Why We Still Invest in Mentorship

No junior engineer was assigned a reading list in the making of this post.

One of our engineers had been fighting the same category of bug for months. Flaky integration tests, always a different test, always some timing thing. They’d gotten very good at fixing them. Fast, and the PR description always explained exactly what had gone wrong.

Then a senior sat in on a screenshare for twenty minutes and said: you’re not fixing flaky tests, you’re fixing a shared fixture that everything writes to.

That was it. That was the whole intervention. Twenty minutes, one sentence, and a problem that had been quietly taxing a sprint’s worth of attention every month stopped existing.

The engineer could have asked a model about any one of those failures and gotten a good answer. They did, often, and the answers were correct. What nobody was going to volunteer was that the answers were all to the wrong question, because nobody else was watching the pattern across months.

Being Productive and Getting Better Are Different Things

This is the distinction that got blurry over the last two years, and we think blurring it is expensive.

An engineer with good tooling can ship real work today without understanding much of why it works. That’s not a criticism. It’s the point of tools. But shipping and growing have quietly decoupled, and a team can look healthy on output for quite a while before anyone notices that nobody’s judgment is developing.

We see it most clearly in reviews. Someone’s code is fine. It’s been fine for a year. It’s also been the same kind of fine, solving the same shape of problem the same way, and when the shape changes they’re stuck in a way that their PR history would never have predicted.

Output tells you what someone produced. It tells you almost nothing about what they could produce next quarter.

Code Review Is Not Mentorship

We believed it was for longer than we should have, partly because it’s convenient to believe. Review is already on the calendar. It already involves a senior looking at a junior’s work. Close enough, surely.

It isn’t, for a structural reason: review sees the artifact, not the reasoning that produced it.

By the time a PR exists, the interesting decisions are gone. The three approaches that got discarded in the first hour, the wrong mental model that made approach two look appealing, the assumption about how the database behaves that turned out to be false but didn’t happen to break anything this time. None of that is in the diff. You can only review what survived.

And the flawed reasoning is the thing worth catching, because it will produce a different bug next month in a file nobody thought to connect.

We still review everything, we just stopped expecting it to do a job it was never shaped for.

You Can’t Ask About a Blind Spot

The obvious objection to all of this in 2026 is that a model is available at 2am, never tired, never condescending, and knows more about your framework than anyone on your team.

All true. We use these tools constantly. They have made the question-shaped part of learning close to free, and that’s a genuine gain. The engineer who used to wait until Monday to ask something now just asks.

But every one of those interactions starts with you knowing what to ask. That’s the constraint, and it’s not a temporary one. A model can challenge an assumption you put in front of it. It cannot walk past your desk, metaphorically, and notice that you’ve been doing something strange for six months. It has no view of you across time. Each conversation starts from nothing.

The things that actually hold engineers back are rarely knowledge gaps. They’re habits. Reaching for the same abstraction every time. Chronically underestimating a certain kind of task. Going quiet when stuck instead of asking, which is a much bigger deal on a fully remote team where nobody can see you go quiet.

None of those are questions, which is exactly the problem. Somebody else has to notice them for you.

Everyone Else Figured This Out Already

It’s a little odd that software treats coaching as a remedial intervention.

No serious athlete stops having a coach after they get good. Musicians who have been performing for thirty years still take lessons. In both cases the coach is frequently less capable than the person they’re coaching, and that’s fine, because the coach’s job isn’t to be better. It’s to see from outside.

Software is the outlier here. We’ve built a culture where asking for a mentor reads as an admission, and where seniority is quietly assumed to mean you’ve graduated from needing one. Our most experienced people have been writing production code since 1997, and they still get more out of an hour of someone watching them work than from most conferences.

Inside the team that’s mostly unremarkable now. It took a while to get there.

Software’s Feedback Is Badly Calibrated

Part of why this matters more in our field than in most: the delay between a decision and its consequence is wildly inconsistent.

Get the syntax wrong and you know in under a second. Get the architecture wrong and it compiles, passes the tests, sails through review, ships, and then costs you a quarter eighteen months later when a requirement arrives that the model can’t absorb. By then whoever made the call has forgotten making it, and the connection between cause and effect is unrecoverable.

You cannot learn from feedback on that timescale. Nobody can. The loop is too long and too noisy.

A mentor shortens it artificially. They’ve already lived through the eighteen months, several times, and can tell you on Tuesday what you’d otherwise find out in 2028. That isn’t wisdom, it’s just exposure somebody already paid for, and it’s about the most useful thing an experienced engineer has to hand over.

We wrote about a client’s velocity metric that broke their team, and that’s the same failure at the organizational level. The consequence arrived far too late to be connected to the decision.

Friction Is Load-Bearing

One thing we’re careful about, because it’s easy to get wrong in the opposite direction.

The instinct with a struggling engineer is to remove the obstacle. It’s faster, it’s kind, and it’s usually the wrong move, because the struggle is where the learning lives. Handing someone the answer produces a working feature and no new capability.

So the useful version is narrower than it sounds. Let people get stuck. Just don’t let them stay stuck on something that has no lesson in it, or stuck in a direction that’s structurally hopeless. The judgment call is whether the friction is teaching anything, and getting that call right is most of the skill.

This is also the failure mode of an always-available assistant. It removes friction indiscriminately. It cannot tell the difference between a struggle worth having and a yak worth shaving, because it doesn’t know what you’re supposed to be learning this year.

Does Everyone Need This?

No, and we’d rather say so than sell it.

If you’re just starting out, a good book and a community will take you further than a mentor will, because the fundamentals are well-documented and you don’t yet have the specific gaps that make one-on-one time worth it. If you have a bounded question, read the docs. If you want a code review, get a code review.

Mentorship earns its cost when the return is a multiple of the time invested, and that’s usually true in exactly one situation: you’re doing this professionally, you’re past the beginner stage, and you’ve hit a ceiling you can’t see the shape of. That last part is the tell. When you can name what you’re missing, go learn it. When you can’t, and you’ve been stuck at the same level for a year, that’s when someone watching from outside pays for itself in a single afternoon.

What We Actually Do

We’ve kept this deliberately unstructured, because every formal mentorship program we’ve seen from the inside became a calendar obligation within two quarters.

What exists at Norveon: nobody works alone on anything for very long, pairing happens by default rather than by request, and our standup is explicitly not a status meeting, which means the hesitation in someone’s voice is audible. That hesitation is usually the signal that someone’s stuck in a way they haven’t worded yet.

The other half is that we hire for it. We’re 14 people. One person who treats questions as an interruption can shut down learning across the whole team, and no program survives that. Nothing in a process document outranks whether the most senior person in the room is visibly still learning.

We’re not entirely sure this holds, by the way. Keeping it informal means the people who ask get mentored and the quiet ones can go a long time without anyone noticing. Someone raises this roughly twice a year and we’ve never landed on a fix that doesn’t turn into the calendar obligation we were avoiding. At 14 people you can paper over it by knowing everyone. We assume that stops working at some size and we don’t know which one.

Working on Arheev turned out to be where we noticed most of this. When the same team ships the same product for a long stretch, you can see exactly who is getting better and who has plateaued while remaining perfectly productive. Those two look identical on a sprint board.

Two years out they don’t look alike at all.

No mentor was assigned via ticket. A few conversations ran long.