Show me an architecture no one questions,
and I’ll show you a system no one understands.
A few years back, I walked into a post-mortem where the architecture was being blamed for everything from latency spikes to the office coffee machine malfunctioning.
The architect? Well, he was calm. Unbothered. Certain.
“It’s not the design,” he said.
“The team just didn’t implement it properly.”
There it was: the dead giveaway. He wasn't doubting the design. He was defending it like gospel.
Right then, I knew.
The most dangerous architect isn’t the one who lacks answers.
It’s the one who never asks questions.
If you’re an architect or becoming one, doubt isn’t your enemy.
It’s your sharpest tool.
Why Architects Must Doubt
Doubt isn’t indecision. Doubt is respect for complexity, for context, and for change.
It’s what keeps you curious instead of complacent.
Without it, you don’t explore. You just preach.
You don’t validate. You just defend.
And that’s when architecture stops evolving and starts rotting.
“The moment an architect starts believing their own narrative too much, they stop listening. They defend ideas instead of validating them. They treat solutions like doctrine. They mistake consistency for correctness.”
— From an older post
Once you slip into certainty mode, it’s over. You’re not solving problems anymore. You’re selling ideology.
And tech doesn’t care about your ideology, it just exposes it over time.
What Happens When They Don’t
Ever seen a team stuck in a bloated microservices hell because someone got overexcited after a Netflix blog post?
Or a Kafka pipeline duct-taped to a CRUD app with 12 users?
That’s not architecture. That’s tech theatre: overpriced, overhyped, and dead on arrival.
At one company I worked for, Jenkins was repurposed as a cron job scheduler in a high-volume data exchange system. Nobody could recall exactly why but the consensus was that it was “simpler to configure” and had a user-friendly UI.
As data volume grew, Jenkins’s well-known scaling limitations became a major bottleneck. It only scaled vertically, and vertical scaling has its limits.
Over time, the system evolved. Everything got tightly coupled to Jenkins: services, data flows, batch jobs, events, and configuration.
Removing it became a nightmare, like flipping over an entire table. Imagine trying that across 200 production environments.
Idiocy is optional, always a choice.
This wasn’t just poor architecture. It was a perfect example of how idiocy is optional, always a choice.
Someone opted for convenience over foresight, and the technical debt paid the price.
When architects stop doubting:
- Systems get overengineered: Without scepticism, every new feature turns into a grand project. Complexity balloons unchecked because no one questions if simpler works.
- Teams stop challenging decisions: Doubt creates dialogue. Remove it, and dissent feels like insubordination. People nod, not because they agree, but because they fear speaking up.
- Criticism feels like betrayal: When certainty hardens into dogma, any pushback is personal. Feedback becomes a threat, not a tool, and the system suffers in silence.
- And the architecture solidifies into a relic nobody has the guts to question.
Balancing Doubt and Decision
Doubt doesn’t mean you freeze. You still make calls, you just know where to be sceptical.
You separate the big, game-changing questions from the nitty-gritty details.
You don’t get stuck debating every minor tech choice; you focus your doubt on decisions that shape the system’s future.
It’s about calibrated scepticism, questioning enough to avoid disaster but deciding enough to keep moving forward.
- Be strategically doubtful: Should we build this at all? Centralised or federated?
- Be tactically decisive: Which DB? Which caching strategy?
Good architects don’t know everything. They just know what to question, and when to stop.
They write decision logs.
They challenge assumptions.
They run pre-mortems before the system’s on fire.
It’s not wizardry. It’s operationalised doubt.
Doubt Is a Cultural Signal
If juniors don’t feel safe saying “This doesn’t feel right,” you’ve already failed.
A doubtful architect builds a team that questions, explores, and learns.
They create an environment where challenging the status quo isn’t a career risk but a necessity.
A dogmatic one builds a team that obeys, until they burn out or leave.
Want to measure maturity? Ask how often people revisit architectural decisions.
If the answer is “never,” you’re probably maintaining a fossil: a brittle system propped up by silence and fear, not trust and curiosity.
To make sense of all this, let’s map how doubt and decisiveness shape architectural impact.
Think of it as your mental compass for when to push, when to pause, and when to pivot.
The Doubt Spectrum
Here’s the architect’s mental model:
High Doubt
^
|
|
Paralysis | Strategic Doubt
(analysis forever) | (adaptive, robust)
|
|
Low Decisiveness -------------------|-------------------> High Decisiveness
|
|
Blind Faith | Overconfident
(dogma, stagnation)| Execution
| (fast, wrong)
|
|
Low Doubt
You don’t want to be slow.
You don’t want to be certain.
You want to move fast and doubt smart.
Final Thought
The best architects I know doubt themselves just enough to double-check assumptions, but not enough to stall.
They don’t cling to being right, they focus on being adaptable.
And they know the job isn’t to win arguments, it’s to keep systems alive.
Not just surviving, but adapting. Evolving with the business, the team, and the unknowns ahead.
Architects aren’t paid to be right. They’re paid to keep systems running despite being wrong, and to provide clear options when “it depends” is the only honest answer.
So doubt early.
Doubt loud, and often.
And design like the future will prove you wrong, because it probably will.
P.S. One Thing to Try Monday Morning
Before your next architecture review:
- Pick one key decision and argue against it for 10 minutes.
- Invite a colleague to do the same.
- Use what you learn to refine or document the risks clearly.
It’s not about being negative, it’s about sharpening your view.
If you liked this post, follow me on my blog for more
Top comments (0)