Playing All the Right Notes: What Stafford Beer Can Teach Us About Data Governance

Every organisation I work with, from the five-person outfit running the business off a shared spreadsheet to the multinational with a Chief Data Officer and a governance operating model with its own org chart, eventually arrives at the same conversation: “who actually owns this data, and can we trust it?” Underneath that question is a much bigger one that most organisations never quite ask: is our data governance actually working as a data governance control system, or is it just a filing cabinet with a policy in it? That conversation usually starts because something has gone wrong. A breach. A dodgy AI output that made it into a customer letter. A regulator’s letter that lands with a thud on someone’s desk. A board member asking, not unreasonably, why last quarter’s numbers don’t add up to what Finance told them in the last board pack.

And it usually ends the same way. There is a new policy document, a committee, a tweaked RACI chart. Everyone has a general sense of relief that “governance has been done.” Nobody consults any of it again until the next crisis. You have what I call ‘governance on paper’ but not ‘governance in practice’.

I don’t think that’s a failure of effort. Most of the people building these frameworks are trying hard and mean well. It’s a failure of design. And it’s a problem that Stafford Beer, the British operational researcher who more or less invented management cybernetics, diagnosed with uncomfortable precision more than fifty years ago — long before “data governance” was something you could put after your name on LinkedIn.

Data governance as a control system, not a filing cabinet

Beer’s central insight, laid out in Brain of the Firm is that any organisation that wants to survive has to be understood as a control system. And that control system is sitting inside an environment that never stops throwing disturbance at it. Those ‘disturbances’ include customers, competitors, regulators, new technology, and — these days — a vendor in the corner promising that Generative AI will sort it all out for you. Beer, drawing on Ross Ashby’s Law of Requisite Variety, made the point that a control system can only manage the variety it can match. If your environment is complicated and your control mechanism is a static policy plus an annual audit plus a name plate with “Data Owner” printed on it, you are, structurally, bringing a kazoo to a performance of Grieg’s Piano Concerto. It doesn’t matter how well-meaning the person playing it is.

That’s really what a data governance control system is for, once you strip away the tick-box framing. It’s not a document. It’s not a certification your organisation can buy its way into. It is the mechanism by which the organisation senses that something is going wrong with its data, gets that signal to someone who can do something about it, and corrects course before the problem becomes expensive, dangerous, or front-page news. Seen that way, the size of the organisation is almost beside the point. The small business making decisions off that spreadsheet has exactly the same control problem as the bank running a model over its data lake — just a different scale of consequence when it goes wrong. Deciding you’re “too small” for a proper data governance framework is a bit like deciding you’re too small to need a nervous system.

The purpose of a system is what it does

I often find myself reminding my colleagues in Castlebridge, and our clients, of Stafford Beer’s famous acronym POSIWID:

“The purpose of a system is what it does. There is, after all, no point in claiming that the purpose of a system is to do what it constantly fails to do.”

Not what the mission statement says. Not what the governance charter promises the board. What actually, observably happens.

Applied to data governance, POSIWID is less a philosophy and more a diagnostic. If your organisation has a beautifully produced data governance framework sitting on the intranet, but the lived reality is that bad data flows unchecked into decisions, that an AI model gets waved through into production without anyone checking what it was trained on, or that “the business” and “IT” spend meetings blaming each other when something breaks — then, per Beer, the real purpose of that framework is to produce the appearance of control. Not control itself. That gap between the stated intent and the observed behaviour is exactly where risk, cost, and reputational damage quietly accumulate. It’s also, increasingly, exactly where a regulator will go looking.

This is the uncomfortable truth for organisations currently sprinting to bolt AI onto everything: a governance policy dropped on top of a system with no real feedback loops does not produce governance. It produces a document that says governance happened.

Governance is practised, not just designed

Stafford Beer gives us the architecture: the control system, the channels, the requisite variety. What he doesn’t fully explain is why perfectly sensible people, inside a perfectly documented governance structure, quietly fail to do the thing the structure asked of them. For that, I find it useful to borrow from two thinkers who are not usually invited to the cybernetics party: Mark Bevir and Karl Weick.

Bevir’s decentred theory of governance makes the point that governance is never just the formal structure on the org chart. It is the accumulated product of situated agents — real people, in real roles, acting on beliefs that are shaped by traditions they inherited long before they read the policy, and modified by the dilemmas they encounter along the way. Nobody in your organisation is executing the governance framework as written. They are executing their own web of belief about what the framework means, filtered through whatever tradition tells them data governance actually is: a bureaucratic overhead to be minimised, a legal obligation to be satisfied, or a genuine discipline that protects the organisation and the people whose data it holds. Beer’s control system only works if the humans inside it share something close to a common tradition about what “doing governance well” looks like. Where those traditions diverge — where Marketing’s web of belief about data quality is nothing like Risk’s — the algedonic channel can exist on paper and still not fire, because nobody upstream believes what’s happening downstream is actually a problem worth escalating.

