#52 | The Engineers Who Can't Ship.

Over the years in the tech industry, I’ve come to recognize two distinct classes of technical people. These classes are imbalanced, and one of them houses a particularly troublesome subset that I’ve grown all too familiar with.

Let me be clear from the start: this isn’t your typical “junior versus senior” discussion. The reality is far more nuanced and, frankly, more concerning.

The first class makes up the bulk of the engineering world - juniors, mid-level specialists, and yes, unfortunately, some seniors. I’d estimate around 80% of the engineers I’ve worked with fall into this category.

These folks excel at building lightweight prototypes. Their solutions are often duct-taped together, unscalable, and sometimes downright insecure. But here’s the thing: they work. And they work fast.

These engineers have an enviable time-to-market capability. They’re excited about new technologies, eager to learn, and they ship. For a startup hunting for product-market fit, this energy is invaluable. You need people who can turn an idea into something tangible before your runway disappears.

The problem? Most of them have no real concept of risk. They don’t run scenarios in their heads. They don’t think about what happens when the system encounters load, or how the architecture needs to evolve over five years. They’re building for today, sometimes for tomorrow, but rarely for next quarter.

The second class is smaller and typically consists of more experienced engineers who’ve learned to think beyond the immediate. These are the people who can actually predict outcomes. They build scenarios, assess stress on systems, calculate loads, and most importantly, they understand risk and probability.

When business stakeholders share their vision, these engineers can reverse-engineer the architecture needed to support that vision five to ten years out. They think in terms of tradeoffs. They understand that not all risks carry the same weight, and they can prioritize accordingly.

This is the class you want designing your core systems. These are the people who save you from catastrophic rewrites two years in.

But here’s where it gets complicated.

Within that second class exists a subset that I’ve encountered more frequently than I’d like, particularly in old-school European corporations. These are engineers who’ve swung so far toward the “secure side” that they’ve become completely unable to ship anything meaningful.

For them, MVP doesn’t exist as a concept. The minimum viable product is, in their eyes, a full-fledged product with every edge case handled and every future scenario accounted for. And here’s the critical issue: they have no sense of probability.

When every risk carries the same weight, nothing is actually a priority. The roadmap becomes vague and undefined. Any new problem, regardless of its likelihood or impact, gets elevated to a high-risk scenario where everything can go wrong.

I’ve watched tech leads with genuine tenure under their belts treat a 0.01% probability event with the same urgency as a 40% probability event. They can’t differentiate. They can’t prioritize. And as a result, they hide behind every possible risk - near future, distant future, doesn’t matter.

Let me give you a concrete example. I recently worked with engineers planning an application architecture to handle hundreds of thousands of requests per second. Impressive, right?

The application had 2,000 users at the time.

Given the B2B nature of the market, reaching even 10,000 users within five years was optimistic at best. But there they were, over-engineering for a scale problem that would never materialize, while the actual product sat unfinished, unable to serve the 2,000 customers who actually existed.

This is extreme over-engineering driven not by technical excellence but by fear. Fear of making the wrong call. Fear of being challenged. And in many cases, particularly in established corporations, fear of losing their job.

In larger, older companies - particularly in Europe - this behavior pattern is surprisingly common. These organizations provide a comfortable ecosystem for engineers who’ve stopped adapting. They’ve been in the same place for five, ten, fifteen years. They’ve watched technologies change while standing still.

Many of them know they wouldn’t survive a modern technical interview. They haven’t kept up with current frameworks, methodologies, or approaches. So they dig in. They drag their feet. They manufacture complexity to justify their existence.

And the structure of these corporations allows it. There’s enough bureaucracy, enough diffused responsibility, that no single person needs to answer for the endless delays.

In a startup or smaller company, this behavior becomes visible quickly. These engineers don’t last long in environments where shipping matters, where deadlines have consequences, where your runway is measured in months rather than decades.

As a product manager, this creates an almost impossible situation. I have dates. I have deadlines. Everyone in this life has deadlines, and we need them. We need them to measure progress, to see something end and something new begin. That sense of completion and forward motion isn’t just corporate overhead - it’s how we maintain sanity and momentum.

But you can’t have meaningful progress without priorities. You can’t have priorities when every risk is treated as equally catastrophic. You can’t ship when the definition of “ready” keeps expanding to include every possible future scenario.

Working with engineers who can’t assess probability means working with people who can’t make tradeoffs. And product development is nothing but tradeoffs.

I’ve wrestled with this question. Can these engineers adapt to the modern world? Can they learn to think in probabilities, to prioritize, to ship iteratively?

Honestly, I don’t know. What I do know is that many of them don’t want to. They’re comfortable. They’ve found an environment that rewards caution over delivery, complexity over clarity, tenure over growth.

Changing someone’s fundamental approach to problem-solving - how they assess risk, how they prioritize, how they think - isn’t a matter of training or mentorship. It’s deeper than that. It’s how their mind works.

For some engineers, the notion of shipping something “incomplete” creates genuine anxiety. They’ve built their entire professional identity around thoroughness, around considering every angle. Asking them to ship an MVP feels, to them, like asking them to do bad work.

The truth is, we need both classes of engineers. We need the fast shippers who can turn ideas into prototypes overnight. We need the scenario planners who can architect for scale and longevity.

What we don’t need are the extremes on either end: engineers who ship without any thought to consequence, or engineers who think without ever shipping.

The best teams I’ve worked with have found a balance. They have fast shippers who’ve learned to consider risk, and scenario planners who’ve learned to assess probability. They understand that perfect architecture for a product with no users is worthless, and a viral product on a collapsing infrastructure is a crisis.

But that balance is rare. And in the meantime, those of us managing products and teams continue to navigate these imbalanced classes, trying to ship something meaningful before the deadline, the runway, or our patience runs out.