You have spent eight or twelve years getting good at building systems, and you have decided you do not want to run a team. That is a legitimate career, and the hiring market has a name for it: Staff Engineer, Principal Engineer, sometimes Distinguished. The trouble is that most senior individual contributors write a CV that sends the wrong message about which ladder they are on, and they get offered one level below what they are actually doing.
This piece is about the CV for that track specifically. Not the manager CV, not the general software engineer CV, but the document that has to prove you operate across teams without anyone reporting to you.
Why senior IC CVs get levelled down
There are two failure modes, and they pull in opposite directions.
The first is copying a manager CV. You borrow the vocabulary of people leadership because it sounds senior: "led a team of eight", "owned a budget", "ran hiring". A hiring panel for a Staff role reads that and concludes one of two things. Either you are really a manager who wants a break from management, or you are inflating an informal lead role. In both cases they start asking about your people skills and stop asking about your technical judgment, which is the thing they are actually hiring for. Worse, if the headcount you claim is small, you look like a junior manager rather than a senior engineer.
The second is copying a senior engineer CV. Here the bullets are all ticket-level delivery: built the payment service, migrated the database, shipped the feature. Every one of those can be true and impressive, and still the reader sees a strong Senior. Nothing tells them that you chose which service to build, convinced three other teams to adopt the pattern, or stopped a migration that would have cost a quarter.
The Staff CV sits between those two. It is technical all the way down, but the unit of work is bigger than a ticket and the evidence of impact is not headcount.
Scope and blast radius instead of headcount
Managers measure scope in people and budget. Senior ICs measure it in blast radius: how much of the system, and how many teams, your decisions touch.
A useful way to write this is to state, for each role, the boundary of what you were responsible for. Not your team's backlog, but the surface you had authority over or influence on. Some honest examples of scope statements:
- "Technical owner for the event pipeline used by 14 product teams"
- "Set the API conventions for the public platform, roughly 300 endpoints"
- "Reliability lead for checkout across web, mobile and partner integrations"
Each of these tells the reader the size of the problem without mentioning a single direct report. Put one line like this under the job title, before the bullets. It frames everything that follows.
The numbers should be real, and they do not need to be huge. "Four teams" is fine if it is true. What matters is that the reader can see the work crossed a team boundary.
The architecture document as the unit of achievement
For a Senior engineer, the natural unit of achievement is the shipped feature. For a Staff or Principal Engineer, it is usually the decision, and the artefact that carries a decision is the architecture document, the RFC, or the technical proposal.
This is the single biggest shift in how you should write bullets. Instead of listing what you built, list what you proposed, what got decided because of it, and what happened after. A good Staff bullet often has this shape: the problem you spotted, the proposal you wrote, who adopted it, and the result.
Some before and after examples:
- Before: "Built a new caching layer for the search service."
- After: "Wrote the RFC for a shared caching layer after spotting the same latency fix in four services; adopted as the platform standard and cut p95 search latency from 900ms to 250ms."
- Before: "Worked on the migration from the monolith to microservices."
- After: "Authored the service-boundary proposal that set the order of the monolith split; the plan I pushed back on would have moved billing first, and keeping it last avoided a freeze on invoicing during the busiest quarter."
- Before: "Mentored junior engineers."
- After: "Guided three engineers through their first design reviews; two now write and defend their own RFCs, and one has since been promoted to Senior."
Notice what changed. The after versions name an artefact, name who else was affected, and give an outcome. The last one also handles mentoring without drifting into management language. You grew people, you did not manage them, and the CV says so plainly.
Evidencing influence without direct reports
Influence is the hardest thing to put on paper because it is invisible by design. You did not order anyone to do anything. Still, it leaves traces, and those traces are what you write down.
The traces worth collecting:
- Standards adopted by other teams. A linting config, an API style guide, an on-call runbook, a service template. If a team you do not belong to uses something you wrote, that is influence with a count attached.
- Decisions you drove. Build versus buy, a database choice, a deprecation. Write the decision and the consequence, not the meeting.
- Things you stopped. Senior ICs are often most valuable when they kill a bad project early. "Recommended against the in-house queue after a two-week spike; the team moved to a managed service instead" is a strong bullet, even though nothing was built.
- People you grew. Promotions of engineers you mentored, interview loops you designed, the onboarding track you wrote.
One practical tip: if your company keeps RFCs or architecture decision records, go back through them before you rewrite your CV. Most people remember perhaps half of what they authored. The documents remember all of it.
Cross-team work and the language that signals it
Staff roles are defined by work that no single team owns. Your CV should make it obvious that you spent a meaningful share of your time there.
A few phrases carry this well without sounding inflated: "across the platform org", "with the data and mobile teams", "for all services on the payments path". Verbs matter too. Proposed, authored, set, unblocked, aligned, deprecated, standardised. Compare those with led, managed, supervised, which point straight at the management ladder.
Keep a hands-on line in each role as well. A Principal Engineer who has not written code in three years is a real profile, but most hiring managers for IC roles want to see that you still build. One bullet about a prototype you wrote or a hard incident you debugged personally is enough to show you have not drifted into pure architecture slides.
Beyond software
The same logic holds in other technical fields with an IC ladder. A Principal Data Scientist proves scope through the models or metric definitions other teams depend on, not the analysts on their project. A principal-level designer points to the component system that product teams build on. In hardware or infrastructure, it is the reference design or the capacity plan. The artefact changes; the principle of showing decisions and adoption instead of headcount stays the same.
What to do this week
Start from your current CV and do three passes.
- Add a one-line scope statement under each senior role: what surface you owned and how many teams it touched.
- Rewrite your top three bullets per role so each names an artefact (RFC, proposal, standard) and who adopted it.
- Delete or rephrase every bullet that uses manager verbs or headcount, unless you actually held that title.
If your LinkedIn profile is more up to date than your CV, which is common for engineers who write a lot internally, a tool like Postulit can pull it into a first draft so you spend your time on these rewrites rather than on formatting.
A Staff CV is not a bigger Senior CV and not a smaller manager CV. It is a record of decisions that other teams live with.