How to Delegate as an Engineering Manager: A Worked Example

A useful delegation agreement names the result, the owner, the timing, and the decisions that person can make. It also explains why the work matters and when to ask for help.

When I first became a manager, the difficult part was accepting that work might not be done exactly as I would do it. At other times I gave too little context, then felt disappointed when the result did not match an expectation I had never explained. I have made both mistakes.

I first encountered the structure below during leadership training. I use Why, What, Who, and When to expose missing expectations, then add decision boundaries and check-ins appropriate to the work.

What is Delegation?

Delegation is an agreement to take responsibility for a result, with enough context and authority to act. It is more than moving a task into somebody else’s queue.

Consider this illustrative handoff:

Can you look into upgrading the database?

Does that mean research the options, write a proposal, or perform the migration? Does it include permission to change production? The engineer should not have to discover your answers after doing the work.

The Four Steps of Effective Delegation

1. Why – Motivation

Explain the reason for the work and the decision it will support. In our example:

The database version is approaching the end of our agreed support window. We need to understand the upgrade risks before committing the next quarter’s capacity.

That gives the engineer a way to distinguish useful investigation from interesting but unrelated research. Explain any fixed constraints and what is still open to discussion.

2. What – The Result

Describe the deliverable and what makes it useful:

Prepare a recommendation covering compatibility risks, options, a proposed test and rollback approach, and an effort range with assumptions. We need enough detail to decide whether to schedule the upgrade next quarter. This assignment does not include a production migration.

You have specified the result without requiring the engineer to follow your exact research process. Check the level of detail together rather than assuming “a recommendation” means the same thing to both of you.

3. Who – Ownership

Name the owner and confirm capacity:

Would you take ownership of the recommendation? You can involve SRE and the service owners. Let’s agree what comes off your current workload to make room.

Ownership does not mean working alone. It means somebody coordinates the work, notices dependencies, and brings the result or an emerging risk back into the conversation.

If several teams share responsibility, a RACI matrix may help clarify their contributions. For a small handoff, a named owner may be enough.

4. When – Deadline

Agree on a date based on the decision the work supports:

We need the recommendation for planning on Thursday. Is Wednesday afternoon realistic for a reviewable version? Which dependencies could prevent that?

A deadline should expose a constraint, not conceal an impossible request. If the estimate does not fit, change the scope, timing, or capacity explicitly.

Add Decision Boundaries

The Four W questions still leave one important gap: what can the owner decide?

For this example, the engineer can organise research and agree on test work within the team’s existing environments and policies. Production changes, new spending, and commitments from another team require the relevant authorisation.

Write those boundaries in the handoff. Use the Decision Tree for decision authority when “keep me informed” is too vague to guide action.

Capturing the Action Item

Put the agreement in the team’s normal work tracker. Here is a compact version of the example:

Outcome: Database upgrade recommendation for next-quarter planning.

Owner: The engineer who accepted the handoff, with input from SRE and service owners.

Due: Wednesday afternoon, before Thursday’s planning decision.

Boundaries: Research and agreed test work; no production changes, purchasing, or promises on behalf of another team.

Check-in: Monday, to review dependencies and whether the scope still fits.

Escalate early: Missing access, unavailable reviewers, or evidence that the recommendation cannot be ready in time.

Ask the owner to explain the outcome and next step in their own words. That is a check on the clarity of your request, not a memory test.

Following Up

Agree on check-ins while there is still time to address a problem. A reminder after the deadline can help close an overdue item, but it is not a sufficient risk-management plan for consequential work.

At Monday’s check-in, ask what has been learned, which dependency matters most, and whether anything changes the scope or date. You should leave with a decision or support action, rather than taking ownership back through a long list of instructions.

If the work is a small, familiar task, you may only need the completion update. Match follow-up to uncertainty and impact instead of inspecting every assignment at the same frequency.

The Delegation Process in Practice

Suppose the service owner cannot review the proposal before Wednesday. The engineer raises that on Monday. You can now agree on a narrower recommendation with an explicit unresolved risk, move the planning decision, or arrange another qualified reviewer.

That is useful follow-up: the owner surfaced a constraint, and the two of you made the trade-off visible. Quietly completing the work yourself would hide the capacity problem and teach the team to rely on your rescue.

Common Mistakes in Delegation

Watch for three gaps. An outcome without capacity creates an additional commitment nobody has made room for. Responsibility without authority sends every decision back to you. An agreed deadline without an escalation route encourages surprises when dependencies fail.

Also check your own response to a different method. If the owner meets the agreed result within the boundaries, needing to do it your way may be a preference rather than a requirement.

Why Effective Delegation Matters for Leadership

A good handoff helps someone practise judgement with appropriate support. It can also reveal where your team depends on one person’s knowledge or approvals.

If you already delegate clearly but still make every meaningful decision, the next problem is delegating ownership, not just tasks.

Use It on One Real Handoff

Choose one piece of work this week. Agree on the Four W questions, decision boundaries, and the earliest useful check-in. Then ask what is still unclear. Improve that agreement before turning it into a template for every task.