Hi there,

Ferrari revealed a car this week and the internet lost its mind. Not because the car was bad - because it was different. The Luce broke from everything Ferrari had looked like for decades and the reaction was instant: rejection dressed up as critique.

Architecture practices do the same thing with technology. A tool gets proposed, a workflow gets challenged and the room fills with concerns. Some of those concerns are valid - practices have been burned before. But some of the resistance isn't really about the tool. It's about the change itself.

Tim Bailey said it plainly: "Most of an architect's work can be systemised to a greater degree. Resistance to that is cultural."

Not technical. Not financial. Cultural. That's the conversation worth having this week.

Let's get into it. 👇

Cultural resistance is your real technology problem. Not budget. Not software selection. Not implementation complexity. The Ferrari moment - that instant rejection when something breaks from familiar form - happens in practices every week.

A new workflow gets proposed and the experienced people in the room raise concerns. The concerns feel technical. They're often cultural. And the distinction matters because they require completely different responses. Technical concerns get resolved with better information. Cultural resistance requires a structured process for working through it - not around it, not past it.

Ferrari's CEO said people are afraid of everything new. That's too broad to be useful. What's more precise: people are afraid of losing what works. In practices with hard-won processes and real institutional memory, that fear is rational. The question is whether there's a structured way to surface it, name it, and move through it.

The workflow stacks idea posted this week is connected to this. The standard software conversation - "what tool should we use?" - treats tools as isolated decisions. They're not. The same Revit licence produces different outcomes in two practices depending on what sits around it. Mapping complete stacks - how software connects, where data flows, where friction lives - is a more honest frame. It moves the conversation from tool selection to system design. That's a different room to be in.

The Ferrari comparison lands because it's honest. Rejection of new things isn't stupidity - it's pattern recognition running on outdated data. Practices that have been burned by bad implementations have good reason to be sceptical. The problem is when that scepticism becomes the default response to everything new, rather than a calibrated response to specific risks.

Two things worth sitting with this week.

First - if your practice has a technology decision that keeps getting deferred, ask whether the barrier is actually technical. It might be. But if the same concerns keep surfacing across different tools and different proposals, the pattern is the thing worth examining.

Second - the workflow stack framing is more useful than the tool selection framing. Not "should we adopt this software" but "how does this connect to what we already have, where does data flow, and where does it break?" That question leads to better decisions and - importantly - better conversations in the room.

Get in touch: reply to this email or book a call. 30 min with Allister Lewis