Advanced IC (Senior / Staff / Principal Engineer)
Growing the scope of the problems you own, without taking on formal people management.
The advanced individual contributor path is about increasing the size of the problems you own rather than the number of people who report to you. At Staff and Principal level your work is judged by how much technical risk you remove from the organisation and how many other engineers make better decisions because of you. You stay close to code, but code stops being the main unit of your output.
What this path actually involves
Day to day you work on the problems that are too cross-cutting, too risky or too poorly defined for a single team to absorb: a migration nobody wants to own, a performance ceiling that keeps returning, a design decision that would be expensive to reverse. You write code, but selectively - prototypes, the hard core of a system, the reference implementation others copy. A large part of the week goes into design reviews, written proposals, debugging across team boundaries, and unblocking people who are stuck.
What it does not mean
It is not a senior engineer who codes more. Staff and Principal are not a reward for accumulating years of depth; what changes is scope and influence, not the volume of implementation. It is also not a way to avoid people work - you spend a lot of time mentoring, persuading and disagreeing well, you simply do it without formal authority. And it is not a role where you get to pick the interesting problems for yourself; you usually take the ones the organisation cannot otherwise solve.
Typical responsibilities
- Own technical outcomes that span several teams or several quarters.
- Make and document architectural decisions, including the trade-offs and the option you rejected.
- Reduce technical risk before it becomes an incident or a rewrite.
- Raise the technical level of engineers around you through review, pairing and mentoring.
- Translate business constraints into technical direction teams can actually execute.
- Say no to work clearly and with reasons, when the cost is not visible to others.
Skills that matter
What changes from a strong senior engineer role
A strong senior engineer is trusted to deliver a hard piece of work well. An advanced IC is trusted to decide what the hard piece of work should be, often before it is well defined. The visible difference is that your output becomes other people's changed behaviour: decisions made differently, designs improved before review, problems that never happened.
Signs you may enjoy it
- You are drawn to problems that are ambiguous and technically deep at the same time.
- A design that quietly prevents a whole class of future failures satisfies you.
- You would rather spend a week making a decision reversible than a month arguing about it.
- You find it interesting, not tedious, to explain a trade-off to people without your context.
- You keep learning technically without needing a project to force it.
Signs you may dislike it
- The amount of writing, reviewing and persuading involved wears you down.
- On days when you merged nothing you feel you did not work.
- Explaining the same decision again feels draining rather than normal.
- You want the authority to end a debate more than the patience to win it.
- You would prefer the organisation simply told you what to build.
Common misconceptions
- That it is the path for engineers who do not like working with people.
- That the deepest engineer in the room is automatically the most senior.
- That Staff and Principal are standardised levels meaning the same thing everywhere; the scope depends heavily on the company.
- That you can reach it through technical excellence alone, without ever writing a proposal or changing someone's mind.
Where it typically leads
It typically deepens from Senior to Staff to Principal or Distinguished, with scope widening from a team to a domain to the organisation. Many people move sideways from here into architecture, technical leadership or management and back again; the path is not one-directional.
How AI is changing this role
Agentic tools have made producing code much cheaper, which shifts the scarce work towards judgement: deciding what should exist, reviewing far more generated change than before, and verifying that the result holds under load and failure. Context engineering is becoming a real senior skill, because the quality of an agent's output depends on how explicitly the system, its constraints and its conventions have been written down, and advanced ICs are usually the people who can do that. Architectural clarity and strong test and observability boundaries matter more now, since they are what makes fast-moving generated code safe to accept. The volume of code you personally type is likely to keep dropping; the amount of technical judgement expected of you is not.
Experiments to run before deciding
Own one cross-team technical problem end to end
8-12 weeks
- Pick a problem two or more teams complain about and nobody owns.
- Write a two-page proposal with the options, the trade-offs and your recommendation.
- Circulate it for written feedback before presenting it in any meeting.
- Drive it to an explicit decision, then stay accountable for the rollout even where others implement it.
- Write down which of your original assumptions turned out to be wrong.
Then ask yourself
Did the written and organisational half of that work energise you, or did you mostly want to be left alone to implement your part?
Make your technical influence visible without writing the code
8-10 weeks
- Choose one design decision inside another team's scope and offer to review it.
- Coach the engineer who owns it instead of proposing your own design.
- Write down the principle behind the decision so it can be reused.
- Ask two engineers what they now do differently, and why.
Then ask yourself
Look at the evidence, not the intention: could those two engineers name a decision they now make differently - and on the days you shipped nothing of your own, was that enough?
Test yourself on the unglamorous risk
10-12 weeks
- Identify the technical risk most likely to cause an incident in the next year.
- Quantify it well enough that a non-engineer can see the cost.
- Negotiate time for it against feature work, in the open.
- Reduce the risk measurably and publish the before and after.
Then ask yourself
Did you enjoy work that produces no visible feature, or did you need the visible outcome to feel it counted?
Worth reading
Staff Engineer - Will Larson
The clearest account of what changes above senior, including how differently the role is defined from company to company.
The Staff Engineer's Path - Tanya Reilly
Practical on influence, scope and the non-code work senior ICs are actually measured on.
A Philosophy of Software Design - John Ousterhout
Short and opinionated; useful for sharpening how you argue about complexity in design reviews.
Designing Data-Intensive Applications - Martin Kleppmann
Still the best single source for the systems trade-offs you will be asked to judge.
Not sure whether this path is closest to you?
Take the Career CompassHelp improve this page
If you have worked in this role and something here is inaccurate, incomplete or out of date, tell me. Suggestions are reviewed before anything changes.