Why I Wrote a Book That Insults My Own Profession

After nine months of hard work, my book is finally here: Screw Architecture, Manage Change.

People keep asking me two things. Why did you write it? And why on earth did you give it a title that insults your own profession?

Fair questions. Here’s the honest answer to both.

The moment it clicked

Over the years, I noticed a recurring pattern across organizations. When systems become expensive, slow, or difficult to change, the root cause is rarely technology itself.

But there was one moment when the pattern stopped being an observation and became something that genuinely bothered me.

I was looking at an organization that was paying twice.

Once, because it had lost the ability to change. Every new initiative took longer, cost more, and delivered less than expected. The board wanted innovation. Customers wanted better digital services. Competitors were moving faster every year. And the organization simply couldn’t keep up.

And a second time, because its IT landscape had become enormously expensive to run. Years of projects had added systems, integrations, and platforms. Very little was ever removed. The complexity itself had become a cost center.

Two losses. Same root cause. That’s the change trap: you pay for an expensive landscape and you pay for the inability to change it.

That double loss is what made me spend nine months writing this book.

Two losses, one root cause: a bloated landscape and a stalled ability to change. AI-generated with OpenAI (gpt-image-1)

The deeper why: I know how hard change is, because I fight it in myself

There’s a more personal reason too, and I might as well say it out loud.

I like to change myself. I always have. And every single time, I discover the same painful truth: changing is harder than I expected, and it costs far more effort than I planned for.

It’s never the big things that stop me. It’s the little things. Little habits that make my life expensive — twice. Once because they cost me time and effort, day after day. And a second time because they quietly prevent me from becoming who I want to be. Who I actually am.

And then, sometimes, I have a screw it moment. The moment I finally break those habits and establish the change. It feels like biting through a lemon — it stings, your whole face resists. But the payback is great. Every time.

That’s exactly what I see in organizations. The same little habits, scaled up: the exception granted “just this once,” the integration nobody dares to remove, the decision nobody revisits. They cost twice. They keep the organization from becoming what it wants to be. And what’s missing is the screw it moment — the courage to bite through the lemon.

The title of the book is that moment.

The Change Trap: pressure and complexity keep climbing while change capacity levels off. Diagram from the book (© Dimitri Van de Putte)

What does change actually cost you?

Here’s the question that shocked me most along the way: what does it actually cost your company every time you change something?

Not the project budget. The real cost.

Because every project adds systems, integrations, and exceptions — and almost nothing is ever removed. Each addition silently raises the price of every future change. The integration you built last year is a constraint on the thing you want to build next year. The exception you granted under deadline pressure becomes permanent, and now every new initiative has to work around it.

The underlying problem is usually a long series of decisions about funding, priorities, standards, exceptions, and governance. Decisions that were often rational in isolation, but collectively created complexity that became difficult to reverse.

And here’s the uncomfortable part: many of the most important architectural decisions are not made by architects. They are made by executives, directors, and managers under pressure to deliver results.

Meanwhile, the pressure only grows. Every executive hears the same two sentences today: “We need to accelerate change” and “We need to reduce our costs.” Inflation drives up operational costs. Margins shrink. Organizations are asked to do something extremely difficult: change faster while spending less.

According to McKinsey research, around 70% of transformation efforts fail to achieve their objectives. Most leaders assume the problem is technology.

They are wrong. Their problem is unmanaged change.

Screw Architecture, Manage Change — out now. Provided by the author

Why I insulted my own profession in the title

So why Screw Architecture, Manage Change?

Because architecture was supposed to solve this problem. But too often it produces documentation instead of decisions.

I’ve been an architect long enough to say this out loud: a lot of what passes for architecture today is theater. Diagrams nobody reads. Review boards that slow things down without changing any outcomes. Frameworks that describe the landscape beautifully while the landscape quietly rots.

The title isn’t against architecture. It’s against architecture that has forgotten its real job: managing change.

Three signs your architecture practice produces documentation instead of decisions

Here’s a quick self-diagnosis. Watch for these signs:

1. The output is documents, not choices. If your architects produce models, maps, and target-state pictures — but you can’t point to a recent, consequential decision they drove — you have a documentation function, not an architecture function.

2. The big decisions happen elsewhere. Funding, priorities, standards, exceptions: if those decisions are made by executives and managers under delivery pressure, without architecture in the room, then the real architecture of your company is being shaped by accident.

3. Exceptions outlive the reasons for them. Every landscape has exceptions granted “just this once.” If nobody tracks them, revisits them, or removes them, complexity grows faster than your organization’s ability to manage it.

If two or three of these sound familiar, you’re not alone. Most organizations I’ve seen are in exactly this situation. That’s precisely why they struggle — not because they lack technology, talent, funding, or ideas, but because change becomes increasingly difficult.

The first step

The first step out is simple to say and hard to do: stop measuring your architecture practice by the documentation it produces, and start measuring it by the decisions it enables.

Ask of every architectural activity: what decision does this inform? Who makes that decision? What does it change about our ability to change?

That reframe — architecture not as documentation, not as governance bureaucracy, not as a collection of frameworks, but as the discipline of managing change — is what the book is about. It’s written for the people who actually make those decisions: executives, directors, and managers, not just architects.

I wrote it because it genuinely bothers me how many companies are stuck. They’ve lost the ability to change, they’re drowning in IT costs, and they’re paying twice for the same mistake. I know how that feels, because I’ve fought the same battle in my own life, habit by habit. The lemon is sour. The payback is great.

You don’t have to stay stuck.

Screw Architecture, Manage Change is out now:

• Ebook: https://wellofwisdom.community/b/samcebook
• Paperback: https://wellofwisdom.community/b/samcpaperback

If you recognize your organization in this story, the book will show you how it got there — and how to get out.