2200 words (10 minutes reading time) by Colin Weatherby

Credit: Copilot

This post continues the story of council IT investment, which started with 293 – IT investment: Dangerous Enthusiasm or Due Diligence?, and 294 – If the Vendor Won’t Bet on Savings, Why are you? This time, I look behind an IT investment to find out what matters if the money you are spending is to going to get you the anticipated benefits. I have taken the thinking from Stafford Beer’s 1973 Massey Lectures, including his department store parable, and carried it into local government.

Tuesday morning, nine o’clock

The Council Office doors open. Within the hour, thirty people have come through.

Some are at the rates counter. Some want a bin emptied. Someone is upstairs asking what happened to a building permit lodged back in March. The phones are ringing, the chatbot is fielding enquiries on the website, and the info@ inbox is filling at its usual steady rate.

One of the thirty is a resident with five things on her mind.

A dog two doors down barks all night. Leaves are blocking the stormwater grates and there’s standing water on her street. Someone has dumped a mattress at the edge of the park behind her house. The waste truck left her empty bin lying across her driveway again. And her neighbour across the road — in his eighties — seems to be struggling. The lawn hasn’t been cut in months, the mail is piling up, and she isn’t sure whether to phone someone or mind her own business.

She is not a Local Laws matter. Or a Road Maintenance matter. Or a Waste Management matter. Or a Community Services matter.

She is all of them at once.

What the council does with her tells you almost everything about how well it is designed. Keep her in mind. We’ll come back to her.

The one rule that governs all of this

There’s a deceptively simple law at the centre of whether any organisation works or fails.

Only variety can absorb variety.

Ross Ashby named it, and Stafford Beer, writing in the 1970s, made it real with the example of a department store. Every customer who walks in generates variety, They have a particular need, at a particular counter, at a particular moment. The store either has enough on hand to absorb that need (i.e. the right person, at the right counter, with the right thing) or it doesn’t. When it doesn’t, queues form and the whole thing tips out of control.

A council has the same departmentalised structure, but the counters have different labels. More importantly, citizens don’t have the choices a customer has. There isn’t store down the street to provide services the council can’t and absorb the variety.

Every citizen who makes a request introduces variety: a specific combination of need, history, expectation and circumstance that didn’t exist until they arrived. That variety has to be absorbed by something, or the council simply fails to do its job.

How a council swallows variety

Councils absorb variety the way a department store does — by carving it into departments. Rates here, parking there, planning over there, parks upstairs, community services down the road.

Each department exists because the variety it holds is similar enough that a small team can build the competence to handle it. A planning officer learns the range of planning questions. A rates officer learns the range of rates questions. And the council quietly assumes that, between them, every department covers every need.

They never do. Because not every citizen arrives pre-sorted to match the council’s structuring of services.

Two filters sit between a citizen and the council’s resources. The first is the front counter and the call centre. Their job is triage: absorb what they can on the spot and pass on what they can’t.

The second, and by far the more powerful, sits inside each department: the service delivery model. This is the standing description of demands the department accepts, the criteria a request must meet, the steps it will follow, the standard it will be judged against. Before any work is done, the request is assessed against this model. If it fits, the department runs the model. If it doesn’t fit, the file is closed, the citizen is referred onwards, or their request must be resubmitted in a form the model can handle.

This is where most of the council’s variety attenuation actually happens. The service delivery model is the council’s standing decision about which types of citizen variety it will absorb — and which it won’t.

What happens to our resident

Both of these filters work on her in sequence, and everyone involved does their job.

The counter logs the bin in the driveway and messages the waste contractor. Local Laws opens a barking-dog file and asks her to keep a log. Road Maintenance schedules a street sweep — due in three weeks. Parks sends a crew for the dumped mattress.

And the note about the elderly neighbour? That isn’t really a service request — she isn’t asking the council to do something for her; she’s asking it to do something for someone else who hasn’t asked for help. It fits no intake model cleanly. So, it’s set aside, or logged as a category like “community wellbeing observation,” to sit in a queue for action by someone, eventually.

At no point does anyone hold the whole picture of her street.

She has been absorbed — departmentally, service by service — and the pieces that didn’t fit quietly dropped into the “too hard” basket.

She walked in as one neighbour with an interlocking set of concerns. She leaves as four cases, and one dropped observation. The council’s response is technically correct and substantially useless.

That’s not a failure of effort. Every officer did their job. It’s a failure of design.

Now bring in the technology

This is the point where senior management usually reaches for a tool.

Beer named three tools for amplifying an organisation’s capacity to absorb variety: the computer, the communications network, and the science of effective organisation — what he called cybernetics. Half a century on, the first two are everywhere. The third is still the least practised of the three.

Councils have bought computers in enormous quantities. The current flagship purchase is the Enterprise Resource Planning system — the ERP — the big integrated platform meant to unify finance, HR, assets, procurement and customer requests into one source of truth.

The pitch that lands on your desk today is, almost word for word, the pitch the mainframe vendors were making in Beer’s day.

Move your existing services onto the new ERP, as they are, and the platform will integrate whatever you were already doing to make it faster and cheaper.

The CEO is persuaded, because the current way of working is a known expense that is only increasing and the vendor says the platform will cut costs. The councillors are persuaded, because they are told everyone else is doing it and, like the CEO, they don’t want to be left behind. Procurement happens. The platform goes live.

And then the citizens meet it.

Why the ERP makes it worse, not better

Here is the uncomfortable part.

An ERP is not a variety amplifier helping the council to absorb variety in demands. By its nature, it is a variety attenuator — the most powerful one the council now owns.