Weick’s work on sensemaking explains the other half of the puzzle: why the gap between what POSIWID reveals and what people believe is happening can persist for so long without anyone noticing. Weick’s central, slightly unsettling observation is that sensemaking is retrospective — we make sense of what we did after we’ve already done it — and it is driven by plausibility rather than accuracy. People inside an organisation are not running a continuous, accurate audit of whether governance is working. They are constructing a plausible enough story, after each quarter or each committee meeting, that things are broadly fine, because that story is consistent with their sense of their own competence and their organisation’s identity as a well-run place. That story gets enacted: people act as though governance is working, which produces the very evidence — the completed RACI chart, the signed-off policy, the committee minutes — that makes the story more plausible next time. It takes a genuine rupture, a breach, a regulator’s letter, a bad AI decision reaching a customer, to force a retrospective reinterpretation in which the organisation suddenly, and often painfully, makes different sense of the same governance arrangements it had been living with for years.

Put Beer, Bevir, and Weick together and you get a fuller picture of the control problem. Beer tells you what the control system needs structurally: requisite variety, feedback loops, algedonic signalling. Bevir tells you that the system is only ever actually run by situated people acting on inherited traditions and locally negotiated beliefs, not by the policy document itself. And Weick tells you why those people, and the organisation as a whole, can carry on believing the system is working long after POSIWID would tell you otherwise, because sensemaking favours a plausible story over an accurate one until something forces the story to break.

Three feedback loops, not one

The thread that actually ties all three of them together is the feedback loop, and it’s worth being precise about it, because Beer, Bevir, and Weick are not describing three separate phenomena. They’re describing the same control problem operating at three different speeds.

Beer’s loop is the one governance frameworks are usually built to talk about: sense a deviation, signal it, correct it, and — where the deviation is serious enough — let it travel as an algedonic signal that skips the ordinary chain of command. This is the fast, mechanical loop: the data quality alert, the model monitoring dashboard, the escalation trigger. It’s necessary. It’s also nowhere near sufficient, because a signal firing correctly is not the same thing as anyone acting on it.

That’s because underneath Beer’s technical loop sits a second one, and this is where Weick turns out to be more directly relevant to cybernetics than he’s usually given credit for. Weick’s sensemaking cycle — enact, select, retain — is itself a feedback loop: the organisation acts, generates cues from that action, interprets those cues, and retains an interpretation that shapes what it notices and does next. Crucially, Weick makes exactly the same move Beer does. He draws directly on Ashby’s Law of Requisite Variety, arguing that an organisation needs a repertoire of interpretations rich enough to register a genuinely equivocal signal for what it is, rather than filing it away as noise. A data anomaly can trip Beer’s technical sensor perfectly and still die in Weick’s loop, because the people looking at it don’t have the interpretive variety to recognise it as the dilemma it actually is. They retain the more plausible, more comfortable reading — “that’s just how the numbers look this quarter” — and the loop closes on the wrong answer.

And underneath that sits a third, slower loop again, which is Bevir’s. What gets retained as “the plausible interpretation” is not selected at random. It’s filtered through a tradition — the inherited, shared understanding of what data governance is for in this organisation — and that tradition itself only changes when a dilemma is serious enough, and repeated enough, to force a revision of the belief. This is a feedback loop too, just an extremely slow one: dilemma modifies tradition, tradition shapes what counts as a dilemma next time. If your organisation’s tradition treats an escalation as an act of disloyalty rather than good governance, that feedback loop will keep suppressing the very signals Beer’s architecture was built to surface, no matter how well the technical sensor is calibrated.

For data governance, this means a working control system needs all three loops closed, not just the fastest one. You can have a beautifully instrumented data quality dashboard — Beer’s loop, functioning — feeding into a team that doesn’t have the requisite variety to interpret an unusual pattern as significant — Weick’s loop, failing — inside a culture that treats “flagging problems” as making a fuss — Bevir’s loop, actively working against you. Every governance failure I’ve seen up close turns out, on inspection, to be a break in one of these three loops rather than the complete absence of a policy. The policy nearly always exists. It’s the loop behind it that was never closed.

Real accountability, and the sinks we build by accident

This is where I want to draw a hard line between actual accountability and what’s increasingly, and usefully, called an “accountability sink.” An accountability sink is a structure in the data governance control system, usually built with entirely good intentions, through regulation, incentive design, or one too many layers of organisational hierarchy, where responsibility is formally assigned but nobody is actually able to discharge it. There’s a name on the org chart. There’s a line in the policy. But no one in that chain is positioned, resourced, or incentivised to spot a real problem and act on it before it causes harm.

