Career

The staff engineer level is one of the most misunderstood in software engineering. Engineers trying to get there often frame it as “more senior” — more experience, better code, harder problems. That framing produces confusion and frustration, because the staff transition isn’t primarily about doing more of what made you senior. It requires a different way of thinking about what your job is. This isn’t a semantic distinction. It matters because the skills you need to develop, the evidence you need to build, and the way you should spend your time are genuinely different at the two levels. Optimizing the wrong things — spending years getting better at code quality when the lever you actually need is organizational influence — produces a plateau that is difficult to diagnose. ...

Reorgs are one of the most reliably destabilizing events in an engineer’s career — not because they are usually catastrophic, but because the uncertainty they create is difficult to think clearly through. You don’t know who your manager will be. You don’t know whether your team will stay together. You don’t know whether the project you’ve been leading for six months still matters. Most engineers respond to that uncertainty by waiting for clarity. The engineers who come out of reorgs in better shape are the ones who move toward clarity rather than waiting for it to arrive. ...

The standard advice for senior engineers is “be more strategic.” Nobody provides tooling for what that actually means in practice. Most productivity and knowledge management tools are built for managers or PMs. The senior IC workflow — navigating informal power structures, tracking skill bets across years, building visibility without a title change — doesn’t fit any standard category. Notion, Confluence, JIRA: these are collaboration tools optimized for teams, not personal career intelligence. ...

A few years ago I was a senior engineer who was doing the job pretty well by the metrics that were visible. Shipping features, writing design docs, unblocking teammates. All the output was there. What I was bad at — and only slowly becoming aware of — was the other 40% of the senior job. The part that doesn’t show up in a performance review as a discrete line item but that determines whether your actual impact is 1x or 3x. The org navigation. The influence. Knowing which conversations needed to happen before a proposal could move. Understanding why some technically good ideas got killed and others with obvious flaws survived. ...

There is a common failure mode for engineers who are doing promotion-worthy work but not getting promoted: they believe the work speaks for itself. It doesn’t. The work gets you to the starting line. The promotion case is a separate thing — a curated, evidence-backed narrative about impact, scope, and judgment that your manager and a promo committee can evaluate without direct exposure to your day-to-day. Building that case is a skill, and most engineers have never been taught it. ...

The RFC process is well-understood at most engineering organizations. You have a problem, you have a proposed solution, you write it up, you get feedback, and you either proceed or revise. RFCs are structured around a decision: should we do X, and if so, how? Strategy documents are different — and the difference matters. A strategy document is not asking “should we do X.” It is answering the question “why are we doing what we’re doing, and how does it connect to everything else we care about?” It is less about proposing a specific solution and more about establishing a shared understanding of the problem space, the constraints, and the reasoning that should govern future decisions in a domain. ...

Most performance review advice is written for engineers who are trying to get to senior. Pass code reviews. Ship features. Demonstrate ownership. Get visible. That playbook breaks at the staff level — and breaks in a particular way. Not because the work is harder, but because the feedback loop disappears. Your manager is often not technical enough to evaluate your architectural decisions in detail. Your impact is measured in quarters and years, not sprints. The “did I do well this week” signal that used to arrive through PR comments and 1:1s no longer exists. You are flying on instruments. ...

Every company has two org charts. The official one lives in an HR system somewhere. It shows boxes, lines, and reporting relationships. It is neat, hierarchical, and largely fictional as a map of how decisions actually get made. The second one exists nowhere in writing. It lives in people’s heads — in the instincts of engineers who have been around long enough to know who you really need to talk to before a proposal goes anywhere. This is the shadow org chart, and understanding it is one of the more underrated career skills an engineer can develop. ...

There is a standard toolkit for engineers. Version control. An IDE. A task tracker. Maybe a note-taking app. These tools exist because they solve problems that are consistent across roles: write code, track work, record things. The senior+ engineer job has a different set of problems. And the standard toolkit doesn’t solve them. The senior+ job is mostly not about writing code This is the uncomfortable truth that Tanya Reilly’s The Staff Engineer’s Path articulates clearly: senior+ engineering is a fundamentally different discipline from senior engineering. The technical work doesn’t go away — but it becomes one input into a much larger job that’s about strategy, alignment, influence, and organizational navigation. ...