Its whole value proposition is standardisation. Defined fields. Mandatory categories. Fixed workflows. Eligibility rules encoded once and applied everywhere. Controlled drop-down menus instead of open conversations. The ERP takes the service delivery models — the very filters that have already chopped our resident’s demand into four cases and a dropped note — and hard-codes them into software, at scale, across the entire organisation.

So, the mismatch that was already there doesn’t get resolved. It gets cemented, and then it gets multiplied.

The tool has been used on the wrong side of the equation. Instead of amplifying the council’s capacity to absorb what citizens bring in, it amplifies the council’s own output — more notifications, more automated messages, more form letters, more dashboards, more controls, more requests to “please resubmit using the correct category.” The citizen is not better served. Often, they’re worse served, because they’re now dealing with a system that can produce the wrong answer faster than a human ever could.

Unfortunately, they don’t have the choice of another store. Every wrong answer is not the end of the transaction. It’s a new piece of variety — a fresh problem — arriving back at the front counter, where someone now has to undo what the system did. Systems thinkers call this failure demand: demand created by the council’s own failure to do the right thing the first time. It is the most expensive demand in public services, because it comes back again and again through channels never designed for it. Angry residents now contact their ward councillor, who lodges a request for them.

The complaints inbox swells. The councillor request escalation queue lengthens. The phones that were meant to ring less, ring more. The time the system takes to deal with one request and be ready for the next — what Beer calls the relaxation time — was already too long. Now it stretches further still.

The underlying instability isn’t fixed by the new platform. It’s amplified by it. Exactly as Beer said it would be.

“The system won’t let me do that”

So what does the council say afterwards?

Not, of course: “We didn’t understand how the technology would work, and we’ve spent a great deal of money turning a poorly designed service into a worse one, now at scale and speed.”

What it says is: “Unfortunately the system doesn’t allow that. Please contact us via the form on our website.”

As always, the technology is the problem.

Except it isn’t. The technology did precisely what it was asked to do. The mistake was made much earlier when the existing service design was assumed to be ready for automation. It should first have been tested against what citizens actually need, before anyone committed to scaling it with technology.

Cost is the wrong place to start

The objection to redesigning any of this is always cost. This deserves some consideration.

The cost that is known is the cost of doing what the council currently does, in the way it currently does it. It is downstream of the service design, not upstream of it. Design differently — different departments, different roles, different service models, different processes — and the same outcomes might cost far less, or the same money might do far more.

The right first question is not “what does this cost?” It is “does the service have enough variety in it to match the variety of what citizens actually need?”

If the answer is no, the service will fail no matter what you spend on it. Pouring resources — or a new ERP — into a design that can’t match the variety in front of it is just paying more to fail. And a large IT programme is a very effective way to spend a great deal of money making a system fail more efficiently.

Cost only becomes a meaningful question if the design can absorb the demand.

What this means before you sign the contracts

You don’t have to accept Ashby’s Law. But you can’t repeal it either. It will assert itself whether or not the business case mentions it.

So, before you commit to an ERP, three questions are worth more than any vendor demonstration.

First: what variety are we actually being asked to absorb? Study the demand your citizens really bring, not the categories the current system records. Test if your response meets citizen needs and expectations. Our resident’s street is one unit of demand, not four cases and a dropped note.

Second: can our service design absorb that variety before we automate it? If it can’t, automating it will multiply the mismatch, and create more failure demand. Redesign first; digitise second. Never the other way round. The service model needs to deliver services that meet resident needs and expectations before any benefits from automation can be evaluated.

Third: is this tool pointed at absorbing citizen variety, or at multiplying our own output? If the platform’s headline benefits are speed, volume and push messaging, it is almost certainly aimed at the wrong side of the equation. Then, it won’t help residents with their needs – it might help the council check the boxes for compliance.

Back to Tuesday

Somewhere in the queue, our resident is still holding five concerns that belong together.

No amount of software will help her if the council has already decided, in its models and its menus and its mandatory fields, that she must arrive as four separate things and one that doesn’t count. The best ERP in the world, faithfully executing that decision, will only ensure her requests are dismembered faster and at greater cost.

Beer’s warning was never really about computers. It was about the temptation to buy a tool instead of doing the harder work of redesigning the organisation around the people it exists to serve.

The tools amplify whichever side of the equation you point them at. Point them at understanding and delivering on your citizen’s needs and expectations, and they help enormously. Point them at automating current processes and producing more output without first understanding what’s happening, and they will fail expensively.

You will know this has happened when you must reimplement parts of the ERP within months of project completion because it doesn’t work the way staff and the community need it to work.

A note on how this blog was written

This piece was written with the help of an AI assistant (Claude, made by Anthropic). The framework and source material were mine: an original parable adapting the department-store section of Stafford Beer’s Designing Freedom to a council setting, together with a companion reflection linking it to the systems-thinking tradition. The brief was also mine — take the council-office story as the hub, keep the title “Carrying Beer into the Council Offices”, write for council senior management, and focus on how councils misuse IT systems, particularly ERPs, when they fail to understand variety in demand. It had to read well on a phone.

The assistant did the drafting and formatting: writing the prose to the brief, placing the ERP as the technology in the frame, and structuring the piece so the Tuesday-morning resident recurs from opening to close. I then did the editorial and domain work — correcting department names to real council functions, refining who is persuaded and why, adding the councillor-request escalation loop, sharpening the closing prediction about reimplementation, and tightening throughout — before a final review pass.

The framework, the brief, the domain judgement, and the final editorial control are mine; the drafting and formatting were the assistants. Stafford Beer’s department-store parable supplied the underlying scaffold, with his own phrasing not reproduced.