Giving direction without micromanaging

A senior engineer on your team has been quietly rewriting a service you asked her to extend. She is four days into what was supposed to be a two-day task. You find out in standup. Your first instinct is to schedule a call, walk through the approach together, maybe take over the ticket. You resist — barely. The rewrite ships, it is cleaner than anything you would have produced, and the incident rate drops. Six months later she is leading a squad of her own.

Now replay that story with a different manager: one who schedules the call, walks through every file, insists on their own approach. The engineer delivers the task. She also starts updating her resume.

The delta between those two outcomes is not about technical judgment. It is about what kind of direction was given at the start, and what happened when the path deviated from expectation.

The real cost of micromanagement

People tend to frame micromanagement as a personality type — the anxious manager who cannot let go. That framing lets most managers off the hook, because they do not think of themselves as anxious. They think of themselves as thorough. Involved. Raising the bar.

The actual mechanism is simpler: micromanagement is what happens when a manager does not trust that the person has the information needed to make good decisions. Sometimes that distrust is justified — the person is new, the stakes are high. Usually it is not justified, but the manager never examined the assumption. The behaviour that follows — checking in constantly, revising outputs, dictating approach — destroys two things simultaneously: the work quality (because people stop thinking for themselves when they know their decisions will be overridden) and the relationship (because adults experience close surveillance as distrust, and distrust is corrosive).

The equally real failure mode on the other side is abdication: handing someone a vague objective, vanishing, then appearing at the deadline to express disappointment. Abdication feels like autonomy to the manager. It feels like abandonment to the person doing the work.

The goal is the space between those poles. Call it aligned autonomy: your people know where they are going and why, and they own how to get there.

The Direction Spectrum

Most managers oscillate between the two bad poles rather than holding the middle. They micromanage when they are anxious, abdicate when they are overloaded, and wonder why neither produces the outcomes they want. The middle requires more deliberate setup work upfront, which is exactly why it gets skipped.

Four moves to get there

1. Communicate intent, not instructions

Before you assign any piece of work, get clear on one sentence: what does success look like from the outside, and why does it matter? Then say that sentence out loud to the person you are delegating to.

“I need the data pipeline to run nightly and land before the 7 AM dashboard refresh, because the analytics team makes their day’s prioritisation decisions off that dashboard” is a direction. “Do the ETL, schedule it in Airflow, connect it to the dashboard” is a set of instructions — it tells them what you already decided, not what you need.

The first framing gives the engineer room to find a better approach than the one you were imagining. It also gives them the why, which is what they will reach for when they hit an edge case at 11 PM and you are not available.

Intent-first direction requires you to have done the thinking yourself first. Many managers skip it because they have not. They are handing off work they have not fully unpacked, so they compensate with step-by-step instructions that fill the gap. The fix is to spend five more minutes on your own thinking before the delegation conversation — not to control the how more tightly.

2. Define done before the work starts

The single biggest source of rework in engineering and product work is ambiguity about what “finished” means. Both parties think they share a definition. They do not.

A useful definition of done (DoD) answers three questions: what is the output? How do you verify it works? What is explicitly out of scope? The third one is the most neglected and the most valuable. An explicit out-of-scope list tells the person that the things you did not mention are not oversights — they are deliberate choices — and frees them to not do those things without having to check.

Write it down. A two-sentence definition in a ticket comment or a Slack message is not bureaucracy. It is the cheapest insurance policy available.

3. Set guardrails, not steps

Guardrails are the constraints within which the person can move freely. They are not the same as instructions. Instructions specify the path. Guardrails mark the edges of the road.

Useful guardrails are: budget limits, technology constraints (“we are not introducing a new dependency here”), compliance requirements, timeline hard stops, and stakeholders who need to be informed before a decision is made. Everything else is the engineer’s call.

The test for whether something is a guardrail or a preference: if the person chose differently, would something actually break, or would you just have done it differently yourself? If it is the latter, it is a preference. Keep your preferences out of guardrails. They belong in a retrospective conversation, if anywhere.

4. Agree on check-ins, then hold the line

Once the work starts, the most valuable thing you can do is stay available and stay out of the way. Those are not contradictory. Agree upfront on the check-in rhythm: a brief daily async update if the task is short, a mid-point sync if it is a multi-week effort, and a clear escalation path for blockers that cannot wait.

Then do not show up between those touchpoints to see how it is going. Every unscheduled check-in sends a signal: I do not trust the cadence we agreed on, which means I do not fully trust you. The person on the receiving end of enough of those signals starts to optimise for making you comfortable rather than doing the work well.

This is the hardest part. Not because the impulse to check is pathological, but because the feedback loop for restraint is slow. You hold back, the work goes fine, and there is no dramatic moment of success to reinforce the behaviour. The reinforcement comes months later when the person tells you they actually enjoy working on your team, when your throughput increases because you are not a bottleneck, when people bring you problems proactively because they trust you will not take over.

The keyboard test

Here is a simple heuristic for the moments when you feel the pull to jump in: if you took over this task right now, what would you get and what would you give up?

You would get a faster resolution to your immediate anxiety and output that looks exactly like what you would have built. You would give up the person’s ownership of the outcome, their growth from working through the hard part themselves, your own time and attention, and the trust you had built. In almost every case, the trade is not worth it.

The exceptions are real — a genuine production crisis, a compliance risk that requires your specific authority to resolve, a clear skills gap that needs immediate coaching. In those cases, step in, be transparent about why you are stepping in, and make it temporary. “I am going to pair with you on this part because the risk level means we need two sets of eyes” is very different from silently pulling the ticket back to yourself.

What this looks like in practice

You take on a new team lead role. One of your engineers is responsible for a service you do not know well. Your instinct, especially early, will be to ask a lot of questions. That is reasonable. But watch whether the questions are for your understanding or for approval-seeking in reverse — you asking questions as a way of staying close to every decision without explicitly owning it.

Try this instead: ask one good question at the start (“what’s the biggest uncertainty you’re navigating on this?”), read the ticket, and then send one message before they start: the outcome you need, the one hard constraint, and when you want to hear from them next. Then close the tab.

You will feel the discomfort of not knowing exactly what is happening. That discomfort is the work of being a manager rather than an individual contributor. It does not go away completely. You just get better at tolerating it, and at building the trust that makes it manageable.

The engineers who can tell you in their first week that their manager gave them real work and trusted them to figure it out — those engineers are the ones who stay and compound.