The Spiral of Outsourcing: Why Bad Software Is Everyone’s Fault
I’d like to propose a small riddle: Why, in an age of “digital transformation” and near-limitless tech budgets, do we still see so many hopelessly buggy, slow, and downright infuriating software products? Time and time again, entire corporate teams—armed with resources that’d make a hungry startup drool—somehow manage to deliver glitchy user experiences that push customers to the brink of rage-quitting. Or perhaps, ironically, they deliver nothing at all.
It’s a puzzle, but one whose solution only a handful of us seem to grasp. The short version: human failings—bad management, misguided outsourcing, and an empathy gap as wide as an ocean. Let’s unpack that, shall we?
The Myth of “Bigger = Better” (and Why It’s False)
We’ve all seen it: huge software teams shipping less functional product in twice the time it takes some tiny, scrappy dev squad in a coworking space to achieve 10x the output. The mismatch is confounding to onlookers who assume that if you throw more bodies at a problem, your code will blossom faster. But no. The real culprit often has little to do with coding skill and everything to do with the structural decisions of the company1.
So, sure, run your website through Lighthouse2 if you want a real-time example. You might discover ghastly performance issues, monstrous security holes, and a near-absent mobile experience. And this is the “shop front” of your business? One might cringe.
To solve these sorts of nightmares, software teams need the freedom to fix problems quickly—before an ironically named “urgent deadline” kills all chances of thoroughness. Instead, we often see a lack of real autonomy, overworked staff who can’t fight the bureaucracy, and no time for the automation that might actually produce lasting improvements.
High-Performing Engineers Aren’t Mythical Creatures
They aren’t some heroic pantheon, either. They’re regular folks—albeit ones who prefer to automate the repetitive so they can pour their finite energies into what actually matters. They combine a certain exasperated pragmatism (i.e., “We are not rewriting the entire codebase for a trivial fix”) with a flair for building just the right novel thing at just the right time.
Balance is the key. If you spend your life “innovating” only to reinvent every wheel known to man, you’ll stall out building half-baked clones of existing solutions. Conversely, if you never try anything new, your software stays stale and your users flee to more exciting platforms. In practice, every real dev team straddles these two extremes, deciding which corners to cut and which corners need original craft.
The Slippery Slope: Why Outsourcing Starts Easy and Ends Ugly
Outsourcing can seem like a rational approach: “We don’t care about X part of our product; let’s farm it out to an external group who’ll do it for cheaper.” But it’s a line walked by many a misguided exec who can’t quite tell the difference between the truly non-critical “we just need a thousand random art assets” tasks and the core “this is our secret sauce” engineering that must remain in-house.
Soon, the company is whittling away more and more of its engineering muscle, confusing cost-cutting with efficiency. Before you know it, they’re outsourcing anything they vaguely label “technical,” forgetting that the technology may well be the product. Then they wonder why the code quality plummets, morale tanks, and new features take eons to ship.
Software as Expense vs. Software as Innovation
Look at the dismal state of banking in certain regions. Outages, security fiascos, bizarrely dated interfaces—leading to the meteoric rise of challengers like Monzo, who treat tech as an integral piece of the puzzle. Meanwhile, older banks treat software as a cost center that should be minimized. This is exactly the difference: you slash your dev budget repeatedly, you get catastrophic meltdown after meltdown, and your customers defect in droves. Surprise, right?
Sometimes, outsourcing is a wonderful approach if it’s truly for tasks that (1) cannot break your main product, and (2) genuinely don’t demand your internal expertise. But the line between “safe to outsource” and “don’t you dare” is slippery, and it takes real knowledge of your product to figure out where that boundary is. If your leadership is clueless? Prepare for the outsourcing free-fall.
The DORA DevOps Data: A Brutal Reality Check
A few years back, the DORA (DevOps Research and Assessment) team hammered home some stats that show certain skills must remain in-house for any high-functioning team—especially those related to DevOps. Yet in the “panic, slash, outsource” mindset, companies happily get rid of entire engineering squads, only to realize too late that no one remains who can actually deploy or maintain the product with any competence3.
Employee Happiness: Not a Nice-to-Have
Stack Overflow data suggests only around half of software developers are “moderately satisfied” with their jobs, and a mere 18% say they’re “extremely satisfied.” Why so glum, chum? Possibly because too many companies treat devs like code-churning drones—human-shaped batteries to be drained and replaced. Once you accept that worldview, it’s easy to see how managers think external bodies are just as good as internal staff.
Then you have the Googles of the world. They also aim for maximum output from their programmers, but the difference? They invest in them, let them innovate, make them part of the strategic vision, instead of cardboard cogs in a soul-sucking machine. You can’t cherry-pick a single practice from Google (like “20% time” or “Chaos Engineering” or whatever) and expect to replicate their results if you’re missing the deeper cultural piece: respect for devs as creators.
The Effect of Low Performers (and the “Dead Sea” Problem)
If you staff your dev team with a high percentage of folks who aren’t quite up to snuff—maybe because they arrived via an outsourced partner that doesn’t filter or train well—your top talent ends up babysitting them. This kills morale, stifles innovation, and ultimately drives away your best engineers. Suddenly, you look around and see that all the real doers have left the building, leaving behind a “Dead Sea” of low performers.
It’s not that every outside resource is incompetent—but if you treat software as an expense you can cheaply farm out, you might never realize (or care) that you’ve compromised fundamental product quality. You accelerate in the wrong direction, each misstep reinforcing the notion that software is the problem, not you.
The Silver-Bullet Syndrome: Slapping Agile/DevOps Stickers on a Trainwreck
Once everything hits meltdown, companies often pivot to “Agile” or “DevOps” as if it’s a brand of miracle cure. They adopt a few surface-level processes—scrum stand-ups or Jenkins scripts—and call it a day. But they never address the root issues: poor alignment between teams, no real trust in the devs, and persistent offloading of critical tasks to questionable outside providers.
True DevOps transformation means a cultural shift that respects continuous delivery, shared ownership, and the empowerment of teams. But if top management doesn’t buy in, you’re just applying “go faster stripes” to a broken car that’s careening down the track with faulty brakes.
Netflix, Messi, and Midfielders Who Mess Up
Take Netflix: they famously see each employee as a “top sports talent” (like a world-class soccer club). If a single midfielder keeps messing up passes, the entire team suffers; you can’t consistently compensate for that error without sacrificing your star forward’s effectiveness. Similarly, your best devs will tire of picking up the slack for the cheap or ill-suited hires that creep in via never-ending “resource expansions.” Low performers degrade overall performance, and eventually, the real talent leaves.
The greatest irony is that many companies desperately want to “copy” Netflix’s or Google’s visible practices, but they skip the underlying approach: no tolerance for mediocrity, heavy investment in top performers, and an unwavering sense of accountability for the product’s core.
Hitting the Brakes Before the Bend
There’s an old racing adage: you have to slow down before you can go fast. If your dev pipeline is mired in slow, buggy, friction-laden processes—maybe stop accelerating. Fix the underlying problems (like a broken architecture, incompetent or unmotivated teams, or nonexistent testing pipeline) before you go full speed into the next corner. Otherwise, you’ll spin out and crash.
The Missing Link: Real DevOps and Sustainable Growth
The only way off the outsourcing spiral is to reclaim your in-house engineering capabilities—particularly the DevOps skill set that fosters quick, reliable releases and fosters a sense of ownership across the team. That doesn’t mean you can never outsource anything, but it does mean you’d better know exactly what’s crucial to keep close.
Yes, finding people with the right expertise is hard. But losing control of your own product is guaranteed to be harder. In a world where software can make or break your entire business, treat your devs as indispensable partners, not expendable line items. Because the moment you reduce them to cogs, you also degrade your product, your morale, and ultimately your chance for real innovation.
No quick fix can patch up a dysfunctional culture that sees code as a mere expense. But if you refocus on bringing DevOps in-house, on forging a team that’s deeply invested in the product, you can slowly ascend from the spiral of outsourcing. It won’t happen overnight, but it’s infinitely better than careening deeper into the sinkhole.
1 The old “Mythical Man-Month” notion that adding more people to a late project only makes it later.
2 Google’s tool for measuring performance and best practices on websites. It can be terrifying.
3 We often see ironically “DevOps-labeled” departments that outsource the entire pipeline to some vendor. Then they wonder why everything breaks.
← Read more articles
Comments
No comments yet.