Working with people
Building a mentor bench
Several partial relationships beat one oversubscribed senior. Split craft, career, domain and peer. Cap how many people you mentor deeply.
Relying on one senior creates a bottleneck and a single point of disappointment when they get busy. Build a small bench deliberately.
You do not need formal agreements with all of them. A quarterly lunch plus async questions can be enough. Write down who is good for what so you stop defaulting every question to the same oversubscribed staff engineer.
Walking through four seats
- Craft mentor — stronger at code, reviews, design taste. Meet when you have a draft PR or design.
- Org / career mentor — understands leveling, politics and how promotions actually happen here. Meet monthly.
- Domain mentor — deeper in the system you are entering (data, mobile, infra). Office hours as needed.
- Peer mentor — someone at your level at another company or team; lower stakes, high honesty.
When you are oversubscribed as a mentor, protect quality: cap active mentees (often one or two deeply), point others to docs and office hours, and sponsor publicly when you cannot coach privately.
Reverse mentorship — learning from someone newer about a tool, generation of users or corner of the stack you do not touch — keeps seniors from fossilizing. Ask a new hire to teach the team how they found the docs confusing; pay them in attention, not just thanks.
Peer circles (three to five engineers at a similar level, meeting monthly) fill gaps formal mentors cannot: honest talk about compensation bands, manager dysfunction, or "is this normal?" without political risk. Keep a light structure: each person brings one dilemma; others ask questions before advice; no status updates. Will Larson and others recommend learning circles for staff-level judgment; the same format works earlier if you keep confidentiality.
Example
Every question currently goes to the same staff engineer. Rewrite the routing: PR taste → craft mentor; "is this packet enough?" → career mentor; a Kafka failure mode → domain mentor; "is this manager-normal?" → peer circle. The staff engineer gets their time back. You get better answers.
Common mistakes
- Mentor hoarding: waiting for one perfect senior.
- Clone factory: pushing others to copy your path. Ask about their goals first.
- Saying yes to every mentee until quality collapses.
Check yourself
You default every question to one staff engineer. What do you do?
Route by seat: craft, career, domain, peer — and write the routing down.
You already mentor two people deeply. A third asks. What is a kind no?
Cap at two. Offer docs, office hours, or a public intro — not "ping me anytime."
Key takeaways
- A small bench beats one hero. Topic-specific asks.
- Four seats: craft, career, domain, peer.
- Reverse mentorship and peer circles fill gaps formal mentors cannot.
- Cap deep mentees. Point others at docs and sponsorship.
Further learning
Next, the promotion-shaped part: sponsorship and growing others.
StaffEng (Will Larson)Staff Engineer: Leadership beyond the management trackStaff Engineer: Leadership beyond the management track
Related
Mentorship: getting it and giving it
Distinguish mentors, coaches and sponsors — then ask well, mentor juniors and grow others as an SDE2.
Mentors, coaches and sponsors
Mentors advise, coaches question, sponsors put reputation on the line. You need a mix, not one perfect person.
Asking for mentorship
Ask with a bounded cadence, an agenda and a specific question tied to an artifact. Vague "be my mentor" contracts get declined.