On Senior Engineers

I've recently found myself discussing what it means to be an experienced or senior engineer with a number of different groups. What's interesting about those two terms is that I don't think they connote what the speaker usually intends. Being experienced is neither necessary nor sufficient to be good, or even great, and the word senior has become somewhat bankrupted by promotion ladders at many companies; getting a "senior"-level title is almost automatic in many organizations if you just have the right number of years of tenure (a different problem I previously wrote about).

John Allspaw wrote what I consider to be one of the best essays on this topic, and I refer to it regularly. You can find it on his blog, "On Being a Senior Engineer". It's worth noting that he also eschews experienced and senior in his post, for reasons similar to what I note above, and instead describes what it means to be a mature engineer.

His essay is categorically worth your time to read, so, really, go read it.

Now that you've read it, here's the list he describes:

1. Mature engineers seek out constructive criticism of their designs.
2. Mature engineers understand the non-technical areas of how they are perceived.
3. Mature engineers do not shy away from making estimates, and are always trying to get better at it.
4. Mature engineers have an innate sense of anticipation, even if they don’t know they do.
5. Mature engineers understand that not all of their projects are filled with rockstar-on-stage work.
6. Mature engineers lift the skills and expertise of those around them.
7. Mature engineers make their trade-offs explicit when making judgements and decisions.
8. Mature engineers don’t practice CYAE (“Cover Your Ass Engineering”).
9. Mature engineers are empathetic.
10. Mature engineers are aware of cognitive biases.

One of the things I like most about Allspaw's list is that it captures the importance of non-technical qualities. Note, for example, that there is no mention of "filing patents", "publishing in a journal", "architects large software projects", or any other such measure of technical contribution, and there doesn't need to be. If an engineer exhibits the qualities listed above, their technical contributions are emergent.

In some cases, companies inadvertently communicate that these qualities are insignificant compared to raw technical skill. This is sometimes reflected by poorly structured promotion requirements or performance review metrics. It can also occur when technical experts who are contrary to the above qualities are exalted within R&D organizations. In these cases, you will usually hear things like, "...but they are a technical genius, so they get away with it," or, "...but the project won't succeed without their knowledge," to justify their elevation. Enduring negative behavior in exchange for technical skill is a myopic approach to engineering management, in my opinion, and is a great way to repel the talent you actually want to retain.

Mature engineers often make the difference between success and failure for teams, products, and even companies, and having good ones on your R&D team are a keystone of success. When building new teams, or evaluating whether or not I want to join one, one of my top considerations is who and how many people fit the description, above. This, alone, I think is a strong indicator of outcome.

Originally posted on my blog: https://bhilburn.org/a-keystone-of-success/