sean goedecke

The more senior engineers get, the more results matter

In my experience, people tend to overrate how much moving up the org chart changes the fundamentals of the job. As a staff engineer, I do more or less the same thing as I did as an intern: write code, respond to tickets, create my own tickets for work that needs doing, and ship projects1. The work I do is faster and better, since I have many more tools in my toolbox, and I do move from project to project more often, but it’s not qualitatively different. My job is still more like a software engineering intern’s job than it is like an equivalently-leveled product manager’s job.

What does change as you move up the org chart?

As you get promoted, obviously the expectations are higher: you’re expected to produce higher-quality work with less supervision, and are trusted to “do something useful” in basically any situation you get put in.

However, there’s one difference that I think many engineers miss: as you become more senior, you’re increasingly graded on results. Interns are graded on effort. If you can be pleasant to work with and you’re clearly trying, you’re doing fine. Junior engineers have to get some things done, but it’s okay to need a lot of help and to not be very productive. Senior engineers are expected to execute independently. However, if the project they’re executing on fails, it doesn’t matter that much, as long as they’ve executed well. Staff engineers, in my experience, are expected to succeed.

Isn’t that unfair?

If this seems unfair, it’s because it is! Projects can fail for many reasons that are broadly outside of engineering control: lack of support, bad product-market-fit, and so on2. If you do solid technical work but the project fails for non-technical reasons, how can that possibly be your fault? Fair enough. But that’s the staff+ engineer deal. You’re expected to have enough non-technical influence and enough good taste to make the project succeed anyway. A couple of failures won’t get you fired - sometimes you do just get unlucky. But they will count against you, and if you don’t have enough successes to hold up alongside them, you will eventually be penalised in your feedback and bonus.

This is only really surprising to engineers. For managers and executives, the expectation to succeed is a well-understood part of the job description. This is most clear in the case of C-staff and senior VPs, who are directly on the hook - formally, in their contracts! - for the financial health of the company. If the company fails to make money, it doesn’t really matter what excuses the executive has. They’re out the door. To a lesser extent, the same is true of all senior VPs and managers.

Final thoughts

If you’re a strong senior engineer who wants to make it to staff, I don’t necessarily recommend trying to become a more effective mentor or whatever the job description in your org chart says. I recommend gaining a reputation for successfully shipping high-profile projects. But I’d also caution you about making that step if you’re not comfortable with being directly accountable for results. Some people who are very technically competent just can’t stand being on the hook for other people’s decisions. In my experience, a strong sense of fairness correlates pretty well with technical ability. If that sounds like you, you might not be happy in a staff role, even if you’re comfortably over the technical bar.


  1. From what I hear, this isn’t true for all staff engineers. Some are engineering managers in all but name, or are shunted into prototype-only architectural roles, and so on. It does happen! But the vast majority of staff engineers I’ve worked with are still operating as part of a regular engineering team and getting their hands dirty on real production code.

  2. I wrote a whole post about this.

If you liked this post, consider subscribing to email updates about my new posts.

July 8, 2025 │ Tags: tech companies, staff