The firm had a reputation. Across the organization, those who had previously worked with the firm spoke highly of them, and when the team entered a room, everyone leaned in. So when we hired them to design an integration layer for our application landscape, nobody expected the engagement to go wrong. The status report did not identify any issues during the engagement. That is exactly what made it dangerous.
They did excellent work on the surface. They conducted a thorough study of our systems, mapping the application usage, tracing the data movement, and documenting the shortcomings of the interfaces. Their picture of the present was accurate and detailed. Every finding confirmed what we already knew. The applications needed to talk to each other. The current setup was inefficient. An integration layer would help. Heads nodded around the table, because the experts had just told us we were right.
Then I looked at the design they were steering us toward, and something felt wrong.
Fifteen years as a system engineer leaves you with a particular kind of instinct. You learn to feel the shape of a technical decision before you can fully articulate why it bothers you. And this one bothered me. They specifically designed the proposed integration layer for our current systems, connecting them in the same manner we use them today. It answered the present perfectly. It made no room for the future. The design’s technical limits should never be accepted, as they would hinder core functionalities essential for the business’s direction.
The consultant had never asked about that future. They never pushed us to define what we would need this layer to do in three years or what we would want to build on top of it as we grew. And to be fair to them, the brief never asked them to. The project had been scoped as an analysis of the current state. There was no future vision written into it. So they delivered against the question on the page, and the question on the page was the wrong one. They gave a correct answer. Nobody had written the right prompt.
They gave a correct answer. Nobody had written the right prompt.
Here is where it became difficult. The recommendation was comfortable. It matched what most people in the room already believed, and it carried the authority of a firm everyone trusted. Some of my peers pushed hard to accept it. They were not being careless. They sat further from the technical detail; they had heard the expert view, and that view carried weight from every engagement before this one. For them, agreeing was the sensible thing to do. Resisting the consultant looked like second-guessing someone who had earned the benefit of the doubt.
I resisted anyway, because I could see what the comfortable answer would cost, and I had to hold that position in a room that had mostly made up its mind.
Why architectural mistakes stay hidden
The reason this matters beyond my one project is that architectural mistakes hide. They do not announce themselves when you make them. They wait until you try to grow, and then every expansion runs into a wall you built years earlier and forgot about. The cost is real and measurable. McKinsey estimates that technical debt can represent up to 40% of the entire technology estate in large enterprises, and most of it accumulates quietly through decisions that favored the present over the future. IDC found that 47% of IT leaders point to technical debt as a major driver of overspending on cloud and digital infrastructure. The organizations that avoid this drag move faster, with research showing a 20 to 30% quicker time to market on new initiatives. An integration layer built only for the status quo is a debt you sign up for at the one moment you had the chance to avoid it.
We changed course. I steered the decision toward a design that stayed open and extensible, so future functionality was not blocked before we had even imagined it. The layer we built could grow with us. The one the consultant proposed could not. This was the same principle I wrote about in why enterprises must stop adding tools, applied at the design stage: treat your architecture as a system that has to serve where you are going, not a set of fixes for where you are..
What I took away
Two things stayed with me.
The first is about the people you hire for advice. A good advisor does not hand your own beliefs back to you with a logo on the cover. They challenge your assumptions about the future and ask the uncomfortable question you’ve been avoiding. If an outside expert only confirms what you already think, you paid for reassurance, not advice. When I work with leadership teams now, I treat challenging their assumptions about what comes next as the actual job, not a bonus.
The second is about the question you ask. The consultant did not fail us. The brief did. Scope a project as an analysis of the current state and you will get a solution for the current state, delivered competently and confidently. If you want a design that serves the future, you have to write the future into the scope. The question you ask determines the answer you get, and no expert will fix a question you framed too narrowly.
Scope a project as an analysis of the current state and you will get a solution for the current state.
Watch the comfortable recommendation most closely. When a proposal matches what everyone already believes and arrives wrapped in a trusted name, that is the moment you most need someone willing to ask whether it serves where you are going. Sometimes that person is a consultant. Sometimes it has to be you. I write more about these patterns in my book Life in the Digital Bubble, and you can find more on architecture and digital leadership at tamerbadawy.com.