The Multiplier Effect: Why I Keep Mentoring as a Core Output

The views expressed here are my own and do not represent those of any current or former employer.

Early in my career, mentoring felt like a side quest. Something you did when you had spare time, which meant it rarely happened. Projects were the main output. Mentoring was extra credit.

I was wrong, and it took me years to see why.

The problem with being the person who can solve any infrastructure problem is that you become the person who has to solve every infrastructure problem. You become a dependency. Teams wait for your input. Decisions bottleneck on your calendar. You work harder, but the organization doesn’t get faster. You’ve accidentally made yourself a single point of failure.

The fix isn’t delegation. It’s multiplication.

What Multiplication Looks Like

Over my career, I’ve mentored more than twenty engineers across infrastructure, security, and SRE. The pattern I keep coming back to is simple: can the team make good decisions without me in the room?

That’s the metric. Not “did I help someone get promoted” (though that happens). Not “did I do a good deed” (though mentoring is rewarding). The metric is: did I create decision-making capacity that didn’t exist before?

Concretely, this means:

Teaching the “why” behind architectural decisions. When I review a design, I don’t just say “use VPC peering instead of Transit Gateway here.” I explain the cost model, the traffic patterns that make peering better in this case, and the signs that would indicate it’s time to reconsider. Next time, the engineer can make that call independently.

Pairing on hard problems instead of solving them alone. When a junior engineer needed to build a concurrency feature for our DR tooling, I could have written it myself in a fraction of the time. Instead, I guided them through the design, reviewed their iterations, and let them ship it. The feature works. And now I have an engineer who understands DR concurrency patterns and can build the next one without me.

Leading workshops that are working sessions, not lectures. The workshops I run bring real problems into the room. Someone has a VPC that needs redesigning. Someone else is struggling with IAM patterns for multi-account. We solve those together. The learning is contextual and immediately applicable, not theoretical.

The Math That Changed My Mind

Here’s the math that converted me from “mentoring is nice” to “mentoring is core output.”

If I spend ten hours a week solving problems directly, I generate ten hours of output. If I spend three of those hours mentoring others to solve similar problems, I initially lose three hours of direct output. But within a few months, those engineers are each solving problems independently, creating maybe five hours of output per week that didn’t exist before. At twenty mentees over several years, the compounding becomes enormous.

The mythical “10x engineer” impact isn’t about writing code ten times faster. It’s about getting several of your peers to stop wasting time via better processes, better tooling, and better judgment. That’s what mentoring produces.

What Senior ICs Get Wrong About Mentoring

The most common mistake is treating mentoring as knowledge transfer. The goal, in this framing, is to download your knowledge into someone else’s brain — explain Transit Gateway pricing, walk through IAM policy syntax, share the checklist you use for security reviews. That’s useful, but it’s not actually mentoring. It’s documentation with a human voice.

Real mentoring is about developing judgment. Knowledge is “this is how Transit Gateway pricing works.” Judgment is “given these traffic patterns, here’s why peering is the better choice, and here’s when I’d reconsider.” The difference matters enormously. An engineer who knows the facts will still come back to you every time they face a novel situation, because they don’t have the mental model to work from. An engineer who has developed judgment makes decisions you’d be proud of, without you in the room. You can’t teach judgment through documentation. You teach it by making decisions together — out loud, with the reasoning visible — until the reasoning becomes theirs.

The second mistake is only mentoring people on your own team. I understand the logic: your team is where you have the most context, the most shared history, the most immediate leverage. But the biggest multiplier comes from cross-team mentoring. When I work with engineers on the security team to help them understand networking patterns, or spend time with SREs on cloud cost models, I’m creating alignment across organizational boundaries that would otherwise produce friction. Those engineers carry better mental models back into their own teams’ decisions. They stop asking the same foundational questions in cross-team meetings. They catch problems earlier because they actually understand the adjacent system. The compounding effect of cross-team knowledge is real and it’s underused.

The third mistake — and this one is almost universal — is stopping when things get busy. Mentoring is the first thing senior ICs drop when projects get intense. I’ve done it. It’s a rational short-term decision and a terrible long-term one. The logic is backwards. The reason you’re busy is that too many decisions require your direct involvement. Cutting mentoring when you’re overloaded means you stay overloaded indefinitely. The engineers who could eventually take load off you never develop the capability to do so, because you disappeared every time the work got hard. Being too busy to mentor is a symptom of the exact problem that mentoring solves.

The Culture Effect

There’s a secondary benefit that’s hard to quantify but easy to feel: when the most senior person on the team is visibly investing in others, it changes the culture.

I think about this a lot in the context of engineers from underrepresented backgrounds. As a mentor at /dev/color, I’ve seen how much it matters to work in an environment where someone senior is actively pulling you forward, not just tolerating your presence. When I pair with a junior engineer on a hard problem and let them drive, when I admit I don’t know something and we figure it out together, when I publicly credit their contributions, it creates a culture where everyone feels permission to learn out loud.

That kind of environment retains talent. And retaining good engineers is, frankly, worth more than any single technical decision I’ll make in a quarter.

The Bottom Line

I keep mentoring as a core output, not a side quest, because it’s the highest-leverage thing a senior IC can do. I deliver infrastructure, and I leave behind stronger engineers and systems that don’t require my constant presence to remain correct.

The only sustainable scaling strategy is multiplying competent decision-makers. Everything else is just working harder.