The Behaviors That Turn Engineers Into Senior Engineers

Welcome to my newsletter! I'm Dave Anderson, an ex-Amazon Tech Director and GM. I write this newsletter I've called Scarlet Ink, which is a weekly newsletter on tech industry careers and tactical leadership advice.

Free members can read some amount of each article, while paid members can read the full article. For some, part of the article is plenty! But if you'd like to read more, I'd love you to consider becoming a paid member. All of my articles are intended to be evergreen (readable and valid forever). Some weeks I have fresh content; other weeks I'll update/rewrite something from 4+ years ago because I want to keep the quality of all articles high.

Giving strong and harsh feedback, in my opinion, is relatively easy compared to gentle coaching feedback.

That's weird, you might think. But hear me out.

Sure, it's emotionally painful to hurt someone's feelings. However, it's not hard to think of what to say.

"For the third time, you've pushed code without getting it reviewed by a teammate, and your change took down our site. You've broken our team's policy yet again. This is the type of mistake you should never make. Your job here is at risk."

Yeah, you might make the person cry, but they truly deserve it. You know you're doing the right thing. What they've done is objectively wrong, and it's simple to explain exactly what they should or shouldn't be doing.

What's harder is explaining nuanced behavior feedback. You see, once people are doing pretty well, it'd be a terrible shame if your feedback completely stopped. Because if you can boost the value of a top employee by 10%, it's likely more valuable than boosting the value of your bottom employee by 50%.

When I'm working with good team members, one of my favorite ways to provide feedback is to explain the behavior I expected. I find it easier for high-performing people to accept feedback when I say, "I wanted to see X", rather than "You didn't do X". Even better, if I can phrase that behavior in terms of next-level performance, rather than performance for their current role. Because good performers are frequently doing their job fine for their current role. But we want to set our sights higher than fine and good.

Imagine I'm chatting with a decently performing Level 6 Development Manager at Amazon. They had just finished giving a presentation to our VP. They want feedback, and I know I should give them some. The easy path (that most people unfortunately take) is for me to say, "That went well. Nice job. Keep doing what you're doing." I really dislike "keep doing what you're doing", because it's not at all helpful. How can I grow with that?

"I thought the breakdown of your incoming ticket data was pretty good, exactly what would be expected from a dev manager. If it was a Senior Manager presenting (Level 7), I would expect them to also break down the root causes of the incoming tickets, with dates those root causes would be fixed. Giving that additional forward-looking breakdown wasn't necessary for you, but would be the kind of additional information the VP would find interesting. As you move towards your next promotion, I wanted you to think about how the next level would operate."

When someone is underperforming, you can usually refer to the role guidelines. For my prior example of the underperforming engineer, "Follows standard development procedures" might be a line I could point to in our expectations.

However, when someone is doing well, you can rarely point to a line in the role guidelines. You can't find "forward-looking breakdown of root causes" in the dev manager role description. It's simply an expectation that as you grow in experience, you begin to anticipate what your peers may need from you.

Considering that context, let's break down my view on what I think Senior Engineer behavior looks like.

Technical Depth.

This is the one area I won't spend much time on.

Senior engineers know how to use AI. They keep themselves up to date on modern technology and methodologies.

If you are an engineer working in networking, I expect that over a few years you will become a relative expert in networking.

If you're an engineer working in computer vision, again, I expect that you will become pretty good at it.

Regardless of what you're working on, I also expect you to learn related technologies. If you're working on a photo editor (as a random example), I assume you'll also learn storage technology, workflow engines, and probably machine learning. While learning your main technology in depth, you are expected to learn the surrounding area in breadth as well.

I can't possibly explain what a senior software engineer in your space looks like compared to a mid-level software engineer, strictly on technical depth.

In the end, those who stand out as deserving a promotion (or bigger opportunities) usually do so because of qualities outside their deep technical expertise. Technical expertise is the baseline. It's your entry criteria to even be considered for promotion, and it's the easiest thing to measure. You either know your technical work (and you'll earn the respect of your peers), or you are technically deficient, and everyone will know shortly.

Behaviors are more complex to measure, harder to provide feedback on, and typically the thing holding most people back. I think the majority of people stuck at the mid-level engineer level are held back by one of the categories below.