Why I Mentor: The Most Durable Work I Have Ever Built

The message arrived without ceremony.

It was from someone I had worked with years earlier, from a team built around software that no longer existed in the form we knew it. The framework had been replaced. The architecture had evolved. Most of the decisions that once occupied our days had become irrelevant, absorbed by a new system or forgotten by a new organization.

The person writing to me had not forgotten one of our conversations.

I will not reproduce the message. It belongs to the person who sent it. What mattered was that they had carried a question from that conversation into later work. They had used it while making decisions of their own. Eventually, they had offered a version of it to someone they were mentoring.

I sat with that for a while.

During nearly 30 years in technology, I have shipped systems, grown teams, resolved incidents, interviewed hundreds of candidates, hired across countries and cultures, and held roles ranging from junior engineer to CTO, VP of Engineering, Solutions Director, and executive. Some of that work was consequential. Some of it kept companies operating, gave people jobs, or made difficult things possible.

Much of the software is now gone.

The question is still moving.

Thesis: The most durable work of my career is not the software I built, but the judgment, confidence, and generosity that people I mentored now carry into work I will never see.

Why now: Technology's half-life keeps getting shorter while the need for mature judgment, humane leadership, and people who can develop others keeps increasing.

Who should care: Engineers becoming leaders, experienced technologists reconsidering impact, and anyone whose influence is measured too narrowly by what they personally produce.

Bottom line: Mentorship matters when it increases another person's ability to choose, decide, and lead without depending on the mentor's answers.

I used to measure impact in systems

Early in my career, impact was visible.

Code compiled or it did not. A release shipped or slipped. An incident ended. A system handled the load. A customer received something that had not existed before. There was comfort in the physicality of the result, even when the work itself was digital. I could point to the thing and say, _I helped build that._

As my responsibilities grew, the units changed. I measured impact through architecture, reliability, hiring, delivery, and eventually through the performance of an organization. A well-designed platform could multiply the work of many teams. A good technical decision could remove years of avoidable complexity. A careful hire could change the confidence and capability of an entire group.

Those are legitimate forms of impact. I still care deeply about them.

But technology teaches impermanence with unusual efficiency.

The language that made someone employable becomes the language nobody wants to maintain. The architecture everyone debated becomes a migration plan. The product that felt urgent becomes a line in an archive. The company changes direction, is acquired, disappears, or simply forgets why a particular system was built the way it was.

Good software can create enormous value without lasting forever. In fact, the responsible end of some software is deletion. A system has done its job, a better model has arrived, and the code should leave without demanding a monument.

For a long time, I understood this intellectually while still measuring myself against artifacts. I wanted to build the system that lasted, solve the problem others could not solve, or be the person trusted with the decision that mattered.

Then the careers around me became longer than the products.

I watched nervous graduates become engineers other people relied on. I watched people who believed they had somehow entered the room by mistake learn that they belonged there. I watched engineers who once needed reassurance begin making decisions I would not have made, for reasons I could respect. Some became architects, CTOs, managers, founders, and leaders. More important, some became the person another anxious engineer could approach without fear of being made small.

The artifact changed.

Instead of asking what I had built, I began asking what became more possible because we had worked together.

That is a harder question. It gives me less control over the answer. It also feels closer to the truth.

Answers solve the problem in front of you

When someone early in their career brings a problem to an experienced engineer, giving the answer is tempting.

The answer is often clear. Time is short. The experienced person can see the failed abstraction, missing boundary, or operational risk before the other person has finished explaining it. Providing the solution feels efficient and helpful.

Sometimes it is exactly what the moment requires. During an incident, nobody needs a philosophical exploration of packet loss when a direct instruction will restore service. A person who lacks necessary context deserves the context, not a test.

But answers have a short range.

They solve the problem as I understand it, inside constraints I may have inferred, using experience the other person cannot yet inspect. If I give only the conclusion, I may produce correct code and a more dependent engineer.

I learned this gradually because, in the beginning, being the person with the answer was part of how I understood seniority. I had worked hard to acquire knowledge. Offering it quickly looked like competence. It was also reassuring. If another person followed my approach, I could predict the result.

Mentorship asks for a different kind of patience.

By mentorship, I mean a relationship that increases another person's ability to choose and act without me. That may include teaching, advice, feedback, advocacy, listening, challenge, or simply staying with a difficult question long enough for someone to discover what they already understand.

