Leadership Garden
Engineering management careers often begin through accumulation. You know the roadmap, so you take on hiring. You know the new hires, so you handle onboarding. You understand the team, so people ask you to coach them.
What interests me is how ordinary each request sounds. None feels like a career change on its own, but together they move your work somewhere else.
Most advice for new managers focuses on delegation: hand off tickets, leave critical work to the team, and make sure it can operate without you. That advice is sound. It also stops one step early. A team can keep shipping without its manager and still depend on judgment the manager never taught.
The harder job is to make that judgment transferable.
Every useful intervention should leave someone better able to understand the customer, weigh risk, or communicate a recommendation. Over time, they should make the next decision without waiting for permission. The work changes with the company and the team. That standard holds.
The role moves
Engineering management moves across product, process, people, and programming. The balance changes constantly. A small team may need its manager in the code. A team without a product manager may need its engineering manager in customer calls. A large team may consume every available hour with hiring, coaching, and coordination.
I think this is why a universal job description for engineering managers tends to disappoint. The useful question is local: where is this team currently unable to make a sound decision?
Sometimes the answer is technical. More often, the team lacks context, authority, or confidence. A manager who responds to every gap by taking over may get a good result this week. The team learns to wait for the same rescue next week.
New managers often retreat toward technical work because they already know how to succeed there. Management remains the awkward work they do between coding sessions.
Three months later, I would ask one question: can more people make sound decisions without the manager stepping in?
Context is the first handoff
Managers often delegate work while keeping the reason for the work to themselves. The engineer receives a ticket, a deadline, and perhaps a mock-up. The manager keeps the customer complaint, the commercial pressure, the rejected alternatives, and the reason the deadline matters.
That is task distribution. It creates activity, though it does little for judgment.
Product context changes the quality of delegation. An engineer who understands the user and constraints can question a weak spec, choose a cheaper approach, or decide that no new code is needed. An engineer with only the ticket can deliver exactly what was requested, including its mistakes.
Before handing off meaningful work, I would want the person taking it to know:
- who has the problem and what they are trying to accomplish
- which constraints are real and which ones are habits
- what a poor outcome would cost
- which decisions are reversible
- when they should ask for help
This takes longer than assigning a ticket because you are handing over the material someone needs to exercise judgment. That material rarely fits in a status update.
Process can preserve fear
Consider a familiar example of process bloat. An engineer ships a broken interface, everyone reacts, and designer approval becomes mandatory for every pull request. One failure produces a permanent tax for the entire team.
Managers add controls because controls feel responsible. The cost arrives later, spread across enough people that nobody can point to it. The extra review becomes normal. Six months on, the team remembers the rule and forgets the incident. (The rule rarely comes with an expiry date.)
Before adding a process, write down the failure it is meant to prevent. Estimate how often that failure occurs, what recurrence would cost, and what the new control will cost every week. Set a date to review the trade. A control without a review date has a good chance of outliving the problem.
Process can transfer judgment when it records a lesson people can apply. A short release checklist may remind an engineer to inspect the failure modes that previously hurt users. Requiring another person to approve every routine choice sends a different message: judgment lives elsewhere.
Mature teams need useful constraints, with old controls removed once their purpose has passed.
Communication teaches people how to think
Communicating down and communicating up require different kinds of discipline.
When speaking with the team, the manager owes people enough truth to understand their situation. If customers are unhappy or a project may be cancelled, hiding that information makes sensible planning impossible. People fill unexplained gaps with guesses, and their guesses are often worse than the facts.
Transparency does not require forwarding every anxious message from an executive. Share what is known, what remains uncertain, what decision has been made, and what the team can do next. That gives people a usable picture of reality.
Communication upward requires compression and a point of view. Managers sometimes present two half-formed options to executives, then leave with a third option nobody wanted. The executive made a decision because the manager brought a problem without a recommendation.
A useful upward brief contains the context, the problem, your recommendation, the alternatives you rejected, and the support you need. Writing it forces you to decide what you think. Sharing that reasoning with the team lets other people practice the same discipline.
After a few of these briefs, someone else on the team should be able to write one without you.
Follow-up is part of trust
Trust becomes vague advice surprisingly quickly. Managers hear that they should grant autonomy, so they step back. Then a project drifts for three weeks, and the same manager returns with daily status checks.
Trust and follow-up belong together when follow-up helps someone recover early. The purpose is to notice a missing dependency, a misunderstood goal, or an engineer who has been stuck too long to admit it comfortably.
Numbers can help, but they see a narrow part of the work. Pull requests and completed tickets will miss the engineer who catches weak requirements before implementation. They will miss the person who helps three teammates finish, or explains a difficult system well enough that another team can finally use it.
Qualitative judgment is slower. It requires being present in planning, reading the awkward thread, and noticing who people call when the work becomes confusing. This is one reason automated management dashboards promise more than they can deliver. They count visible artifacts while much of a team’s value appears between them.
Good follow-up asks about the next decision, the evidence behind it, and where confidence is low. It gives the manager a chance to coach without taking the work back.
Give away the next decision
Managers rarely set out to become bottlenecks. They keep a critical tool because they built it. They remain the contact for another team because they already know everyone. Technical decisions reach them because answering takes five minutes and teaching may take an hour.
That hour is the work.
Each recurring intervention should leave something behind: an owner, a written constraint, a decision rule, or a direct relationship between two people. Those people may have previously communicated through the manager. The immediate exchange may be slower. The fifth exchange should no longer require you.
A month away is often used as the test of a healthy team. I like the test, with one addition. A team can continue moving while its manager is absent and still make poor decisions. Continuity is useful. Independent judgment is better.
Look at the ordinary week instead. Do engineers make small, reversible choices without asking permission? Can they explain the customer problem behind their work? Do they know when a risk deserves escalation? Can they disagree by comparing tradeoffs instead of defending positions?
Listen to how the team argues when you stay quiet. If people compare customer impact, reversibility, and cost, the team has learned how you weigh a decision.
Managers will always retain obligations that cannot be delegated: performance decisions, staffing, organizational commitments, and some difficult conversations. Their reasoning should not remain trapped in their calendars.
If every answer still lives with you, you have collected work rather than built leadership. Teach the reasoning, give away the decision, and stay close enough to see what people learn. Then give away the next one.