The Consulting Mirage: When Technical Debt Becomes a Deliverable
I remember during my time at Careem, just before the Uber acquisition. I was tasked with leading the DevOps adoption across the entire tech organization. It was a massive, interesting problem: building a CI/CD platform to help hundreds of Engineers ship software safely and faster.
Then, the company hired consultants, they were from a firm that was "big", but not "Big 4" to "guide" us.
I’ll be honest: I felt betrayed. I had the vision, I had the team, and suddenly a group of outsiders was brought in to tell me how to do my job. To be fair, after working with them for a while I realized some were brilliant. But others? I had no idea why they held "Senior" titles. They would ask basic questions about Git, Jenkins, and YAML, then spend the rest of the day messing up our standard deployment scripts, requiring constant handholding and needing to be spoon-fed basic best practices and key DevOps concepts.
When I eventually joined BCG, I thought, "Nah, this is BCG. There’s no room for those guys here"...
...I was wrong.
The Incompetence Shield
It turns out "those guys" are everywhere. Brand reputation doesn't filter them out; they are like a persistent bug in the system. The consulting industry provides the perfect environment for them to thrive.
Most engineering engagements last 12 to 18 weeks. By the time you’ve understood the requirements, fought for access to the client’s platform, and built a Proof of Concept (PoC), the contract is over. In such a short window, technical incompetence is rarely exposed. These individuals excel at the "consulting dance": speaking with authority about concepts they don't understand, using all the current's hype buzzwords and convincing stakeholders of a vision while the actual implementation is a house of cards with a potential domino effect.
The "Not My Problem" Architecture
In this environment, there is zero incentive to build software that is scalable, maintainable, or follows industry best practices. Why bother? The contract will end, the handover will happen, and the consultant will be long gone before the system actually has to scale, most systems will never see a real production environment anyway.
Quite often, the Proof of Concepts are locked in a drawer and never see the light of day. Even the "production" apps are frequently decommissioned once the client realizes they can't maintain the mess that was left behind.
What it meant for me
A lot of my time was spent "productionizing a Proof of Concept", which is a polite euphemism for "cleaning up someone else’s mess."
This problem increased with the rise of AI code assistants. I’ve seen teams generate massive amounts of technical debt, pushing "working" code that is architecturally bankrupt, hence, a nightmare to maintain. Every time I raised a concern about the long-term stability of these systems, I was silenced with the typical "we don't have time for perfectly ideal engineering".
The scenario was pretty much me being handed a Blue Tricycle, a Screwdriver and a bucket of Green Paint and asked to deliver a Red Ferrari in 3 weeks.
The most frustrating part? It was legally and contractually "OK." The box was checked. The deliverable was sent. The invoice was paid.
The Real Cost of "Loud" Engineering
Consulting rewards the "loud" engineer, the one who builds a flashy demo that breaks the moment you look at the source code. But as an Architecture Principal, I know that real value isn't in the demo, it's in the quiet, boring stability of a system that works three years after the consultants have left.
We are teaching a generation of consultants and engineers that "shipping" is the only metric that matters, regardless of what is under the hood. We are optimizing for the exit, not the operation. And as long as the industry rewards the "checked box" over the "robust system," we will keep building, shipping and delivering technical debt as products.