When I moved from managing projects to running the development department, the job description talked about strategy, capacity, and standards. All true. But the version that actually changed how I spend a week is shorter: a head of development owes the team four things, and everything else is detail.
A standard they can see
The first thing a team needs from its lead is a clear answer to what good looks like here. Not a slogan. A written set of expectations for how code is structured, reviewed, tested, and released, short enough that a new developer can read it on their first morning and specific enough that a review can point at it.
The standard only counts if it is enforced in review, including on the lead’s own code. I still write production code, partly because I like it and partly because a standard I do not hold myself to is just a document. Review is where the culture actually lives. The lead’s job is to make sure it is thorough, kind, and about the code rather than the person.
A plan before the sprint starts
Nothing burns a team out faster than work arriving unsized and unsequenced. So the second thing the lead owes them is a plan: what is being built, in what order, by whom, and what done means for each piece, agreed before the sprint opens rather than discovered halfway through it.
This is where the project management years pay off. Estimation is done with the people who will do the work. Dependencies on clients and third parties are surfaced in planning, not in a stand-up three days before the deadline. And when a client wants something new mid-sprint, the answer is a conversation about what it replaces, not a quiet addition to somebody’s evening.
Cover
The third thing is the one that never appears on an org chart. A development team needs somebody standing between it and the noise: scope creep, interruptions from other departments, urgent requests that are not urgent, and blame when something goes wrong in production.
Cover does not mean hiding problems. When a release fails, the client hears about it from me, with the cause and the fix, the same day. What the team gets is the assurance that the conversation about who made the mistake happens inside the room, as a lesson, and not outside it as a verdict. Engineers who feel safe report problems early. Engineers who do not, hide them until they are expensive.
Protecting focus is part of the same duty. A developer who is pulled onto four things a day finishes none of them. One of the quieter wins of the last year has been giving each project a named lead and a single channel for requests, so the rest of the team can go a full morning without a context switch.
A next step
The fourth thing is a future. Every engineer on the team should be able to say what they are growing into and what the department is doing to get them there. For some that is a deeper specialism, for some it is their first project lead, for some it is the move into management that I made myself.
In practice that means a conversation each quarter that is about them rather than about the backlog, a real say in which projects they get, and the occasional stretch assignment with the cover to fail at it safely. Hiring is part of the same job: the bench should get stronger every year, and the people already on it should be the first to benefit when it does.
What this looks like from the outside
A managing director does not measure any of this directly. What they see is whether projects land on the dates that were promised, whether clients come back, and whether the department can take on more work without falling over. Those outcomes are the result of the four things above, done consistently, and that is why they are the first place I look when one of the outcomes slips.
None of it is complicated. It is the same discipline that makes a good developer and a good project manager, applied to people instead of to code or to a schedule. The lead who has done both of those jobs has an advantage, because they know exactly what the team is being asked for and what it costs to deliver it.