Systems & Organizations
The “Maverick Mentor” Paradox
When a senior engineer spends half the week answering ad-hoc questions, the team's delivery cadence quietly stalls.
2026-08-061 min read
Maverick mentors are the unofficial experts everyone routes around the org chart to reach. Their value looks self-evident — any blocked teammate gets unblocked in minutes — but the arithmetic underneath is queueing math, not generosity. A single expert answering unscheduled questions is a shared server with random arrivals, and every request that lands while they are mid-thought joins a queue nobody is measuring. As that server approaches full utilization, waiting time does not creep up in proportion; it climbs steeply, which is why a mentor who feels merely busy produces delays that seem wildly out of scale with the size of the asks.
At a mid-size e-commerce platform, a senior data engineer started fielding a few dozen quick-look requests a week. Each one cost him a few minutes of talking and far longer finding his place again in the pipeline he was building. His own deliverable slipped two sprints in a row, and the team's completed-ticket count, which had risen every iteration for a quarter, flat-lined. Nobody had gotten worse at their job; the work had simply been rerouted through one person's attention. The tell was that his calendar looked open while his week was full.
The paradox resolves when mentorship is treated as a scheduled service with a stated capacity rather than an always-on duty. Fixed office hours convert random arrivals into batched ones, which is the cheapest intervention queueing theory offers. A cap on concurrent mentees keeps the office hours themselves from becoming the next bottleneck. And the constraint does something interruption never does: forced to answer five people at once, the mentor writes the answer down, and a documented pattern serves everyone who asks next month. The expertise stops being a person you have to catch and becomes an artifact you can find.
Key insights
Unscheduled expert time behaves like a queue: as utilization nears capacity, wait times climb far faster than the workload grew.
Batching interruptions into office hours costs the mentor less than the interruptions did, and produces documentation as a side effect.
Why it matters
Ignoring the queue turns your most capable engineer into a single point of failure for everyone else's delivery date.
Informal-only knowledge transfer means the expertise walks out the moment that person does, and nothing on the team gets faster in the meantime.
Use this tomorrow
1Ask your most-interrupted engineer to log every unscheduled request for one week — a tally mark and a rough minute count — then add up the total hours before the next sprint planning.
2Block two 45-minute office-hour slots on that person's calendar, announce them in the team channel, and count how many of next week's requests arrive inside those slots versus outside them.
Go deeper
The underlying math is ordinary queueing theory: for any server handling arrivals it cannot predict, average waiting time rises sharply as utilization approaches one hundred percent. That is why the last increment of a busy expert's time is so expensive — loading a person near full capacity does not add a proportional amount of delay, it can multiply it. Treating a human expert as a scheduled resource with deliberate slack is not indulgence; it is the same capacity planning any operations team applies to a shared machine. The uncomfortable implication is that a fully-booked expert is a misconfigured system, not a productive one.
A different angle comes from Fred Brooks's The Mythical Man-Month, which argued that adding people to a late software project makes it later, because communication paths grow faster than headcount does. Hiring more juniors around a single maverick mentor multiplies the number of question-askers without multiplying the number of answerers, so the bottleneck tightens exactly when leadership believes it is being relieved. The fix is to widen the answering capacity — pairing, written patterns, a rotating question-taker — before widening the asking capacity. Scaling a team without scaling the knowledge supply is how growth makes delivery slower.
