The Helpful Senior Who Isn’t: Why Your Best Engineers Are Accidentally Breaking Your Team
Or: How Mentorship Became a Trap and Nobody Noticed Because It Looked So Good on Peer Reviews
It was 2:14 on a Wednesday when I watched it happen for the third time that week. A junior engineer pinged their tech lead on Slack, and before the notification sound had finished chiming, the senior had swivelled their chair around, leaned in, and started typing the fix. The junior nodded along, eyes tracking the cursor, absorbing the explanation like a lecture. Fifteen minutes later the PR was up, the junior had “learned something,” and the senior had quietly killed another opportunity for someone to actually grow.
We celebrate this. We put it in peer feedback forms and promotion packets. “Always available. Incredible mentor. The team couldn’t function without them.” And that last part — the team couldn’t function without them — is the tell. We’ve confused being helpful with being needed, and the cost is a generation of engineers who can explain how things work but can’t figure out why they don’t.
The Rescue Reflex
Let’s be honest about what’s happening in most engineering teams. A junior hits a wall. They do what any reasonable person would do — they ask the smartest person in the room. The senior, being competent and well-intentioned, provides a clear, thorough explanation. Problem solved. Story points delivered. Everyone feels good.
Except something critical didn’t happen. The junior never sat with the discomfort of not knowing. Never opened the stack trace and followed it three levels deep. Never formed a wrong hypothesis, tested it, watched it fail, and formed a better one. They got the answer, but they skipped the process of finding it — and the process is where engineering intuition actually lives.
As the educator Maria Montessori observed, “The greatest sign of success for a teacher is to be able to say, ‘The children are now working as if I did not exist.’” We’ve built engineering cultures that produce the exact opposite — teams that work as if the senior must exist, at all times, for anything non-trivial to get done.
You end up with engineers who are technically knowledgeable — they can explain the concepts because they’ve heard excellent explanations — but operationally dependent. They know about things without knowing how to figure out things. And there’s a chasm between those two that no amount of pairing sessions will bridge if the pairing always looks like one person driving and the other watching.
The Senior’s Trap
Meanwhile, the senior is drowning. Their calendar is a graveyard of deep work sessions that never survived the morning. Their Slack is a support ticket queue they never signed up for. They’re permanently interrupt-driven, context-switching between three people’s problems before lunch, and wondering why they haven’t shipped anything meaningful in weeks.
Here’s the paradox that should keep engineering leaders up at night: the seniors who get the best peer feedback might be doing the most organisational damage. The team’s bus factor drops precisely because of someone’s strength. You’ve built a single point of failure out of your best person, and you’ve rewarded them for it.
The basketball coach John Wooden put it well: “A good coach can change a game. A great coach can change a life.” The difference? A good coach calls the plays. A great coach builds players who read the game themselves. Most of our senior engineers are calling every play, and we’re praising them for the team’s win record without noticing that nobody else on the court can improvise.
Throw Them in the Fire
I’ve had many graduates start with me over the years, and one thing I learned early: never wrap them in cotton wool. Throw them in the fire. They’re young, they’re hungry, and their minds are like sponges — they’ll soak it up. Remember when you were that age? You thought you could take on the world. It wasn’t that long after you had a dream of being an astronaut. That energy, that fearlessness — it’s a feature, not a risk to be managed.
There’s a real tendency I find with some managers to give new grads too much leeway, too much protection. I have to remind them regularly: stop cushioning the landing. Give them hard problems to solve. Not impossible problems, not problems designed to humiliate — but real problems, the kind where they’ll have to think, research, fail a bit, and ultimately find their way through. That struggle is the entire point.
With our interns at Agoda, we form them into teams and pair each team with a mentor engineer. But I always give the mentors the same instruction: give them your time in the morning. Help them get oriented, answer questions, point them in the right direction. Then leave them in the afternoon to fend for themselves. Let them wrestle with it. Let them argue about it. Let them search Stack Overflow and read documentation and trace through code and feel that particular frustration that eventually resolves into understanding.
The afternoon silence isn’t neglect. It’s the most important part of the programme.
The Socratic Method: Teaching Engineers to Fish (Properly)
There’s a technique I teach all my managers and intern mentors, and it’s not new — it’s been around for about 2,400 years. The Socratic method isn’t about withholding answers to be difficult. It’s about asking questions that guide someone to discover the answer themselves, building the neural pathways that make them capable of the same discovery next time without you.
When a junior comes to you and says “this service is throwing a 500 error, what’s wrong?”, the rescue response is to look at the logs and tell them. The Socratic response is different:
“What have you checked so far?”
“What does the error message actually say?”
“Where would you look to find out if this is a data problem or a service problem?”
“What changed recently that might have caused this?”
Each question does two things. It gives the junior a breadcrumb to follow, and it teaches them the sequence of investigation — the mental model that experienced engineers use so automatically they’ve forgotten it’s a skill they once had to learn. You’re not teaching them the answer to this specific bug. You’re teaching them how to debug. The difference is everything.
It feels slower. It is slower — in the short term. But a team full of engineers who can debug independently is exponentially faster than a team that queues behind one person’s brain. The upfront investment pays compound interest.
The hard part for seniors is resisting the urge to jump in when the junior is struggling. There’s research in education — work on productive struggle from educational psychologists — that shows intervening too early in problem-solving actively damages learning. The discomfort isn’t a sign that something is going wrong. It’s a sign that growth is happening. Sitting with “I don’t know yet” for thirty minutes before asking isn’t wasted time. It’s where intuition gets built.
Capturing Lightning: The AWS Incident Log Approach
There’s a practice from AWS that I think every engineering organisation should steal. When they have production outages, they maintain a live incident chat, and they encourage every engineer involved to log what they’re doing in real time as they troubleshoot. Not just the conclusions — the entire thought process:
“I’m checking Dashboard X.”
“Dashboard shows a spike in Service Y response times.”
“Checking logs for Service Y — seeing a spike in error logs around 14:32.”
“Error pattern suggests a connection pool exhaustion. Checking upstream traffic.”
It reads like a stream of consciousness, and that’s precisely the point. When new engineers join, they can read through historical incident logs and watch how experienced engineers think through production problems. They see the dead ends, the hypothesis formation, the narrowing of the search space. They learn the investigative rhythm that you can only otherwise pick up by living through real incidents.
This is brilliant because it solves a fundamental problem: the only way to build production debugging intuition is through real production incidents, and ideally you want fewer of those, not more. By externalising the thought process, you create a reusable learning artifact from every incident. The senior’s expertise gets captured in a form that scales beyond one-to-one pairing.
Think about what this means for your team. Instead of the tribal knowledge living exclusively in Namfon’s head — “Oh, you need to talk to Namfon about that service, she’s the only one who knows why it does that thing on Tuesdays” — you’ve got a searchable record of how problems were diagnosed and resolved. The knowledge transfers even when the person doesn’t.
Strategic Unavailability Is a Leadership Skill
Here’s where it gets uncomfortable for engineering leaders. If your most helpful senior is also your biggest single point of failure, the answer isn’t to tell them to stop helping. The answer is to redefine what helping means.
Helping isn’t answering every question. Helping is building people who don’t need to ask. Helping isn’t being available at all times. Helping is creating systems — Socratic coaching habits, incident documentation practices, structured mentoring windows — that transfer capability rather than just transferring information.
If you’re tracking developer experience metrics, look for the fingerprints of this problem. How long does it take new joiners to submit their first meaningful merge request? How quickly do people transition from “always asking” to “sometimes answering”? Teams with the most responsive seniors might paradoxically have the slowest ramp-up curves. The data might be telling you that your best mentors are accidentally your worst teachers.
Set the expectation explicitly: senior engineers should be making themselves progressively unnecessary to their teams. Not irrelevant — there will always be gnarly problems that need experienced eyes. But the day-to-day operational capability of the team should not depend on any single person’s availability. If a senior takes two weeks of leave and the team’s output drops by half, that’s not a testament to the senior’s importance. It’s an indictment of how they’ve been mentoring.
The Product Owner Version: Same Pattern, Higher Stakes
Everything we’ve just discussed about senior engineers? It maps almost perfectly onto the relationship between Product Owners and their engineering teams. And arguably, the consequences are worse.
In most Scrum implementations, the PO owns the “why” and the “what.” They talk to stakeholders, interpret business needs, prioritise the backlog, and translate customer pain into user stories. The engineers build what’s asked. Rinse, repeat, sprint after sprint. On the surface, this looks like healthy specialisation. Under the surface, it’s the same learned helplessness problem wearing a different hat.
When the PO handles all the business context — the customer conversations, the revenue implications, the competitive landscape, the strategic trade-offs — they’re doing the exact same thing as the senior who types the fix while the junior watches. The engineers get the “what” without ever developing the muscle to understand the “why.” They become excellent executors who can’t independently assess whether what they’re building actually matters.
This is where the T-shape breaks down. We talk constantly about T-shaped engineers — deep technical expertise with broad cross-functional understanding. But if your PO is shielding the team from every business decision, your engineers never develop the horizontal bar of that T. They’re just an I. A very technically competent I that builds exactly what it’s told without the business acumen to question whether it should be built at all.
The management theorist Henry Mintzberg made an observation about strategy that applies here: “Strategy is not the consequence of planning, but the opposite: its starting point.” When engineers don’t understand the strategic context of what they’re building, they can’t make the hundreds of small design decisions that collectively determine whether a feature actually solves the problem. They optimise for the specification instead of the outcome, because the specification is all they’ve been given.
You’ve seen the symptoms. Engineers who build exactly what the ticket says and nothing more — not because they’re lazy, but because they genuinely don’t know enough about the customer to fill in the gaps. Teams that wait for the PO to return from holiday before making any prioritisation decisions. Developers who can’t articulate why their feature exists beyond “it was the next thing in the backlog.” That’s not an engineering problem. That’s a business literacy problem that we’ve accidentally designed into our process.
The fix mirrors what works for technical mentorship. Stop letting the PO be the sole translator between business and engineering. Bring engineers into customer conversations. Share the analytics dashboards, the support ticket patterns, the revenue data. When an engineer asks “what should we build next?”, try the Socratic approach: “What are our customers struggling with most right now? What does the data suggest? What would you prioritise and why?”
It’s slower at first. Engineers will make suboptimal prioritisation calls. They’ll misjudge market dynamics. They’ll propose features that don’t align with strategy. That’s fine — that’s the afternoon without the mentor. That’s the productive struggle. Because the alternative is a team of technically brilliant people who have no idea whether the thing they’re building will move the needle, led by a single PO who’s become as much a bottleneck as the senior engineer with the permanent Slack queue.
The best product engineers I’ve worked with don’t wait to be told what matters. They already know, because someone invested the time to expose them to the business context instead of protecting them from it.
The Bottom Line
As the philosopher Lao Tzu said, “A leader is best when people barely know he exists. When his work is done, his aim fulfilled, they will say: we did it ourselves.” That’s the north star for senior engineers, product owners, and the leaders who manage them.
We’ve built a culture that rewards the visible act of helping and ignores the invisible act of growing. We celebrate the senior who swoops in and saves the sprint, and we overlook the one who sat quietly while a junior spent an uncomfortable afternoon working through a problem that would have taken the senior ten minutes. We praise the PO who “protects” the team from business complexity, and we don’t notice that we’ve created a room full of engineers who couldn’t tell you what their customers actually need. But the quiet ones — the senior who asked three questions instead of giving one answer, the PO who brought engineers into the stakeholder meeting instead of summarising it afterward — they’re the ones whose teams will still be functioning in six months.
Stop measuring helpfulness by responsiveness. Start measuring it by independence. The best mentor isn’t the one the team can’t live without. It’s the one the team doesn’t realise they’ve outgrown.
Now, if you’ll excuse me, I have an intern team that just Slacked me asking for help with their afternoon task. I’m going to wait thirty minutes before I respond. It’s the most helpful thing I’ll do all day.