loading...

On Senior Engineers

bhilburn profile image Ben Hilburn Originally published at bhilburn.org ・3 min read

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/

Posted on by:

bhilburn profile

Ben Hilburn

@bhilburn

Excited by good ideas and kind people.

Discussion

markdown guide
 

Mature engineers do not shy away from making estimates, and are always trying to get better at it.

That really stuck out to me because I've met many engineers who roll their eyes at estimation and avoid it at all costs.

 

That's because getting better at it means learning stuff like story points, or the cone of uncertainty.

Having a single date deadline is known to be basically impossible by most of literature out there. Yet business don't want estimates with probabilities, they want date deadlines.

 

Because estimates are just educated guesses and overwhelming fraction of people who want to know estimates do not understand that. Only way to know exact finish date is to complete project or task first.

Estimates are normally heard as promise to do this by that deadline even if you never say this. There are even guides how to word that appropriately to reduce chances of being misunderstood. So for most people it is easier to simply avoid giving estimates at all.

 
 

HAHAHAH I wrote that before our conversation.

 

Great read 👍, and thank you for sharing Allspaw's post. I'm not closed to be a "Senior" Engineer yet but reading this gives me a good glimpse of the ideal qualities and self-awareness that I should be pursuing.

 

Related to John's 9 and 10:

11) Mature engineers encourage diversity. Of people, ideas, and viewpoints.

 

Mature engineers have an innate sense of anticipation, even if they don’t know they do.

Could you explain what you mean by this line a bit? I don't quite understand it.

 

Sure. From John Allspaw's essay, referenced in my post:

Mature engineers have an innate sense of anticipation, even if they don’t know they do.

This code looks good, I’m proud of myself. I’ve asked other people to review it, and I’ve taken their feedback. Now: how long will it last before it’s rewritten? Once it’s in production, how will its execution affect resource usage? How much so I expect CPU/memory/disk/network to increase or decrease? Will others be able to understand this code? Am I making it as easy as I can for others to extend or introspect this work?

 

Ahh, as in anticipate something happening I was thinking of it in a sense of look forward to. Thanks!

 

Fantastic Article!! I like the term 'Mature Engineers' than 'Senior Engineers'. I'm going to print the 10 points and stick it on my workspace. 👍