Why I Wrote Screw Architecture, Manage Change

I remember sitting in a steering committee meeting, watching a $50M transformation program get presented as a success. New platform, new governance model, new architecture review board. Everyone clapped.

Six months later, the same organization was slower than before the program started. Not a little slower. Noticeably, painfully slower. Every new initiative took longer to approve, longer to build, longer to ship. Costs kept climbing. And when I asked people why, nobody had a straight answer. They blamed legacy systems. They blamed “technical debt.” They blamed the vendor.

Here’s the part I can’t shake off, even years later: that $50M wasn’t an abstraction. It was real money, the kind a company earned by taking real risk, by selling real things to real customers. If someone handed me $50M of my own money and asked me to spend it on getting slower, I’d refuse on the spot. I wouldn’t need a consultant to tell me that was a bad deal. Yet companies do this routinely, approve it in committee, and applaud afterward.

That’s the disconnect that bothers me most. People who are careful, even frugal, with their own money will sign off on corporate spending that no sane person would accept personally. Nobody renovates their house by making it harder to walk through next year. Nobody buys a car that gets slower to start every time they service it. But that’s exactly the deal many organizations keep signing, year after year, transformation after transformation.

I’d seen this exact pattern before. Not once — at multiple organizations, in different industries, with different leadership teams. And it always ended the same way: more money spent, less speed delivered. I remember one retail company in particular. Eighteen months into a “digital backbone” program, the team proudly reported they’d delivered every milestone on the plan. What they didn’t report, because nobody was tracking it, was that the average time to approve a minor product change had gone from two weeks to seven. Marketing had stopped asking for seasonal promotions because the lead time made them pointless by the time they shipped. Nobody connected that slowdown to the transformation. On paper, the transformation had succeeded. In the business, the business had gotten slower at the one thing it actually needed to do fast.

That repetition is why I wrote Screw Architecture, Manage Change. I needed to answer one question properly, instead of shrugging at it again: why does a $50M transformation program leave a company slower than before it started?

It was never a technology problem

Here’s what I noticed once I stopped looking at the systems and started looking at the decisions.

The root cause was almost never technology itself. It was a long series of decisions — about funding, priorities, standards, exceptions, governance — made over years, often by different people, each decision rational in isolation. A funding call here. An approved exception there. A standard quietly bent for one important client. None of these decisions looked reckless at the time. Collectively, they built a wall of complexity that became nearly impossible to reverse.

And here’s the part that really got under my skin: most of those decisions weren’t made by architects. They were made by executives, directors, and managers, under pressure to deliver results right now. Architecture teams were, at best, informed after the fact. I saw this up close once, in a planning meeting where a VP approved an exception to the integration standard so a key client’s launch date wouldn’t slip. It was the right call for that quarter. Nobody in that room mentioned the word “architecture” once. Nobody was supposed to. Eighteen months later, that one exception had been copied three more times for three more clients, each copy justified the same way, and the integration layer had quietly become four different integration layers wearing the same label.

A quick note on why I keep saying this so plainly: I’m not writing this to blame executives or let architects off the hook. I’m writing it because until a leadership team actually sees that the decisions shaping their architecture are being made in budget meetings and planning sessions rather than in architecture reviews, they keep treating the symptom instead of the cause. That’s the whole premise of the book’s preface, stated as plainly as I could manage: the problem is rarely technology itself. It’s a long series of individually rational decisions that nobody connected until they’d already become permanent.

What a $50M transformation can look like from the inside. Photo by Gayatri Malhotra on Unsplash — https://unsplash.com/photos/electric-post-outdoor-during-daytime-597hLaz5l1o

The tax nobody budgets for

Every one of those decisions carries a cost that doesn’t show up on the invoice. Technology variation and technical debt behave like a tax — a quiet, compounding tax on every future investment and on the total cost of ownership of everything you already built. You don’t pay it once. You pay it every single year, on every single project, whether you notice it or not.

And like any tax that keeps rising, it eventually changes behavior. Teams stop proposing ambitious changes because they know the tax will eat the budget. Leaders stop trusting estimates because every estimate quietly includes a surcharge for untangling yesterday’s shortcuts. The organization adapts to the tax instead of fighting it — which is exactly how the tax becomes permanent.

