Technical Leadership

The most technically rigorous work can be undermined by how it’s presented. An engineer who presents a beautifully designed migration plan to a VP using technical vocabulary, implementation details, and system architecture diagrams is often going to lose the room. Not because the work is bad, but because it’s pitched at the wrong level. Non-technical stakeholders — product managers, finance leaders, VPs, C-suite executives — make decisions based on outcomes, risks, and tradeoffs at a business level, not at a systems level. Your job as a staff engineer is to translate between those worlds: to take something technically complex and make it comprehensible and actionable for people who don’t share your frame of reference. ...

Staff engineers who don’t delegate end up in one of two failure modes: they become overloaded individual contributors whose leadership impact is capped by their own bandwidth, or they become bottlenecks whose teams can’t move without their direct involvement. Either way, the scope of work they can affect is limited to what they can personally execute. Delegation is how staff engineers multiply their impact. But delegating badly — unclear expectations, no feedback loop, rescue when things get hard — teaches people less than not delegating at all and produces lower-quality outcomes. ...

Engineering meetings have a bad reputation, and much of it is earned. Too many meetings are called when an async message would suffice, run without a clear purpose, and end without decisions or next steps. The people who attend feel their time was wasted. The people who called the meeting often didn’t accomplish what they intended. This post is specifically about the meetings that matter at the staff engineer level: design reviews, architectural decision meetings, technical alignment sessions, and cross-team coordination. These are meetings worth doing well — they’re how complex technical work gets coordinated. The goal is not to eliminate them but to make them actually work. ...

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. ...