There are meetings where everyone in the room knows the truth and nobody says it. I’d been through the existing codebase.
The designs were rough; the code behind them was worse, not catastrophically wrong, just badly built, in the way that happens when a team has been too busy to be honest with itself, and too stubborn to revisit the amateur choices it had made along the way.
I’d written it up. They’d seen my assessment and recommendations.

The meeting opened with a presentation: architecture diagrams, process flows, the kind of thing that takes real effort.
I didn’t say much.

Any architecture decision comes with a stated reason and a real one, and they don’t always match.
The stated reason is usually the same. It’s the right tool for the problem. Sometimes it is. Sometimes the real reason is that the architect wants to learn the technology, wants it on their CV.
The architect who reaches for Kafka because they want it listed in their next interview, who proposes microservices because the monolith problem feels beneath their current ambitions.
The motivation is personal growth; the organisation pays the tuition.
Researchers called it resume-driven development , a recognised pattern, and the more visible of the two.

What I was watching was something different and considerably worse. Resume-driven development is at least honest in its selfishness: the architect wants something, they take it. The defensive version works differently. The problem is visible, the gap is known, and instead of addressing it, someone builds something impressive nearby.

That presentation wasn’t ambition. It was camouflage.
The codebase was broken; the team knew it, and they knew I knew it. So they built a deck. Clean and full of best-practice references. Built purely to avoid the conversation about what was actually wrong.

Both forms share the same structure: the person making the decision is not the person who lives with it.
The architect who pushed for the event-driven microservices architecture moves on; the team that inherited it runs it.
The same team that built the presentation to avoid a conversation about the codebase will eventually have that conversation. Or their replacement will.

The problem doesn’t go away because nobody said it out loud.
It just gets more expensive.

None of this is an argument against personal motivation.
Learning on the job is legitimate, and so is growth. The issue is honesty.
Motivation and purpose can coexist, but only if you know which one is driving.
When you present them as the same thing, you’re not making an architectural decision. You’re writing fiction and calling it a proposal.

I didn’t say much in that meeting. I didn’t need to. The codebase was still going to be there on Monday.