Nobody sets out to build these. They emerge from exactly the kind of well-meaning governance activity organisations undertake to look responsible: a compliance function with a mandate but no operational authority to actually stop something; a “data owner” who owns the label on the RACI chart but not the budget, tooling, or time to fix a known quality issue; a three-committee sign-off process where the diffusion of responsibility means that no single committee ever feels the full weight of the decision. Beer would have recognised this instantly as a failure of what he called algedonic signalling — the channels through which pain (a genuine, urgent problem) is meant to travel fast to whoever can act on it, bypassing the normal, slower chain of command entirely. When those channels don’t exist, or are buried under routine status reporting, problems fester quietly until they surface as a crisis. At which point the organisation discovers, to its horror, that everyone followed the process and nobody was actually watching.

This is exactly where Bevir and Weick earn their keep. An accountability sink is rarely a structural defect anyone deliberately designed. It’s what happens when the situated agents inside a decentred governance arrangement each hold a locally plausible belief that “someone else has this covered” — a tradition of deference to the next committee along, modified over time by whichever dilemma made escalating awkward last time — and the organisation’s collective sensemaking keeps enacting a story in which everything is under control, because that story is more plausible, and considerably more comfortable, than the alternative. Nobody is lying. Everybody is making locally reasonable sense of an ambiguous situation. The sink is the accumulated, unintended output of that sense-making, not a decision anyone took.

Real accountability, in cybernetic terms, requires three things at once: the authority to act, the information to know that action is needed, and a feedback loop short enough that the person accountable actually feels the consequence of getting it wrong. Miss any one of those three, and what you have isn’t governance. It’s theatre. Give it long enough, and it becomes an accountability sink.

Building a data governance control system that actually works

For organisations trying to manage risk, control cost, or bring AI and analytics in responsibly (see our earlier look at the decision intelligence gap in AI strategy), a cybernetic lens gives you a rather different checklist than the usual policy-and-committee approach.

Test your governance by what it does, not what it says it does — go and look at actual data flows and actual decisions, not just the policy describing them. Put authority and responsibility in the same hands: if someone is accountable for data quality or model risk, they need the standing and the resources to intervene, not just the title. Build escalation paths for genuinely serious problems that can bypass the routine reporting cycle entirely — the way Beer’s algedonic signals skip the ordinary hierarchy — so that a real data or model failure surfaces in days, not at the next scheduled steering committee three weeks from now. And make sure the governance mechanism itself scales with the variety of the risk it’s managing.

A simple checklist is requisite variety for a low-stakes spreadsheet. It is nowhere near enough for a customer-facing AI model making decisions at scale. This is, ultimately, what a data governance control system has to deliver: not a document, but a working loop from signal to action, held together by people who actually believe escalating is the right thing to do — a point I’ve made before about why we sometimes have to legislate for the tiresome rather than trust good intentions alone.

Why this matters more, not less, when you start automating

Here is where I think Beer becomes essential reading rather than interesting background, because this is exactly the moment most organisations are living through right now. Somewhere in your business, someone is building a case for automating a function, deploying a Generative AI tool, or standing up an agentic process that will make decisions, trigger transactions, or take actions without a person in the loop for every step.

Before any of that happens, you need to understand two things, and Beer, Bevir, and Weick between them give you the language for both. First, you need to understand the system you’re proposing to automate — not the tidy version in the process diagram, but the one that actually runs, with all its informal workarounds, exception handling, and the tacit judgment someone quietly applies that never made it into a job description. That informal layer is Bevir’s situated agency at work: the traditions and locally negotiated beliefs your people have built up about how the process really behaves, and the retrospective sense they’ve learned to make of its edge cases. It rarely survives contact with a process map. Second, and this is the part that gets skipped, you need to understand the system of governance around it: where does the requisite variety live today, who currently receives the algedonic signal when something goes wrong, and who is actually accountable, in the sense of having the authority and the standing, not just the title, to intervene?

Automate the first without understanding the second, and you don’t get efficiency. You get an accountability sink at scale. A human doing a task badly is a problem you can usually see and correct because someone, somewhere, notices and says something. An AI agent or automated process doing the same task badly, at speed, across every case that flows through it, with the human reviewer removed because the whole point of the exercise was to remove them, is a problem that can run for months before anyone’s algedonic signal fires. By then it isn’t a data quality issue. It’s a regulatory finding, a mis-selling scandal, or a customer harm case with your organisation’s name on it, and a governance framework that “existed” but had no mechanism capable of catching it.

This is not an argument against automation, or against Generative AI, or against agentic systems doing real work. It’s an argument for sequencing. Understand the viable system before you re-engineer it. Understand where control, variety, and accountability actually sit today before you remove the human layer that, however informally, was providing some of it. If you can’t answer who is accountable, who would notice if it went wrong, and how quickly that signal would reach someone empowered to act, you are not ready to automate the function. You are ready to automate the accountability sink, and hand it a much bigger amplifier.

They’re already playing the notes. Before you hand the instrument to a machine, it’s worth knowing whether anyone would notice if the tune went wrong — and whether your data governance control system was ever really a control system at all.

(Update: 2nd September 2026: Wait.. there’s more… the second article in this series is available on the TDAN resource pages on DataVersity.net – read it here!)