How to Delegate Technical Work Without Micromanaging

There is a specific failure that almost every new lead runs into, and it goes like this.

You hand a piece of work to someone. You want to give them space, so you keep it brief. Three days later you look at the branch and it has gone somewhere you would not have gone — not wrong exactly, but built on an assumption you would have corrected in thirty seconds on day one.

Now you have three bad options: let it ship and live with it, ask for a rewrite that costs them three days and some confidence, or fix it yourself and teach them that handing work back is normal.

The instinct after that is to check in more often. That is the wrong correction, and it is how micromanagement starts — not from a desire to control, but from having been burned by under-specifying.

The real problem is the handover, not the follow-up

Micromanagement is usually a symptom. You hover because you are not confident the work will land, and you are not confident because you did not establish enough up front.

Specify more at the start so you can check in less afterwards.

That sounds like more control. It is the opposite: a clear brief is what makes it safe to walk away.

What a handover has to contain

Four things. Miss any one and you get either an unexpected result or a stream of questions.

1. The outcome, not the task

“Add a status column to the enrolment table” is a task. “Support needs to see at a glance which enrolments are stuck waiting on eligibility, because right now they open each one to check” is an outcome.

Give the outcome and you often get something better than you asked for, because the person can see the problem. Give only the task and you get exactly the column — including in the cases where a column was not the right answer.

2. The boundaries: what is fixed, what is theirs

This is the part most often skipped, and it is where the day-three surprise comes from.

Fixed — please do not change these:
  - the existing API response shape (mobile depends on it)
  - the permission model; use the existing `can()` helper
  - we are not adding a new dependency for this

Yours to decide:
  - component structure
  - how the status is derived and where that logic lives
  - whether it needs its own hook

Saying explicitly what they own is as important as saying what is fixed. Without it, cautious people ask about everything and confident people change something you needed stable.

3. The landmines you already know about

You have context they do not. Spend two minutes transferring it.

“The eligibility service returns 200 with an empty body when the member is not found — do not treat that as success.” That sentence saves half a day and it is the sort of thing that only lives in the head of whoever was on the last incident.

4. When to come back

Be explicit, because people default to not wanting to bother you.

• “Show me the approach before you build it — a paragraph is fine.”
• “If you are stuck for more than an hour, come and get me. That is not failing, that is the process.”
• “If it turns out this needs an API change, stop and we will talk.”

That last one is the check-in that actually matters. You are not asking for status updates — you are naming the specific conditions under which the plan is no longer valid.

Match the specificity to the person and the risk

The same brief given to two engineers is wrong for at least one of them. Two variables: how experienced they are with this kind of work, and how expensive it is to get wrong.

The bottom-right cell is where people get it wrong in both directions. Handing a junior engineer a high-risk piece with a one-line brief is not trust, it is abdication. Standing over them the whole way is not support, it is doing it yourself with extra steps. Design together, then genuinely let go of the implementation.

Reviewing without taking it back

You will look at the work and see things you would have done differently. Most of them do not matter.

Before commenting, sort into three buckets:

The second bucket is the discipline. Every time you convert a “different” into a change request, you teach the team that the goal is to guess what you would have written. Do that a few times and people stop making decisions, which is precisely what you were trying to avoid.

The check-in that is not micromanagement

There is a real difference between “how is it going?” asked daily and a scheduled, purposeful checkpoint.

What works: agree one checkpoint at the point of maximum leverage — after the approach is decided, before the bulk of the work is done. Ten minutes there prevents the three-days-in surprise entirely, and it is asked for once rather than hovered over continuously.

What does not work: asking for progress. If you need to know whether it is on track, the answer should be visible in the branch, the board, or standup. If it is not, fix the visibility rather than asking the person.

When it goes wrong anyway

It will sometimes. The response determines whether they take on the next piece with confidence or with anxiety.

The useful question is not “why did you do it that way?” — which sounds like an accusation however you say it. It is “what did you understand the goal to be?” Nine times out of ten the answer reveals that your brief was ambiguous, which is a fixable thing about your process rather than a deficiency in them.

Then fix the brief for next time. Delegation is a skill you are practising too.

The test

Could this person finish the work well if you were unreachable for a week?

If yes, you delegated. If no, you distributed typing and kept the thinking — and you will be doing that forever, because nobody is learning to do it without you.

The goal is not work off your plate. It is decisions off your plate, made by people you trusted enough to give the context.