The Senior Engineer Path (That Isn't Management)

You don't have to become a manager to grow your career. Here's a framework for senior IC growth that I've used and advised others on.

For most of my career, the assumption was that growth meant management. Senior engineer was a layover, not a destination. If you wanted more impact or more compensation, you switched orgs into a manager track and stopped writing code.

That model is breaking, and I think that is good. The senior IC path is real now, but most people misunderstand what it actually requires.

The myth of the IC track

The first thing I want to dispel is the idea that staying technical means staying narrow. Almost the opposite is true. The senior individual contributors I respect are wider than most managers I have worked with. They just express that range differently.

A staff engineer is not a senior engineer plus seniority. It is a different job. The work is mostly:

• Finding problems nobody else has named yet
• Making other engineers more effective
• Owning decisions that span multiple teams
• Writing things down so the org does not relearn the same lesson three times

If you want to know whether you are tracking toward this, check what your last quarter actually looked like. If it was tickets and PRs, you are still doing senior work. If it was uncomfortable cross-team conversations and documents, you are starting to do staff work.

What you give up

Nobody talks about the costs honestly. There are some.

Recognition lag. Manager wins are visible: this team grew, this person got promoted, this initiative launched. IC wins are diffuse. You prevented a bad architecture nobody will ever see. You wrote the doc that ended a six month debate. The org will eventually notice, but it takes longer.

Politics without authority. Staff engineers operate by influence. You cannot tell anyone what to do. Earlier in my career working on regulated systems, I learned that being right is necessary but not sufficient. The people who succeed on this track are the ones who learn to make others want to do the right thing, without resenting them for it.

The compensation ceiling is real but lower than people think. At most companies, principal level pay matches or exceeds senior manager. But the path is narrower and the variance is higher.

What you actually need

Three things, none of which you can fake.

Depth in something specific

You need to be the person on the team for at least one thing. Not knows it, the person. From teams I have worked with, the staff engineers who lasted were the ones who could be paged at 2am about their core system and have a useful answer in five minutes.

The trap is choosing a thing that is not durable. Frameworks come and go. Pick a domain that compounds: distributed systems, performance, data modeling, security, LLM systems. Pick at least one.

Range in everything else

Depth alone makes you a specialist. The IC track requires that you can also walk into a frontend code review and say something useful, or read a Postgres query plan, or follow a product spec discussion without getting lost.

This is the part that takes the longest. There is no shortcut. You read code outside your area, you go to design reviews, you ask dumb questions in public until they are not dumb anymore.

Writing and speaking

This is the leverage multiplier. A staff engineer who cannot write clearly is invisible. A staff engineer who writes well shapes the org by leaving artifacts in its codebase, in its documents, in its public posts.

Most engineers are bad at this and treat it as optional. It is not optional. It is the single highest leverage skill on the IC track.

How to know it is working

A few signals I look for in myself and the people I advise:

1. You are getting consulted on decisions outside your team. Not invited, consulted. People want your opinion before they ship.
2. Your code reviews change designs, not just diffs. You are pushing back on the framing, not the formatting.
3. You can describe your impact in business terms. If you cannot, you are not yet operating at staff level, regardless of what your title says.
4. You are training your replacement. Senior IC work is anti-hoarding by nature. The more you teach, the more leverage you have.

A note on the management decision

If you are deciding between tracks, do not let comp drive it. Both tracks pay well at the top, and badly in the middle. Decide on what you want your weeks to feel like.

Manager weeks are people-shaped. One on ones, calibration, hiring, conflict. IC weeks are problem-shaped. Code, designs, debugging, writing. Some people are energized by the first and drained by the second. For me, it is the other way around. There is no virtue in either answer. There is only fit.

If you are weighing this and want to talk it through with someone who has been on the IC track for a while, /contact is open. The choice is reversible, but the reversal costs more than people expect.

References

• Will Larson: Staff Engineer
• Tanya Reilly: Being Glue
• Charity Majors: The Engineer Manager Pendulum