AI Doesn't Need You to Fix Your Operating Model

If sarcasm is the lowest form of wit, then the lowest form of consultancy has to be operating model transformation. Never has there been a field that has just the right level of complexity to be hard to measure whilst promising so much.

And AI has certainly given rise to plenty of operating model snake oil.

You are not getting value from your AI investments because you need to update your operating model.

AI is moving from the lab to the front line and your operating model needs to keep up.

Sound familiar?

The shameless audacity hidden in the idea that a bunch of people who have never done your job, lived your pain, taken your risks, could come in and optimise your people and processes and unlock the mighty power of AI is staggering. And yet here we are.

Of course, organisational change can be important, but it's a do-once lever, not a programme and not something you do every time there's a new technology on the market. Besides, most of the time it doesn't even work. A McKinsey survey ("The secrets of successful organizational redesigns") found three-quarters of organisational change fails to meet its objectives and improve performance.

There aren't many services that have a 75% failure rate that still get sold constantly.

Operating model change is lengthy, expensive, and hard to measure cleanly, which means if you do need to do it, a) you should do it yourself so you are closer to the work and b) avoid consultants looking for a long, fluffy, high-value engagement over delivering fast, provable value.

The reason we bring this up is we are seeing a lot of sales pitches misrepresenting and conflating Conway's Law and Domain Driven Design as a hook to take clients on an operating model odyssey.

Let's start with Conway's Law. Mel Conway wrote a paper in 1968 called "How Do Committees Invent?" It's a good paper and well worth a read. But it is largely about the process of design and how the way we communicate influences that design. Not only the design of software systems, but the 'design' of the groups of people who guide the process itself. It is not about the boxes on your org chart. It's about who talks to who, every day, across time zones, across levels of status. Some may argue the focus on status and military-style communication has been superseded since 1968, but the main premise holds.

And Conway's Law is relevant to a world in which AI forms part of the communication network. For example, teams orchestrating agents need to feed them all the weird and obscure knowledge they take for granted, like the fact Dave's code can only be changed on a Wednesday and the reason there are three copies of one function is because a refactor had to be abandoned in 2007.

One could argue that anyone from outside the team tinkering with anything this arcane could very easily result in lost context, broken relationships, and months of reduced output while people relearn all this know-how.

Despite the frequent slop-generated references on LinkedIn, Conway never said that org charts influence design (other than indirectly via comms channels they may create or prevent). Conway's Law is all about the flow of information and rules and constraints between people. You don't need to know Conway's Law to remember to tell Claude about Dave's code. You need to know if Claude breaks something because it didn't know about Dave's code and fix that.

A discipline often confused with Conway's Law but distinct from it is Domain Driven Design, or as it's more often known, DDD. DDD is a big topic, but in essence what it enables is a way for teams to construct logical models in codebases that reflect what the business does in all its glorious nuance and give clear ownership of that model and reduce coupling between parts of the system that have no business being tangled together.

It's very relevant to AI because, as we've talked about before, it can help mitigate a lot of the problems LLMs create in the code by keeping modules focused on a clear task without having to know too much about the rest of the system.

Consultants can help you get started with DDD, but it's a commitment, not a workshop. DDD is hard, nuanced, and needs continuous debate and revision as the business changes. This means it's best driven bottom-up by the people who understand the domain, not handed down via a change programme. That should make it less attractive to consultants, but we often see it packaged into a tidy, one-off deliverable.

If you're a business struggling with AI adoption and someone tells you the fix lies in the operating model or in organisational change, ask exactly why, and what specific benefit you'll get. Don't start yet another transformation until the cause and the change and the results are obvious.

If DDD sounds like it might be worth exploring, then absolutely look into it. Even if you don't formally adopt it, the conversations are worth having, and it's full of topics that lead to good habits.

Not only can you do this regardless of your org chart, but everyone (no matter which team they are in) is positively encouraged to get involved in exploring how the business really works.

If we haven't put you off consultancies entirely and you'd like practical help with AI delivery (without the shilling for operating model changes), we are an email away.