Communication

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

Most engineers have extensive experience being on the receiving end of 1:1s. As a junior or mid-level engineer, you have them with your manager. They set the agenda. You update on your work, raise blockers, ask questions. At the staff level, a significant number of your 1:1s are ones you initiate — with peers you need to work with, with stakeholders whose teams are upstream or downstream of yours, with leadership whose support you need for technical direction you’re trying to establish. These are different from the 1:1s you were trained on. The dynamics are different, the stakes are different, and the mistakes are different. ...