Engineering-Leadership

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

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

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

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