Most engineers have an uncomfortable relationship with the phrase “managing up.” It sounds like politics, like playing games, like doing something other than the real work. The discomfort is understandable — and it leads to a lot of staff engineers doing excellent technical work that doesn’t get funded, prioritized, or protected. Managing up is not about manipulation or self-promotion. It’s about ensuring that the people responsible for resource allocation, roadmap decisions, and organizational priorities have accurate information about the work you’re doing and why it matters. When you manage up poorly, decisions get made with incomplete information. That’s bad for the organization and bad for the work you care about. ...

Technical design documents (TDDs) — sometimes called design docs, RFCs, or tech specs — are one of the most valuable tools available to staff engineers. When done well, they create alignment before implementation, surface risks early, and create a durable record of why decisions were made. When done poorly, they’re ignored, debated endlessly, or written as formalities after the decision is already made. This post is about writing TDDs that work: getting the right people to the right decision with minimum friction. ...

Most engineers who get promoted to or hired as staff engineers are surprised by how different the role feels in the first year. The technical skills that made them excellent senior engineers are necessary but no longer sufficient. The work is less about coding and more about judgment, direction, and coordination. The feedback loops are longer. The impact is harder to see in real time. This post is for engineers in their first 12 months as a staff engineer: what to focus on, what mistakes to avoid, and how to think about the year as a whole. ...

A technical roadmap is supposed to answer a simple question: what are we building, when, and why? In practice, most roadmaps fail to do this usefully — they’re either so high-level they don’t convey meaningful information, so granular they’re out of date within a week, or honest about neither the priorities nor the uncertainty. The engineers who build good roadmaps understand that a roadmap is a communication tool, not a plan. It’s for alignment, not prediction. ...

Most technical projects fail at the scoping phase, not the execution phase. The project that ran over by six months, produced something that didn’t quite match expectations, or got cancelled partway through — in nearly every case, the root problem was established in the first few weeks, before most engineers started working. Scoping isn’t writing a requirements document. It’s the thinking process that determines whether a project has a coherent, achievable definition before resources are committed to it. Done well, it prevents three months of work from being thrown away. Done poorly — or skipped — it virtually guarantees it. ...

The jump from senior to staff engineer interviews is bigger than most candidates expect. Senior engineer interviews are largely about technical depth — can you design systems, write good code, reason about complexity? Staff engineer interviews add an entirely different layer: can you operate at scope, drive alignment, influence outcomes, and communicate at the executive level? Most candidates who fail staff engineer interviews are technically excellent. They fail on the judgment, communication, and leadership signals that the interview is actually designed to surface. ...

The central challenge of the staff engineer role is that the impact you’re expected to have — shaping technical direction, driving alignment across teams, changing how engineering gets done — requires influence, not authority. You can’t direct anyone. You don’t have a reporting line. You get things done by persuading people who don’t report to you, earning trust with stakeholders who already have strong opinions, and navigating organizational dynamics that nobody explicitly documented. ...

Giving feedback is one of the most high-leverage things a senior engineer does — and one of the most consistently underdeveloped skills in the profession. Most engineers who are technically excellent struggle with feedback because the skills are completely different. Writing good code requires precision and correctness. Giving feedback that changes behavior requires understanding why the behavior exists and what conditions would change it. This post is about technical feedback specifically: code reviews, design critiques, architecture discussions, and the kind of direct feedback about someone’s technical work that either helps them grow or falls flat. ...

Most engineers write their first RFC by borrowing a template and filling in the blanks. The result is a document that describes a technical solution in detail, lists some alternatives, and ends with an open-ended question about what people think. That kind of RFC doesn’t produce decisions. It produces comment threads. An effective RFC is not a document that describes a solution. It is a document that frames a decision — that lays out the problem, the constraints, the viable options, and the trade-offs clearly enough that reviewers can evaluate them and reach a conclusion. The solution you prefer is in there, but it’s one item in a structured argument, not the whole document. ...