The useful move is often not to withhold the answer. It is to expose how an answer is made.

What is the actual problem? Which constraint is real, and which one have we inherited without examining? What would need to be true for this approach to work? What would make the decision reversible? Who carries the failure if our assumption is wrong? Which part do you understand well enough to trust your judgment, and where do you need evidence?

These questions do more than produce architecture.

They teach a person where to place attention. They make assumptions visible. They show that uncertainty can be handled without pretending it has disappeared. Over time, they become part of someone else's way of thinking.

That is what the message years later helped me understand. I had not transmitted a solution. I had contributed to a question that could survive the original problem.

Technical growth is also character development

Technology likes skills that can be named.

Languages, frameworks, protocols, platforms, design patterns, and tools are legible. They fit into job descriptions and interview loops. They can be tested, compared, and turned into a learning plan.

The qualities that determine whether those skills become useful in a real organization are harder to score.

Curiosity matters because the first explanation is often incomplete. Humility matters because systems punish certainty that cannot absorb evidence. Communication matters because an architecture nobody understands cannot be maintained by the people expected to live with it. Integrity matters because technical work creates opportunities to hide risk behind complexity. Reliability matters because trust is built through promises kept when the work is boring as well as when it is impressive.

Kindness matters too.

I do not mean politeness used to avoid conflict. I mean the discipline of remembering that the person asking a question is not the problem they brought. A review can be rigorous without making the author regret participating. Feedback can be direct without using humiliation as evidence of standards. A senior engineer can say, “I do not know,” and make the room more intelligent by allowing everyone else to stop performing certainty.

Taste may be the hardest quality to explain. It is the ability to feel when a system contains more ideas than the problem deserves, when a technically valid choice will create a human maintenance cost, or when an elegant abstraction is concealing an awkward truth. Taste grows through exposure, consequence, comparison, and reflection. It cannot be installed through a single answer.

Judgment brings these qualities together.

A person with judgment can make a decision before all information is available, explain the tradeoff honestly, notice when the context has changed, and revise without treating correction as humiliation. That capability is more valuable than any tool I could teach because it determines how every future tool will be used.

This is why mentoring has become inseparable from engineering for me.

The code is part of the work. The person who will decide what code deserves to exist is the longer project.

Belief can become practical infrastructure

Some of the most capable people I have worked with did not initially experience themselves as capable.

They arrived careful, observant, and convinced that everyone else understood a set of rules they had somehow missed. They interpreted unfamiliarity as evidence that they did not belong. They could see gaps in their own knowledge with painful clarity while assuming the confidence around them came from complete understanding.

Telling someone to be confident rarely helps. Confidence offered as an instruction becomes another standard they believe they are failing.

What helped more was making the evidence visible.

This decision was yours. That question changed the direction of the review. You noticed the risk before I did. You recovered after the mistake and improved the system. You do not need to know everything in order to know this part well.

Belief becomes useful when it is specific enough to test.

I have seen a person begin speaking differently after receiving evidence that their judgment was already operating. I have seen someone stop apologizing before every contribution. I have watched an engineer who once asked permission for routine choices become the person who could hold a consequential disagreement without either collapsing or dominating.

I did not give those people confidence. That language would claim too much.

At best, I helped remove a distortion that made their existing capability difficult for them to see. I gave feedback, context, responsibility, and sometimes advocacy. I said their name in rooms where an opportunity was being discussed. I challenged a conclusion when the reasoning was thin. I tried to create enough safety for them to test a larger version of their own judgment.

Then they did the work.

That distinction is essential. Mentorship is not the production of a person. It is participation in an environment where a person can become more fully responsible for their own development.

My mistakes belong in this story

It would be easy to write about former colleagues who became leaders and allow their later titles to reflect well on me.

That would be emotionally satisfying and ethically incomplete.

I have made mistakes in hiring, management, promotion, and communication. I have hired technical ability while underestimating the damage arrogance can do. I have explained a decision when I should have listened longer. I have sometimes mistaken my ability to see a problem quickly for an obligation to take it over. I have given feedback from the altitude of the role rather than from the position of the person who had to use it.

There were moments when my standards improved the work and reduced the person.

No leader should be proud of that exchange.

