Engineering management fundamentals

The unit of work changes from a change you made to a change the team made, and with it the feedback loop. As an engineer you knew by Thursday whether the week had gone well because something either worked or did not; as a manager the signal arrives in weeks and is second-hand, which is why new managers feel unproductive while being busier than ever. The second change is that your technical opinion now carries positional weight, so an idea you offered as a suggestion is heard as an instruction and the room stops arguing with you. That is a real loss of information, and the practical response is to speak last, ask what the objections are, and make it explicit when you are thinking aloud rather than deciding.

Candidates say they run weekly one-to-ones and are rarely able to say what is in one, so the shape is worth having ready.

Weekly, 30 minutes, same slot, recurring. Cancelled by them, never by you.

part                 minutes  owner   what belongs here
-------------------  -------  ------  --------------------------------------
Their agenda first      12    them    whatever they brought. Blockers,
                                      frustrations, a decision they want
                                      cover for, something personal.
                                      If they bring nothing, ask about the
                                      week rather than filling it yourself.

Feedback both ways       6    shared  one specific observation from the
                                      week, given in situation-behaviour-
                                      impact form. Then: what should I do
                                      differently.

Growth and direction     8    you     progress against the thing they said
                                      they wanted. Reference the ladder,
                                      name evidence you have seen, name
                                      the gap. Monthly depth, weekly touch.

Context they lack        4    you     what changed above them, what the
                                      reorg means, why the roadmap moved.

Running notes            -    shared  a shared doc, both editing, carried
                                      forward. Commitments with owners.

What does NOT belong: sprint status, ticket walkthroughs, code review.
Those have their own forums, and letting them in is how a one-to-one becomes
a status meeting the engineer starts dreading.

The ordering is the substance of the answer. Their agenda goes first because a one-to-one is their meeting, and if yours goes first the time runs out on your items every week and they learn that the slot is for you. The observable symptom of getting this wrong is an engineer who arrives with nothing prepared, which managers misread as disengagement when it is a rational response to a meeting they do not own.

Feedback belongs in every one, not in a quarterly cycle, because the cost of delivering it collapses once it is routine. If feedback appears only when something is wrong, its arrival is itself the message and the person stops hearing the content.

The reciprocal question — what should I do differently — is the part most managers skip and the part that produces the useful information. It rarely works the first four times. It starts working once you have visibly acted on something small, because you have then demonstrated that answering it is safe.

The running notes matter for an unglamorous reason: they are the evidence base for the promotion case and the performance conversation later. A manager who cannot produce dated specifics has a year of impressions instead, and impressions are where bias lives.

Delegation transfers the work and keeps the accountability; abdication transfers both. The practical test is whether you can say, without asking, what the current state is, what the definition of done was agreed to be, and when you next expect to hear about it. If you cannot, you have not delegated, you have hoped. Delegation done properly names the outcome rather than the method, states the constraints that are not negotiable, says explicitly what decisions the person can make alone, and sets a checkpoint they own rather than one you impose. The failure mode on the other side is worth naming too: delegating the task while retaining every decision inside it, which is the most demoralising version because the person carries the effort and none of the authority.

Technical enough to judge, not to build. Concretely, that means you can read a design document and find the unasked question, follow a post-incident review without translation, tell whether an estimate is padded or fantasy, and hold an opinion about the team's architecture that survives contact with the people who own it. It does not mean owning production code on the critical path, because your calendar guarantees you will become the blocker. The direction of decay matters: credibility degrades slowly and invisibly, so managers who do nothing hands-on for two years usually think they are fine and are being managed around. Cheap ways to stay current are reviewing code without approving it, taking on-call shifts, and picking up unimportant work with no deadline attached to it.

Because it is nearly always faster in the moment and nearly always more expensive over the quarter. Taking the task back solves this instance, teaches the team that escalating to you resolves things, removes the learning that would have prevented the next instance, and adds to a queue that already has your name on everything that matters. The exception is real and worth stating so the answer is not absolutist: in an incident, or when a commitment fails this week, take the work. Then treat the fact that you had to as the actual defect and fix the cause — missing knowledge, an unclear owner, a system only one person understands. Doing that twice without follow-up is how a manager becomes the single point of failure they were hired to remove.

Your output is the output of your team plus the output of the teams you influence, which is Grove's formulation and remains the only definition that survives scrutiny. That is deliberately awkward, because it means nothing you did personally counts. Usable proxies are whether the team ships predictably enough that stakeholders stop asking, whether people are visibly more capable than a year ago and can name what changed, whether the team survives your absence for a fortnight, and whether attrition is voluntary in the direction you would choose. The measure to distrust is your own busyness. A manager whose calendar is full and whose team is blocked has high activity and no output, and the interview question behind this one is whether you can tell the two apart.

Listen, then change one thing. The first fortnight is one-to-ones with everyone, asking what is working, what is broken, what they would fix if they could, and what they think my job is. Weeks three to six are for corroborating that against evidence — the incident log, the release history, the last two planning cycles — because the loudest account of a team is rarely the accurate one. Somewhere around week six, name one visible problem and fix it, because credibility comes from a delivered change rather than from a listening tour. What to avoid is a reorganisation in month one: you have inherited a set of arrangements that were rational for reasons nobody has told you yet, and undoing them early is how new managers spend trust they have not earned.