Delegation and mentoring
Offline stock counts is too big for you to build alone, and if you try, the team stops growing while you become the bottleneck. This lesson shows you how to hand over real work with the right amount of freedom, how to support each engineer according to how ready they are for that task, and how to grow people on purpose with pairing, feedback and a plan per person.
By the end you can
- Write a delegation brief that hands over an outcome, the context and the decisions that are theirs
- Set a level of delegation for each decision, from "I tell you" to "you decide on your own"
- Match your support and check-ins to a person's task-relevant maturity, and pick stretch assignments that stretch without breaking
- Pair to teach, and give feedback with Situation, Behaviour, Impact
- Write a mentoring plan for each engineer, and notice and share the team's glue work
The everyday picture
Think of a driving instructor. On the first lesson, the learner drives in an empty car park, and the instructor's foot hovers over the second brake pedal. A few weeks later, they drive on quiet streets and the instructor only speaks at junctions. Later still, on busy roads, the instructor stays silent unless something dangerous happens. The instructor never grabs the wheel to show off, and never sends a beginner onto the motorway on day one.
Notice two things. The amount of control the instructor keeps depends on the road as much as on the learner: a learner who parks perfectly may still be a beginner at night in heavy rain. And the instructor's goal is to become unnecessary. Leading engineers works the same way. You hand over the wheel step by step, you choose how closely to watch for each kind of road, and you measure yourself by how well the team drives without you.
Hand over real work, with the outcome and the context
Andy Grove, who ran Intel, wrote in High Output Management (1983) that a manager's output is the output of their team plus the teams they influence. The same is true for a tech lead. Once you lead five engineers, the number that matters is what the six of you ship and how much better the five get, and your own commits are a small part of that. If you keep the hardest code for yourself, you also put yourself on the critical path while meetings, reviews and questions pull you away from it (What a tech lead is (and is not)).
What to delegate. Hand over work that someone can grow on and that matters to the product. Keep, for now, the work only you can do: setting technical direction, decisions that cross teams, and the calls that are hard to undo. A common mistake is to delegate only the chores (upgrading libraries, fixing flaky tests) and keep every interesting problem. People notice, and they stop offering.
How to hand it over. Write a short delegation brief. It takes 20 minutes and saves weeks of misunderstanding. It has seven parts:
- Outcome: what is true when the work is done, in terms you can check. "A count survives a Wi-Fi drop and syncs once, with no lost or duplicate lines."
- Why it matters: the product goal behind it, so the person can make good trade-offs without asking you.
- Context: what you already know. Past attempts, constraints from other teams, the people who care.
- Limits: the things that are fixed, such as the API contract, the pilot date or the devices.
- Decisions: which ones are theirs, and which ones need you (the next section).
- Check-ins: when you will look at progress together, and what you want to see.
- Help: who to ask, and how much of your time is theirs each week.
Four failures are common. Handing over steps instead of an outcome: the person follows the steps, learns little, and comes back the moment a step fails. Dumping and disappearing: Grove's warning was that delegation without follow-through is abdication. Taking it back at the first problem: the person learns that ownership is temporary. Hidden expectations: you had a design in your head and judge theirs against it. If you have a strong view, write it into the brief as a limit or a suggestion before they start.
Quick check
Sam owns the sync engine. Two weeks in, his retry approach differs from the one you would have chosen, but it meets every part of the brief. What do you do?
The brief defined what good looks like, and his design meets it. Asking him to write down the trade-off keeps the reasoning visible and teaches you both. Rewriting it or ordering a switch tells Sam that the real brief was "guess what I want", and he will stop deciding. Taking it back for a design that works is the "taking it back" failure.