But it gets worse than a tax. A tax, however painful, still lets you function. What I watched happen in these organizations was worse: the ability to change didn’t just get expensive — it disappeared. Decisions that should have taken weeks took quarters. Changes that should have been routine required special committees, exception processes, and heroics. At some point, the company wasn’t just slow. It had quietly lost the capacity to change at all. That’s the real answer to the $50M question: the money wasn’t wasted on the wrong technology. It was wasted sustaining a system that had already lost its ability to change, and nobody had named it yet.

A stamp of approval is easy to give — harder to justify afterward. Photo by Raymond Petrik on Pexels — https://www.pexels.com/photo/classic-wax-seal-on-an-envelope-36824933/

The architecture illusion

Meanwhile, I kept watching architecture teams produce beautiful paperwork. Frameworks. Principles. Diagrams with clean boxes and confident arrows. It looked like architecture discipline. It looked professional and structured.

But the organization’s actual ability to change did not improve. Projects stayed slow. Costs kept rising. Systems kept getting harder to evolve. I eventually started calling this what it is: not an architecture discipline, but an architecture illusion. The artifacts exist. The outcomes don’t.

Everyone around me kept saying the same thing: “the company needs better architecture.” I think they were wrong. What the company needed wasn’t more diagrams made beautifully — it was fewer decisions made badly. I got tired of watching architecture teams produce documentation while the business quietly made all the real decisions somewhere else: in budget meetings, in vendor calls, in hallway conversations the architecture team never even saw, let alone influenced.

That’s the second thread of this book: architecture, as most companies practice it, isn’t the discipline that governs decisions. It’s the paperwork that gets produced after the decisions are already made. The illusion isn’t incompetence. It’s a structure that lets real power sit somewhere other than where the diagrams are drawn.

Beautiful diagrams. An organization that still can’t change. AI-generated with OpenAI (gpt-image-1)

The good news: it can be rebuilt

Here’s what kept me from writing a book full of despair: the ability to change can come back. It’s not a one-way door.

The clearest example most people already know is Apple. Before Steve Jobs returned in 1997, Apple had sprawled into a confusing maze of product lines, each with its own variations, each adding complexity nobody fully owned anymore. The company wasn’t just slow — it was close to irrelevant. When Jobs came back, one of his first and most famous moves was brutal simplification: cutting the product line down to a handful of offerings. That wasn’t an aesthetic choice. It was a direct attack on the complexity tax. By removing variation, Apple restored its own ability to change — and everything that followed, from the iMac to the iPhone, was built on that restored capacity, not on better diagrams or a new governance board.

That’s the pattern I want leaders to see before they’re six years and $50M deep into the alternative: complexity isn’t destiny, and neither is slowness. Both can be reversed, deliberately, the same way they were created — decision by decision.

Many hands, clear roles, fast progress: the kind of coordinated effort large transformation programs rarely achieve. Photo by Randy Fath on Unsplash

Change, not architecture, is the real job

That reframe changed how I approached the whole book. Architecture, standardization, governance, reuse, documentation — none of these matter on their own. They matter only because of how they influence an organization’s ability to change.

Organizations don’t win because they have better architecture. They win because they can adapt faster than their competitors. And the most successful organizations I’ve worked with rarely even talk about architecture. They just make better decisions: they align investments with strategy, they reuse before they build, they standardize where it makes sense and differentiate where it actually matters, and they continuously remove complexity instead of letting it accumulate quietly.

If you manage change well, architecture takes care of itself. If you manage it poorly, no framework, no governance board, and no set of beautiful diagrams will save you.

A path that loops back on itself: effort spent, progress nowhere. Copyright Milo Van de Putte

Why this book exists

Put the three threads together and you get the whole reason this book exists. A $50M program that leaves a company slower isn’t a one-off disaster — it’s the predictable outcome of years of individually rational decisions, made by people who were never asked to think about architecture at all. The teams that were supposed to prevent it were busy producing frameworks and diagrams instead of shaping the decisions that actually mattered. And none of it was permanent — it was built, decision by decision, which means it can be dismantled the same way.

Screw Architecture, Manage Change was written to make that reality explicit — to put a name to the pattern I kept watching play out, and to give leaders and architects a way to see it before the tax becomes permanent and the ability to change quietly disappears.

The title was never really about architecture. It was about change. I wrote it because I was tired of watching companies spend more every year to move slower every year, with nobody able to explain why — and because I believe, having seen it done, that the trend can be reversed.

If any part of this sounds familiar, you can get the book here:

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

Or visit http://wellofwisdom.community to learn more.