So we centralised responsibilities. Created a specialist group of web editors.  Instituted a bunch of policies and standards. Placed tight limits on what people outside the team could do.

On paper, it looked great. Specialists can work faster than occasional users. They can make use of ‘advanced’ (i.e. complex) tools. We gain economies of scale by managing them as a single pool. And we can control site design, editorial voice, etc, more easily, as it’s all managed from a single point.

Yet somehow these central teams became bottlenecks. You never had enough specialists, no matter how big your budget was, there were always people who wanted more stuff, more quickly than you could deliver. Adding budget just unveiled yet more demand.

And the design got tired anyway. Maybe we cut too many corners while trying to keep on top of everyone’s requests. Maybe we imposed too much control: the site became bland, or was always a little out of date. Maybe people bypassed the web team, set up their own facilities and diluted the overall design.

So we accepted reality, decentralised and the cycle started again.

Everyone seems to be in a big centralisation phase right now. Budgets are tight, so anything that looks like it might control costs is popular. Just mention ‘economies of scale’ and your business case will go through.

Likewise, security is at a premium. So we talk about the benefits of controlling access from a well-defended central facility. And all those other attributes – control the brand, control the user experience, control all our (big) data, etc.

In uncertain times, people want to exert control.

I see this in other domains too. Big projects, for example, have always been popular. Big projects can afford to hire specialist teams. They get management attention. They promise quick, comprehensive solutions to complex, tangled, thorny problems. We’ll talk about the failure rate for big, centralised projects later.

(Project managers get promoted according to the size of the projects they do. Their career path is often to set up a huge project, then get promoted before its failure becomes obvious. Do web managers get promoted according to the size of the teams they manage?)

Products are the same. Most successful products start off small. They do some one thing well. As they succeed, they accrue more features. They chase more and more ‘adjacent’ markets. And product managers’ power grows with them.  

Bigger products mean bigger revenues, hence bigger budgets to do ever more stuff. Uncontrolled sprawl.

Centralisation is a power game. It’s not really about control at all.

There’s a problem here. Centralisation is fragile. It’s great if you get all the conditions right. It does give better control, improved efficiency, greater transparency, etc.

But as you move away from ideal conditions, it breaks down quickly. If demand isn’t perfectly matched to supply, central teams rapidly become bottlenecks. If you don’t have robust information flows, central teams rapidly get out of touch with reality. If the unexpected happens, central facilities become a single point of failure.

Remember, centralisation is about power, not control. Centralisation only gives the illusion of control. As soon as conditions move away from nominal, centralisation starts to fail.

Some day now, this centralisation phase is going to end. That’s the way the cycle works. We’ll decentralise again.

Decentralised teams are inefficient. They’re messy  It can be hard to see exactly what’s going on.  Hard to steer and control them. But they’re robust. They learn to accommodate new situations. (Some may fail, but others move in and pick up the slack. It’s like ecology – teams evolve to fill the niches.)

Then, as they work out just what works in the new situation, they start to seek efficiencies. They look for ways to embed consistency and control. They begin to centralise again.

In fact, this talk of centralisation versus devolution creates a false dichotomy. Control doesn’t come from imposing extreme power structures. It comes from surfing a dynamic balance between availability of information, expertise, resources, management attention, etc.

Sometimes information is most visible to people working on the organisational fringe; sometimes it can only be acquired by people with large, central budgets. Sometimes we build expertise by working on a team with other experts in the domain; sometimes we build it by working closely with customers. And so on.

This is mostly about knowledge acquisition. We shift between centralised and devolved strategies in order to gain fresh perspectives, test new ideas, build new relationships, consolidate experience. Centralised and devolved are two sides of the same coin.

That’s a useful framing. Centralisation as part of a dynamic strategy for organisational learning. We cycle between centralised and devolved in order to adapt, learn, improve, then re-adapt as circumstances change.