Lesson 09 of 10 · Part 3 — People and outcomes
Mentoring and growing engineers
Grow the engineers around you: delegate real work with the right support, use pairing and reviews to teach, give feedback that helps, create stretch opportunities, and spread knowledge so the team doesn't depend on any one person, including you.
Why it's part of the job
A lead's impact grows with the team's ability. Growing engineers also removes single points of failure: if only you can upgrade the clusters, you are the bottleneck, and the team is at risk when you're away.
A good mentor teaches someone to ride a bike: running alongside holding the seat at first, then just a hand nearby, then waving from the pavement. Holding the seat forever means they never learn, and letting go on day one means a scraped knee and a bike in the garage.
Delegate real work, with support
| Level | You give | Example |
|---|---|---|
| New to the area | A defined task, pairing, close check-ins | "Pair with me on this node pool upgrade" |
| Growing | A problem and constraints, check-ins at milestones | "Design the backup approach for StatefulSets; let's review the draft Thursday" |
| Experienced | A goal and the context; they come to you when needed | "Own the Gateway API migration this quarter" |
Match the level to the person and the task; someone senior in one area may be new in another.
Teach through everyday work
- Pairing on real problems, with them at the keyboard.
- Design reviews where you ask questions instead of giving answers ("what happens if this zone fails?").
- Code reviews that explain the why, separate must-fix from nice-to-have, and recognise good work.
- Incident shadowing: let people commander a minor incident with you as backup.
Feedback that helps
Use situation → behaviour → impact, soon after the event:
"In yesterday's design review (situation), you raised the IP exhaustion risk with numbers (behaviour). That changed the decision and saved us a migration later (impact)."
"In the rollout this morning (situation), the change went to all clusters at once (behaviour), so when it failed, every region was affected (impact). Next time, what would a safer rollout look like?"
Give positive feedback often and specifically; give corrective feedback privately and with a question that invites their thinking.
Stretch opportunities
Help each engineer find work slightly beyond their comfort: presenting a design, owning a cross-team change, writing an ADR, running a game day. Agree a growth goal per person (with their manager) and connect work to it.
Spread knowledge
- Rotate who does upgrades, on-call leads and releases.
- Write runbooks and short guides as part of the work, not after.
- Short internal talks or recorded walkthroughs of tricky systems.
- Check the bus factor: for each critical system, can at least two people run it alone?
Try it: a growth plan for one engineer
- Pick one engineer and ask what they want to get better at this year.
- Find one real piece of upcoming work that stretches them in that direction.
- Agree the support level from the table, and check-in points.
- After two weeks, give specific feedback using situation–behaviour–impact.
- List your team's critical systems with the people who can run each; plan pairing where only one name appears.
Going deeper: growing other leads
The best sign of a good lead is that others can step into the role. Share your thinking out loud, invite people into decisions, and hand over parts of the lead role (running design reviews, owning the roadmap theme) deliberately.
Recap
- Growing engineers is how a lead scales and removes single points of failure.
- Delegate real work at the right support level.
- Teach through pairing, reviews and incidents.
- Feedback: specific, timely, situation–behaviour–impact.
- Stretch work and spread knowledge so no system depends on one person.
This site is a public version of my personal engineering knowledge hub. It intentionally excludes confidential company information and internal operational details.