Think of the last project you handed to an engineer or a tech lead. When it started to wobble, did you hear it from them, or did you spot it yourself in a stand-up, a dashboard or a missed date? The answer tells you more about how your delegation is working than any project plan.

Most Engineering Managers were promoted for being good at the work, which makes handing it off feel risky. Often you are not sure the engineer will match your standard, and sometimes you can already see the result will differ from what you would have built.

My default is still to delegate. You cannot write the code, run the on-call rotation, review every design doc and grow a team at the same time, and engineers usually rise to a real chance. The counterweight is support: the less ready the person, the more help they get. Taking a project back late costs morale, rework and trust, so the goal is to see trouble while it is still small.

Seeing it early is the hard part. Nobody enjoys delivering bad news to their manager, and many engineers worry it will count against them. Saying “my door is always open” is not enough. A routine update format works better: what is going well, what needs attention, and whether the date still holds. When problems have a standard slot in every update, raising one becomes normal reporting, not a confession.

Clarity at the start does the rest. Before work begins, agree on the deliverables, the deadline, how often you will check in and who else needs to know. The most painful delegation failures come when the manager sees a miss and the engineer sees a success. Both worked hard. They were aiming at different finish lines.

Defining success matters even more in engineering, because the work is often invisible and the finish line is fuzzy. Merged, deployed, behind a feature flag, monitored, documented and handed to support are all reasonable meanings of “done.” Two people can say the word and mean different things.

Here is a hypothetical example. An Engineering Manager asks an engineer to move a nightly reporting job to a new platform. The engineer ships a working job. The manager expected the old job switched off, the alerts moved, the runbook updated and the on-call team briefed. The gap was not skill. It was a definition of done that nobody wrote down.

So write it down in a few lines, ideally at the top of the design doc or ticket: what must be true on the last day, who must be able to use it, and what we are willing to leave out. Then name what you care about, so your engineer does not have to guess. For most EMs the unsaid concerns are the same few: how easy it is to roll back, who carries the pager afterwards, a promise made to another team, a date a customer has already heard. Name your top two.

Your reaction to the first piece of real bad news teaches the whole team what future updates should look like. If your reply sounds like blame, the next status turns green early. If your reply is “Thanks for flagging it. What do you need from me?”, you get honest ones. In my experience, a project that is always green is a cue to ask more questions, not proof that all is well.

Add one line to the update format: how confident are you in the date, and why? It gives engineers a polite way to say the plan is shaky, and it fits naturally into a weekly 1:1. Then look at the work as well as the words. A short demo, a staging environment you can click through or a draft pull request tells you things a status line cannot. That is not distrust. It is a second channel.

Finally, ask who should be kept informed. The people engineering teams tend to forget are support, security, SRE, the data team and the neighboring team that depends on your API. A two-minute question at kickoff, “Who will be surprised by this?”, catches most of them.

Escalation rules tell the owner when to bring something to you. For engineering work, I make them observable and agree on them with the owner at the start. These are examples, not a standard:

Reversibility does a lot of work here. Decisions that are easy to undo, like a library choice behind a clean interface or a change behind a feature flag, should rarely need you. Decisions that are hard to undo should always reach you. That one distinction lets your engineers move fast on most things and slow down on the few that matter.

Rules can miss in two ways. If they are too tight, your tech lead becomes a messenger and you become the bottleneck in every thread. If they are too loose, you hear about issues in the incident review. With a new owner, I start tighter and loosen as trust grows. After the first milestone, look at which rules fired and which should have fired but did not, then adjust them together.

A rule only works if the owner can say “I am not sure this counts” without penalty. Give them a light channel, such as a short message, not a meeting. Thank early escalations even when they turn out to be minor. An early alarm that proves minor costs a message. A late alarm can cost a quarter.

Pair the rules with a promise: you will help, not take over. It has to show in your behavior. Picture an engineer who escalates a risk on Tuesday and finds the project handed to someone more senior by Friday. They are unlikely to escalate again, and everyone watching learns the same lesson.

Handing over the decision, not just the execution, is the hardest part for anyone promoted for being good at the how. If you only ask for implementation, nobody is as invested as you are. For Engineering Managers, the pull to stay in control shows up quietly: code review comments that rewrite the design, “quick questions” that are really instructions, a presence in every chat thread.

The fix I find most useful is to separate musts from preferences. Musts are the things that have to hold: an API other teams depend on, a security requirement, a compliance duty, a launch date, the on-call load. Preferences are how you would build it. Share the musts as requirements. Offer preferences as clearly labeled suggestions in review, or keep them to yourself.

Picture an EM who tells a tech lead: the service has to move off the old cluster before the contract ends, the public API cannot change, and nothing may add pages to the on-call rotation. The rest is yours. The tech lead has room to decide, and the guardrails are clear. Compare that with an EM who hands over a finished design doc and calls it delegation.

A less experienced engineer needs more support, but I would adjust the support, not the ownership. Use shorter check-ins, smaller milestones, a pairing partner or a design review before the first line of code. The engineer still decides how to do each step. Support that quietly removes the decisions tells them they were never really in charge. Where they lack context, share your reasoning, but leave the open questions open.

Be honest about the limits. Some decisions should stay with you, and the least helpful move is delegating a decision you plan to overrule. When the outcome meets the agreed definition of done, ask yourself a plain question: is this a real problem, or just not how I would have done it?

Seen this way, delegation is also how you grow your next tech leads. An engineer who makes a call, lives with it and explains it in a retro learns more than one who follows a plan. In my experience, strong tech leads are usually engineers who were given real decisions early, with a safety net.

Think of a time an engineer brought you bad news early. What did you do in the next few minutes that made them willing to do it again? Hit reply and tell me. I read every answer.

Keep going, one small spark at a time.

Erwin