Technical environments can excuse a surprising amount of cruelty if the person producing it is considered brilliant. I used to believe that exceptional output could compensate for corrosive behavior if expectations were managed carefully enough. Experience changed my mind. A person who makes everyone around them less willing to ask, challenge, disclose risk, or try is degrading the system, regardless of how impressive their individual contribution appears.

Arrogance is especially expensive because it interrupts learning while advertising certainty. I no longer see it as a rough edge around excellence. It is a limit on excellence.

My own failures also changed how I mentor.

I am less interested in whether someone adopts my preferred style. I am more interested in whether they can explain the consequence of their choice. I am more careful about the difference between a pattern I recognize and a conclusion the current evidence supports. I try to notice when positional authority is making agreement look more voluntary than it is.

I do not always get this right.

That is not a ritual disclaimer. It is part of the method. A mentor who cannot be corrected teaches the most dangerous lesson possible: that seniority converts interpretation into fact.

If I want another person to become comfortable changing their mind, I have to let them watch me change mine.

No mentor gets to claim another person's life

The evidence on mentorship uses the language of a working alliance, not a heroic intervention.

The National Academies' synthesis on effective mentorship in STEMM describes mentorship through career and psychosocial support: guidance, skill development, sponsorship, listening, encouragement, and role modeling. It also emphasizes that mentorship can take many forms and that one mentor is unlikely to possess everything another person needs.

That is a useful corrective to the mythology of the wise senior figure who transforms a promising junior through the force of personal insight.

People grow through families, friends, peers, managers, teachers, opportunities, exclusions, accidents, choices, failures, and their own sustained effort. Some people become extraordinary despite the leaders around them. Some receive excellent mentorship at the wrong time or in the wrong form. Some need access more than advice. Some need a manager to stop interfering.

Power complicates every mentoring relationship.

If I can influence someone's pay, promotion, project, reputation, immigration status, or access to opportunity, my guidance does not arrive as neutral wisdom. Even a casual preference can sound like a requirement. The person may agree because disagreement feels expensive.

Responsible mentorship has to leave room for refusal.

It must allow someone to choose a path I would not choose, develop strengths I do not possess, and seek mentors whose experience corrects my blind spots. It should increase the number of meaningful options available to them, not narrow those options around my approval.

This is also why I resist using another person's title as my score.

I am proud when someone I worked with becomes a CTO, architect, founder, or respected leader. But the title is theirs. So are the difficult years, decisions, relationships, and sacrifices through which they reached it. My contribution may have mattered. It is not authorship.

The most honest evidence of mentorship is quieter: the person has more agency, uses better judgment, and no longer needs the mentor to validate every consequential choice.

The point is to become unnecessary

Many leaders build organizations that confirm their importance.

Information flows through them. Decisions wait for them. People seek approval because approval is safer than ownership. The leader becomes indispensable and receives constant evidence that they are valuable.

It is a fragile architecture.

A team that cannot think without its leader has not been led into strength. A person who can execute only while the mentor remains nearby has received support without independence. The relationship may feel close, but closeness is not the same as development.

The goal is not disappearance. People still need peers, advisers, friends, and trusted voices throughout a career. I still contact people who helped me decades ago. Independence does not mean isolation.

It means the relationship is no longer organized around dependence.

The engineer can frame the problem, ask for the missing context, make the call, own the consequence, and return for a conversation rather than permission. They can disagree without fearing that the relationship will be withdrawn. They can teach something the mentor does not know.

Eventually, they can create those conditions for someone else.

This is where impact begins to compound.

A question offered to one engineer appears years later in a room I will never enter. A form of feedback that preserved someone's dignity becomes the way they conduct a difficult review. The confidence to admit uncertainty becomes permission for another team to surface risk before it becomes failure.

None of it carries my name.

That is part of what makes it valuable.

Software becomes legacy code and then, if we are fortunate, disappears. Organizations forget old structures. Titles belong to a period. Even the systems that outlive us eventually become constraints for someone else to remove.

People continue into chapters we cannot design.

The message that opened this essay did not make me feel immortal. It made me feel appropriately small. Something useful had passed through a relationship, changed in the possession of another person, and continued without needing me.

That is why I mentor.

The greatest architecture I can leave behind is another engineer who no longer needs my answers and has learned to create the conditions in which other people can discover their own.