There’s a pattern I keep seeing when mentoring engineers, and it comes down to a single question: what are you solving for?

An enthusiastic engineer picks up a complex problem and dives straight into a solution. They’re energised, they’re building, they’re making progress. Or at least it looks like progress. But the solution has gaps they can’t see yet. It won’t handle failure gracefully. It hasn’t accounted for what production will actually do to it. They can’t smell what’s off because they haven’t been burned by those smells before. Then there’s the engineer who pauses. They ask uncomfortable questions. They poke at edges. They’ve seen enough things break in production to know that the interesting part of engineering isn’t making something work. It’s understanding how it will fail. The difference between these two engineers isn’t talent or enthusiasm. It’s their default assumption.

The Default Assumption

The less experienced engineer starts from an implicit belief: this will work, and I need to handle the cases where it doesn’t. The more mature engineer starts from the opposite: this will fail, and I need to create the conditions where it doesn’t. That’s not pessimism. It’s engineering realism.

The entire cloud-native stack is built on this principle. Kubernetes restarts failed pods. Circuit breakers trip to prevent cascading failures. Retries, health checks, graceful degradation, none of these exist because we expect things to work. They exist because we’ve accepted that failure is the default, and our job is to design around it. The enthusiastic engineer solves for function. The mature engineer solves for failure. Both are problem-solving. They’re just solving for different things.

The Invisible Failure Space

When a junior engineer looks at a problem, they see the solution space, the set of things they could build. When a seasoned engineer looks at the same problem, they see the failure space, the set of things that will go wrong. This is the gap that experience creates, and it’s genuinely hard to teach. You’re asking someone to be aware of their own blind spots, which is almost a contradiction. But it’s not impossible.

As a mentor, the move isn’t to gatekeep. It’s not “you’re not ready for this.” It’s to make the failure space visible so they can see it for themselves. A few ways I’ve found effective:

“What happens when…” as a discipline. Not as a test or a gotcha, but as a genuine exercise. What happens when this gets ten times the traffic? What happens when the upstream service is down? What happens when someone deploys this at 2am on a Friday? If they can’t answer, they’ve found their own edge, and that’s the point.

Separating the spike from the solution. Give people permission to explore with enthusiasm, but name it correctly. “This is a spike. Great. Now let’s talk about what it would take to make this production-ready.” That gap between spike and production is where the real learning lives.

War stories as calibration tools. This is how scar tissue transfers without the scars. “Let me tell you about the time we shipped something like this and what happened.” Not to frighten, but to calibrate their sense of what matters.

The Solution That Already Failed

There’s another pattern I see alongside the solution-jumping: working in isolation. An engineer discovers a problem, gets excited, and starts building, without asking whether anyone has looked at this before. In any team of reasonable size, on any problem with a wide blast radius, someone has almost certainly poked at it already. They explored, they evaluated, and they deliberately chose not to proceed. That context is invisible to someone approaching the problem fresh.

This is Chesterton’s Fence applied to engineering decisions. The absence of a solution is often itself a signal. It’s not a gap waiting to be filled, it’s a decision that was already made, and understanding why is the first step. The most expensive solution is the one someone already proved won’t work. Those prior attempts are free evidence of the failure space. Ignoring them means choosing to rediscover failure the hard way.

The mentoring move here is straightforward: before you write a line of code, do a discovery round. Talk to the people who’ve been around the problem. Check old ADRs, Slack threads, abandoned pull requests. The question isn’t “has anyone solved this?”, it’s “has anyone decided not to, and why?”

Calibration, Not Caution

I want to be careful not to frame the cautious engineer as the ideal. Over-caution is its own failure mode, the engineer who never ships because they’re forever identifying risks they might encounter. That’s not maturity, that’s paralysis. The mature engineer isn’t cautious. They’re calibrated. They know which risks matter and which don’t. They can distinguish between a risk that will page someone at 3am and a risk that’s theoretical. They ship, but they ship with eyes open.

The goal of mentoring isn’t to slow enthusiastic engineers down. It’s to help them flip their default assumption. Start from failure. Work backwards to resilience. Mine the organisational memory for lessons already learned. And then build, with the full picture in view. You’re not saying “you’re not good enough.” You’re saying “you’re solving the wrong problem. Solve for failure.”