When working with team members, one of my favorite ways to provide feedback is to explain the behavior I expected. I find it easier for people to accept feedback when I say "I wanted to see X", rather than "You didn't do X".

As a slight tangent, imagine I'm chatting with a moderately performing Level 6 Development Manager at Amazon. They had just finished giving a presentation to our VP.

"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 certainly 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."

The context I gave in the example was not directly from the Amazon role guidelines. You can't find "forward-looking breakdown of root causes" in the development manager roles. It's simply an expectation that as you grow in experience, you begin to anticipate what your peers may need from you.

Amazon has some great role guideline documents internally. I'd love them to release those to the public because I think you can get some great insights into how people view each level of expertise and responsibility.

Often enough, that's one of my first recommendations to employees at Amazon who want to get promoted. I'll suggest they first read (in detail) the role guidelines document for their role. Because understanding the expectations of getting to the next level, is key to understanding how their behavior and performance needs to change.

Considering that context, I thought it would be useful and interesting to 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.

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

If you're an engineer working in Computer Vision, again, I expect you become pretty good at it.

Regardless of what you're working on, I also expect you to learn the surrounding technologies. If you're working on a photo editor, for example, I assume you'll also learn storage technology, workflow engines, perhaps machine learning. While learning in depth, you are expected to learn in breadth as well.

I can't possibly explain what a software engineer in your space looks like compared to a senior 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, and the easiest to measure. Behaviors are more complex to measure, harder to provide feedback on, and typically the thing holding people back.

Makes the team around them better

This is perhaps the top priority, so I'm listing it first.

Senior engineers are frequently not the most productive engineers on a team. Why? One big reason is that they're spending their time on coaching and mentoring their co-workers.

The highest value of code reviews isn't about ensuring code is high quality. That's a mistake that junior engineers make. It's about ensuring that the engineers involved grow their skills, and understand how to do better engineering. It's about growth, not about this exact code.

A design review isn't only about making the best design, it's about walking through the tradeoffs in the design, asking the right questions, and ensuring that all tech folk involved understand why choices were made. Team growth is a significant portion of the value of discussing a design.

When a product manager asks for some cost estimates on their features, it shouldn't be about handing them a list of 17 numbers. "1 week, 7 weeks, 13 weeks, 4 weeks.." That's useful, but insufficient. It should be about educating them on why certain choices are expensive, why certain choices are easier, and how that could play into adding more value for our customers.

When the senior engineer reads an excellent white-paper on a new technology, they don't just forward it on. They explain why their team should pay attention to the white-paper, and what they learned from it.

When the operational load of a team starts growing, the senior engineer is not responsible for simply fixing it, or pointing fingers at their manager's resource allocation. They're responsible for educating their manager, project managers, and engineers, to ensure that the future will be better.

Senior engineers may write less code, but they're providing significantly more value than a single employee.

This post is for paying subscribers only

Sign up now and upgrade your account to read the post and get access to the full library of posts for paying subscribers only.

Sign up now Already have an account? Sign in