Why I Enjoy Mentoring: The Satisfaction of Helping Others Grow

From building software to building people

For a long time I measured a good year by what I built. A network that held up. A platform that launched. A system that scaled. A company that grew enough to be acquired. I still enjoy all of that, and I still write code most weeks, mostly because I like it.

Somewhere along the way, though, I noticed that the moments I remembered best were not always my own. They were the times an engineer I had been working with solved something they could not have solved a few months earlier, and did it without asking me. There is a particular satisfaction in that which is different from shipping something yourself. It is quieter, and it lasts longer.

I enjoy mentoring because watching someone become capable of something they could not do before is as rewarding as building something myself. In engineering and in junior cycling the work is the same: give people context, room to try and support when it goes wrong, until they no longer need me, and then watch them help the next person.

I did not plan to feel this way. As a co-founder I was too busy doing every job myself to think about growing anyone. It was only when the team grew and I had to let go of work, which I have written about in learning to delegate as a technical founder, that I discovered how much I liked seeing other people pick it up.

The goal is independence

The point of mentoring is not to become the person everyone has to ask. If an engineer needs me for every decision, I have built a dependency, and I have also built myself a very tiring job.

What I am trying to grow is judgment. Knowledge is the easy part to share; documentation does that. Judgment is knowing which of three reasonable designs fits this team and this business, when a shortcut is fine and when it will hurt, and when to raise a concern even though it is awkward. That only develops by making decisions, so mentoring means handing decisions over, a little at a time, and being there when they turn out differently than expected.

The best signal that it is working is a little deflating: people stop coming to you. The engineer who used to ask what to do starts telling you what they did and why. Then, if you are lucky, they start explaining it to someone newer. That is the moment I care about most. I describe the stages I try to move people through on the Mentorship page, from asking what to do to teaching someone else.

Junior riders and junior engineers

Outside work, I volunteer with junior riders in the Berkeley Bicycle Club, lead a co-ed amateur team, and help organize the Berkeley Omnium, whose proceeds go to six East Bay youth cycling teams. I expected cycling to be a break from leading engineers. It turned out to be the same job in different clothes.

With a junior engineer, I am trying to build problem-solving rather than hand out answers, so I ask more questions than I answer. I want them to ask questions too, including the ones they worry are obvious, because the obvious ones are where most misunderstandings hide. I want them to understand why a system is built the way it is, not only how to change it, because the why is what lets them make the next decision without me. And I want them to make real decisions and own the outcome, inside limits that keep a mistake survivable.

With a junior rider, the skills are different and the shape is identical. Bike handling and race awareness come from repetition, not from being told. They need to be encouraged to try something hard, like staying with a faster group a little longer than feels comfortable. They learn teamwork and responsibility by riding in a group where other people depend on them holding a line. The difficult races teach the most, and the conversation afterwards matters more than the result. I care more about whether a rider is better than they were last month than about where they finished.

Both groups need patience, and both develop at their own pace. Some engineers get comfortable with production in weeks and some in a year, and neither tells you much about where they will end up. Some riders improve in a straight line and some plateau and then jump. Treating everyone as if they should be on the same schedule is the fastest way to lose the ones who would have been great. I wrote more about the parallels in what cycling taught me about engineering leadership.

You cannot hand someone twenty years

The hardest lesson for me was accepting that some things cannot be taught, only experienced.

I can explain why a migration needs a way back at every step. I can describe what happened the last time I skipped one. I can warn, clearly and in advance, that a design will be painful to change later. And often the person nods, understands the words, and does it anyway, because the words are not the same as the feeling of a two-in-the-morning rollback. I know this because I was that person, and my mentors were patient with me.

So I no longer think my job is to prevent every mistake. That is impossible, and trying makes people timid. My job is to make the mistakes survivable and the lesson clear: a staging environment before production, a review before the merge, a small change instead of a big one, and a conversation afterwards that is about what we learned rather than who to blame.

The skill is knowing which mode the moment calls for. Sometimes I guide, asking questions until the person sees the problem themselves. Sometimes I demonstrate, because watching once is worth an hour of explanation. And sometimes I step aside on purpose and let someone go down a path I would not have chosen, because the cost of being wrong is small and the lesson is worth more than my being right. Cycling is the same. You can tell a junior rider a hundred times not to spend everything on the first climb, and they will learn it properly the first time they cannot hold the wheel on the second one.

Mentoring is also learning

I do not think mentoring runs in one direction. Junior engineers ask questions that expose assumptions I have carried for years. Sometimes the honest answer to “why do we do it this way?” is “because that is how we did it last time”, and a good mentor notices that and changes it. Newer engineers also come in knowing tools and approaches I have not used, and I would be foolish not to learn them.

Young riders do the same thing in a different way. Their enthusiasm for something I have done a thousand times reminds me why I started. Their questions are blunt and often very good. And they are, unsurprisingly, faster than me on most climbs, which keeps the coaching humble.

That curiosity is contagious. After more than two decades I am still learning, still experimenting and still writing code, and I think mentoring is part of why. It is hard to get bored of something when you keep seeing it through someone who is seeing it for the first time. I want people to challenge me, which is why two-way mentoring is part of how I describe the way I work.

Not the smartest person in the room

Mentoring changed how I think about leadership. Early on I assumed a leader should be the person with the best answer. It took me longer than I would like to admit to see that a leader who always has the best answer is usually the reason the team has stopped offering any.

A good leader does not need to know everything. The job is to build an environment where other people can succeed. In practice, that means a handful of ordinary things done consistently. Giving people real opportunities, not just the work nobody else wants. Sharing what I know freely, including the mistakes. Giving feedback that is specific, honest and kind, and asking for it back. Clearing obstacles out of the way, which is often the most useful thing I do in a week. Building trust by doing what I said I would. Noticing progress out loud. And letting people own their work, including the decisions I would have made differently.

The measure of a lead is the team that works without them. If my team can make good decisions when I am on vacation, I have done my job. If everything waits for me, I have not, however busy I look. That idea runs through how I run engineering, and it is why I care more about growing engineers into leads than about how many people report to me.

The part that lasts

Building software is rewarding. Building a company is rewarding. I have done both and would do both again. But software gets rewritten and companies change hands. What someone learns about how to think through a problem, how to own a decision, or how to keep going on a hard climb, they carry with them for the rest of their career or their life.

The greatest satisfaction, I think, comes later and mostly out of sight. It is when someone I worked with becomes the person others go to, and starts doing for them what someone once did for me. At that point what I learned is reaching people I will never meet, through someone I helped. I find that a good thing to have been part of.

Short answers