I am seeing a lot more of this in the leaders I work with, briefing papers to boards and executive teams are getting longer. There isn't more to say.

Saying more is now free. A briefing that took a day to write can be generated in minutes, and it arrives polished, structured and confident.

The research is catching up. In September 2025, Harvard Business Review published a study from BetterUp Labs and the Stanford Social Media Lab that named the pattern "workslop": AI-generated work that looks good but lacks the substance to advance the task. Of 1,150 US workers surveyed, 40% had received some in the past month, and they estimated about 15% of what lands in front of them fits the description. Some of it travels upward, from direct reports to their managers.

The researchers' central point is that it shifts the burden downstream. The receiver has to interpret, correct or redo it.

Only writing got cheap.

Reading, weighing and deciding did not. A busy leader still has one evening with the pack. They receive text the author may never have thought through, and are left to do the reflecting on a smaller time budget. If they reach for an AI summary, a machine condenses what a machine wrote, and the person who signs off meets a summary of a summary.

Why it happens

Jeff Sparrow's recent essay in The Conversation is about Australian universities, but the mechanism travels. His argument is that AI didn't break higher education. It landed in a system that already rewarded the appearance of work over the work itself. He quotes a historian describing AI as "a catalytic solvent, titrating out the incoherence that was always there."

He points to one academic journal where submissions rose 42% after ChatGPT arrived, with editors blaming AI combined with publish-or-perish incentives. He also notes that some universities encourage AI-assisted grading, provided a human being is in the loop.

Organisations have the same shape. Where effort is measured by documents produced, documents will multiply. And "a human signs off" is a weak control when no human could realistically read what is being signed. Approval without reading is ritual, not oversight.

This is a governance problem, not a technology one. It sits in decision rights and expectations, and nobody has made the decision.

What to do about it

Leaders often complain about the overload, and some quietly stop reading. Neither helps. The leader is the one person with the authority to set the terms of what reaches them. For example:

• Two pages maximum, or a 15-minute slot, whichever suits the matter.

• The decision needed, stated at the top.

• A recommendation, not a menu of options left for the reader to sort out.

• What the author checked themselves, and what they are unsure of.

• A short live conversation where the author defends it.

The constraint does the real work. It forces the author to decide what matters, which is exactly the thinking AI lets people skip.

Some universities are heading the same way.

NYU Stern researchers describe students handing in polished project work they couldn't explain under follow-up questions, and have trialled voice-AI oral exams in response. Ireland's higher education authority has proposed an "oral assessment safeguard": inviting a student to explain and defend their work when authorship is in doubt. It is early and uneven. Many UK universities keep viva exams for suspected misconduct because live questioning is costly to run at scale. But the logic carries. A document can be generated. The understanding behind it can't.

The part that falls to the leader

A standard only exists while the person who set it honours it. Read what meets the rule. Engage with the recommendation. Give a decision. Send back what doesn't comply, unread. Send short things yourself. The first time a leader waves through a 20-page paper they didn't read, staff learn the real rule, and the stated one becomes decoration. The HBR researchers land in the same place: leaders should set clear norms and model purposeful use. Leading by example isn't a nice extra here. It is the mechanism.

Take this to your next meeting

Choose one: set a page limit and ask every author for a recommendation, or accept that you are approving papers you haven't read. And ask the room: could anyone defend the longest paper we accepted this quarter without opening it?

Sources

Jeff Sparrow, "Friday essay: AI is devastating higher education, but the system was already broken", The Conversation, 23 Oct 2026. https://theconversation.com/friday-essay-ai-is-devastating-higher-education-but-the-system-was-already-broken-292988

Kate Niederhoffer et al., "AI-Generated 'Workslop' Is Destroying Productivity", Harvard Business Review, 22 Sep 2025. https://hbr.org/2025/09/ai-generated-workslop-is-destroying-productivity

Panos Ipeirotis and Konstantinos Rizakos, "Scalable and Personalized Oral Assessments Using Voice AI", arXiv, 2026. https://arxiv.org/abs/2603.18221

"Oral assessment as a safeguard for academic integrity", International Center for Academic Integrity, Mar 2026, citing the Irish HEA policy framework (2025). https://academicintegrity.org/aws/ICAI/pt/sd/news_article/631829/_PARENT/layout_details/false

Brumby, Cox, Sarkar and Gould, "Sampled vivas are pivotal in combating AI cheating", Times Higher Education, 6 Mar 2025. https://www.timeshighereducation.com/node/735603

Four decades of noticing the same shape recur; a certification, a decade in uniform, an MBA unit, thirty countries of workshops, a national infrastructure redesign, and being right about it, or wrong about it, with no real way for a reader to tell the difference beyond whether the story sounded convincing.

That’s the nature of a career told in hindsight, it persuades by narrative, not by evidence.

On 3 March 2022, that changed. I received formal ethics approval from the University of Otago Business School, reference 22/024, to begin doctoral research into Pacific data governance under a Doctor of Business Administration. From that date, the pattern I’d been noticing informally for thirty years became something I had to actually test, not just narrate, held to a standard well beyond whether it feels true to the person who lived it.

The approach is called insider action research, and it’s worth explaining, because it shapes everything this newsletter becomes from here.

Most research methodologies ask you to step outside the thing you’re studying, to gain the distance that’s supposed to produce objectivity. Insider action research does the opposite on purpose: it treats being embedded inside the practice, inside the institutions, as the position, not a bias to be corrected for. Coghlan and Brannick, whose work grounds this approach, treat an insider's pre-understanding as something to be made explicit, disciplined and tested, not simply asserted.

That’s not a loophole around rigour. It’s a different, harder kind of rigour, because the researcher can’t hide behind distance from what they’re describing.

What that means practically, for anyone still reading by post eight: I’m not going to stop writing from the inside.

That was never really the point of pattern-recognition mattering to me in the first place, and it isn’t the point now. What changes is what I’m allowed to say I’ve found.

Six posts of biography could reasonably claim to notice a pattern. What comes after this one has to earn a claim before making it, held against actual field evidence rather than a career’s worth of hindsight, and labelled honestly for how confident that evidence actually makes it, not more.

I don’t know yet exactly what shape that takes here, post to post. I know the shape of the discipline behind it, and I know it’s a stricter one than the six posts before this one needed. That’s not a caveat. It’s the actual reason any of this is worth reading from here.

You’re right. I aimed the questions at advice a director receives, but the post is about the writer’s own inside knowledge: what it is worth, and how it gets tested. The questions should turn that on the reader, who is also an insider in their own organisation.

For a director or executive

• What do you know about how your organisation really works, that comes from years on the inside rather than from anything you have tested?

• Pick one conviction you act on without thinking. If it were wrong, how would you find out?

• When you describe a pattern to your board or leadership team, do you say how well you know it: a hunch, something you’ve seen repeatedly, or something checked?

Want to know more about this Doctoral Programme at Otago University…it’s here.

Get that wrong, act fast on a stale read, and you get what I called noise with confidence attached. Decisive, wrong, and dangerous precisely because it doesn’t feel like a mistake while it’s happening.

More recently I wrote about a different decade, this one spent years advising boards, on formal committees, credentialed expertise in every chair.

And I described a gap that had nothing to do with anyone’s competence: rooms full of people who knew exactly what governance was supposed to mean, and a recurring sense that knowing it wasn’t the same as being able to act on it. Vocabulary, fluent. Standing to make it operate, somewhere else, or nowhere at all.

I wrote those two pieces weeks apart, about experiences twenty years apart, and didn’t notice until a reader pointed it out that they’re the same failure, just breaking at opposite ends of the same mechanism.

Both are failures of the same basic loop, observe what’s happening, orient to what it means, decide, act. The Army version fails at the front half: initiative is live, the authority to act is right there, but the orientation feeding it is wrong or stale. Fast, confident, wrong.

The boardroom version fails at the back half: the orientation is excellent, better than excellent, some of the sharpest diagnostic thinking I’ve sat in a room for, but there’s no reachable path from correct orientation to an actual decision. The loop has first-rate input and nowhere to discharge it. Correct, and still nothing happens.

I think the second failure is much harder to see, and that’s worth sitting with for a second.

The first one announces itself. Something breaks, visibly, and you can trace it back to a bad call made in a hurry. The second one never announces itself at all. Nothing breaks. The committee adjourns, everyone agrees the analysis was sound, and the next meeting picks up more or less where this one left off.

A loop that can’t complete doesn’t fail loudly. It just quietly never finishes, meeting after meeting, for years, while everyone in the room remains entirely right about what should happen.

I’ve started to think most institutions are extremely well defended against the first failure and almost undefended against the second, because the first one is the one every leadership course warns you about, don’t be the person who acts without checking.

Almost nobody warns you about the opposite trap: being the room that checks perfectly and never gets to act, because the standing to act was never actually in the room to begin with, and nobody thought to ask before the meeting whether it was.

That question, who actually has standing to close the loop, not just describe it correctly, is the one I keep finding wherever more than one legitimate source of authority is in play at once, which is most places if you look closely enough, and is close to unavoidable in some of the settings I’m now working in directly. I don’t have a tested answer yet.

I have a shape that keeps recurring, in a military doctrine and a decade of boardrooms, different enough contexts that I’m fairly confident it isn’t just me seeing what I expect to see.

Chris Argyris named something adjacent to this back in the 1970s: the difference between single-loop learning, which corrects an action without ever questioning the deeper structure producing it, and double-loop learning, which is willing to interrogate that structure itself.

A lot of governance committees, on this account, are extremely good single-loop learners, excellent at refining the analysis, never quite reaching the harder question of why the analysis never converts into a decision.

That’s the loop I’m interested in now, not the one that fails by moving too fast, the one that never gets to move at all.

Reference: Argyris, C. (1977). “Double Loop Learning in Organizations.” Harvard Business Review. Real and well-placed here.

Most of the trouble I have seen with data platforms, digital programmes and now AI was not a technology problem. It was one of those three questions left unanswered or answered in the wrong order. That is the argument of this newsletter. Everything else is evidence for it.

Who is writing

I am a governance practitioner and doctoral researcher. I'm a Fellow of the Chartered Governance Institute, working across the Pacific and Oceania.

I’ve worked in enterprise architecture and digital infrastructure, advised boards and public institutions, and worked with data governance in Pacific small island settings, where statutory and customary authority overlap. Much of that was national-scale work: alongside a Board of Directors through a two-year infrastructure transformation, advising government agencies in New Zealand, and working with NGOs and commercial organisations internationally on digital and data strategy development.

I am completing a Doctor of Business Administration at the University of Otago on a governance framework for data collaboratives, hence the coffee!

I write as a practitioner, in my own name. These are personal views. They are not the position of any employer or institution.

The argument so far, in six posts

• Before I Had a Word For It. Governance came before delivery. I first met it in a software certification.

• Whoever’s Closest, Decides. Authority is a design choice. Orientation comes before initiative.

• It Was Never a Technology Problem. What we call technical failure is often an authority and sequencing failure in disguise.

• The Year I Stopped Believing in Org Charts. Authority is built between institutions, continuously, not granted once.

• Not a Federation of Platforms. Who has standing to decide across institutions that do not report to each other.

• The Paper That Asks the Board to Decide Nothing. What the board table looks like from the adviser’s chair.

If you only read two, read Whoever’s Closest, Decides and Not a Federation of Platforms.

What comes next

Each essay keeps the same case-led voice. Each end with a short box of questions for directors and executives. And each pattern claim carries a label for how well the evidence supports it: early observation, approaching confirmed, or confirmed pattern.

What this is not

It is not a vendor pitch, a compliance checklist or a technical guide. It is one practitioner’s attempt to say, plainly and with evidence, what boards and leaders need to settle before they build.

If any of this matches something you're working through, or you think I've got it wrong, I'd like to hear it. Reply to this email or leave a comment.

From that vista, one pattern keeps repeating. A board receives a good paper, reads it carefully, and decides nothing.

A Paper that Describes is not a Paper that Decides.

A board gets a twelve-page paper on a digital or data programme. The risks are listed. The dependencies are mapped. The recommendation is “note the update.”

Nobody has done anything wrong. But the paper does not ask the board to decide anything, so the board does not. The risks go into the minutes. They are now recorded, and no one owns them.

I wrote papers like that. As an adviser I believed thoroughness was the job. I now think a thorough paper with no decision in it hands the board a problem and no way to close it.

The Person with Expertise is not the Person with Standing.

In the room, the adviser holds the knowledge. The directors hold something different: standing to say yes, no or not yet, and to be answerable afterwards. I do not carry that. They do. When those two things get confused, you get analysis that impresses and decisions that never land. It is the same pattern I keep meeting in programmes, only smaller and faster.

Silence in the Minutes is a Finding.

A risk that appears in the minutes with no owner, no date and no next step tells me something. The board saw the problem and could not find a way to act on it. That gap is where governance on paper turns into governance in practice…or fails to.

What I do Differently Now.

I put the decision on page one. I name who has standing to make it. I say what happens if the board does nothing. And I write for the director who is not technical and should not have to be.

I cannot tell you what it costs to be the one answerable for the outcome. Directors can. What I can tell you is what the gap looks like from where I sit, because I have watched it many times.

For a director or executive

• Does the paper you just for in your inbox, ask you to decide something, or only to note it?

• Who in the room is standing to close the decision, and are they answerable for it afterwards?

• Which risks in your last minutes still have no owner, no date and no next step?

• Could an adviser explain this paper to you without jargon? If not, who is it written for?

Please Note: These are my own views, written as a practitioner, and do not represent the position of any other organisation I work with. This piece was drafted with AI assistance and revised by me; nothing here is legal, financial or governance advice for your specific situation, if you're facing a live decision, talk to your own advisers, or local barista!

The pattern from the previous decade hadn’t gone anywhere. It had just found a bigger stage.

The engagement that mattered most from this period was a redesign of New Zealand’s national e-Science infrastructure (NeSI), the shared compute, storage, and research-support capability connecting universities, research institutions, and government across the country.

NeSI wasn’t broken in any way you could point to on a systems diagram. The compute worked. The storage worked. What didn’t work was harder to name: it operated as a federation of technical platforms, each institution’s piece governed on its own terms, with no coherent answer to the question a researcher actually asks, which is simply who do I go to, and what can I expect from them.

That question turned out to be the whole design problem!

Every institution in the federation had its own priorities, and its own sense of what NeSI was for. Nobody had designed the thing a user actually experiences, a consistent, accountable, end-to-end service, because everyone had been designing their own piece of the infrastructure instead. The technical redesign, when it came, was almost secondary. The real redesign question was how to govern and operate NeSI as one coherent national service for all researchers, with clear ownership of outcomes, rather than as a collection of platforms that happened to share a name.

I’d spent a decade by then noticing that governance problems wore technical costumes. NeSI was the first time I got to actually design the alternative, at national scale, rather than just diagnose the pattern after the fact. I stopped thinking about it as an infrastructure project and started thinking about it as a service, something with an owner, a defined handoff to the people using it, and an expectation that it would keep improving in successive, deliberate versions rather than being built once and left to decay.

None of that vocabulary was original to me.

Service design and IT service management had been saying versions of this for years. What was new, for me, was applying it to something as institutionally tangled as a multi-university national infrastructure, where no single actor had the authority to simply declare the redesign and make it so.

That’s the part of NeSI I keep coming back to. Getting the service design right was, in the end, the easier half of the problem. The harder half was governance in the literal sense, who had standing to decide what, across institutions that didn’t report to each other and never would.

Provan and Kenis’s work on network governance modes, a few years later, gave me a cleaner way to describe what I’d been improvising: that networks without a single controlling authority still need some form of coordinating structure, and the choice of which form is itself a design decision, not something that emerges naturally if you just get enough good people in a room. I’d built one version of that structure for NeSI without knowing there was a literature already describing the choice I was making.

Reference: Provan, K.G. & Kenis, P. (2008). "Modes of Network Governance: Structure, Management, and Effectiveness." Journal of Public Administration Research and Theory.

Over the better part of a decade, we delivered workshops in more than thirty countries across West and Eastern Europe, the Middle East, South America and the Asia Pacific, most of it through Microsoft Innovation Centres, which were never really technology projects at all.

They were collaborative arrangements between universities, city governments, and local industry, three institutions with three different mandates, three different funding cycles, and three different ideas about what success would look like, all expected to pull in the same direction because someone had put their names on the same MOU.

This was my first systematic encounter with multi-stakeholder governance, and it arrived as a practical problem long before it arrived as a concept.

Which decisions actually needed collective authority, and which just needed one institution to get out of the way?

Who held that authority when the answer wasn’t written down anywhere?

How was it supposed to work when a university operated on a semester’s patience, a city government on an election cycle’s, and a software company on whatever the market gave it that quarter?

I didn’t have good answers. What I had was a growing, uncomfortable sense that the org chart each institution walked in with told me almost nothing about how decisions would actually get made once the project was underway.

Out of that period came a piece of research I’m still, in a strange way, extending today: the notion of innovation as a messy undertakening in a local context, arrived at through a rich sedimented history of accidents, chaos and change, which I tested alongside a three-ecosystem model mapping the relationships between demand, supply, and innovation actors.

It sounds dry written down like that. What it actually taught me was a habit I’ve never lost, that capability isn’t something you design once and walk away from. It accumulates, or fails to, across repeated cycles of measurement, intervention, and whatever institutional memory survives from one version of the effort to the next. You don’t get it right the first time. You get a version, learn from what the version revealed, and release the next one.

The bigger shift, though, came from reading Duncan Watts alongside the doctrine I’d already absorbed from my Army Reserve years. Watts’s work on networks argued something that ran directly against how most institutions still described themselves: that relational, distributed structures were often more robust and more adaptable than hierarchical ones, not despite having less central control, but because of it.

Watching those thirty-country engagements up close, I could see it playing out in real time. The productive local software economies were never the ones with the cleanest governance chart.

They were the ones where the relationships between the university, the city, and the industry actually worked, where information moved, trust existed, and nobody was waiting for permission that had to travel through three institutions to arrive.

That was the first time I understood authority as something constituted between people and institutions, continuously, rather than something granted once and then simply held. It’s a small enough reframe to state in a sentence. It took me the better part of a decade, on the ground in thirty countries, to actually believe it.

The academic grounding came later, as it usually did for me. Watts and Strogatz’s 1998 paper on small-world networks gave the formal language for something I’d been watching operate informally for years, that the quality and structure of connections between actors matters more than any single actor’s position in a nominal hierarchy.

I keep finding this same order of operations in my own history: watch the pattern first, meet the academic/research paper that names it second!!

References:

Watts, D.J. & Strogatz, S.H. (1998). "Collective dynamics of 'small-world' networks." Nature.

So I went to study, partly out of frustration with my own inability to explain what I kept seeing. The MBA covered the usual ground, and none of it particularly changed how I thought. Then came the final unit: Services Marketing and Management. It wasn’t the subject I expected to be the pivot. It turned out to be the only one that was.

The core idea is simple enough once you’ve seen it, and almost invisible before you have: a service isn’t a product with some intangible extras attached. It’s a different kind of exchange entirely, built on interactions rather than deliverables, where the quality of the outcome depends on decisions made during the process, not just on what gets handed over at the end. Once I had that distinction, I went back through a decade of projects I’d watched go wrong and realised I’d been diagnosing every one of them incorrectly.

They hadn’t failed because the technology was wrong. The software mostly worked. They’d failed as services, the wrong question asked at the start, the wrong person consulted about a decision that wasn’t theirs to make alone, a handoff between teams that assumed context nobody had actually transferred. None of that shows up on an architecture diagram. All of it shows up, eventually, as a project that technically shipped and organisationally never quite landed. I’d spent years calling these technology failures because that was the vocabulary available to me. They were services design failures the whole time, and services design failures are much harder to see, because nobody puts “who gets consulted, and when” on a project plan.

What struck me most was how consistent the miscoding was.

It wasn’t that people were bad at noticing something had gone wrong, everyone always noticed. It was that the available diagnostic categories, technical failure, scope creep, poor communication, all pointed away from the actual mechanism, which was an authority and sequencing problem wearing a technical costume. Give someone the wrong diagnostic category and they’ll fix the wrong thing extremely competently, forever.

I didn’t leave that unit with a finished theory. I left it with a question that’s shaped everything since: if the thing that’s actually broken is how a decision gets made, who gets asked, and in what order, then most of what gets called a technology problem is really a governance problem that hasn’t been recognised as one yet. That question has followed me through every project, every sector, and every region I’ve worked in since, largely unchanged.

It wasn’t an original insight, even then. Vargo and Lusch’s work on service-dominant logic, a few years later, made the same reframing formally, arguing that value isn’t delivered in a product handoff but co-created through an ongoing process, exchange as service, not exchange as object.

I’d arrived at a rougher version of the same idea from the opposite direction, watching things go wrong rather than reading the theory first. It’s a pattern I’ve noticed about most of what I’ve learned this way: the literature was usually already there. I just met it after the practice, not before.

References:

Vargo, S. L., & Lusch, R. F. (2004). Evolving to a New Dominant Logic for Marketing. Journal of Marketing, 68(1), 1–17. https://doi.org/10.1509/jmkg.68.1.1.24036

Weekends and camps, I served in the Royal New Zealand Armoured Corps, inside a doctrine that organised authority almost the opposite way.

Manoeuvre warfare doesn’t wait for permission to travel up a chain of command and back down again.

The person closest to the situation makes the call, not because rank doesn’t matter, but because by the time a decision reaches someone further away, the situation it was made for has usually changed. The doctrine’s entire premise is that initiative has to sit with whoever has the clearest read on what’s actually happening, provided and this is the part that took me years to appreciate, their orientation has been properly updated first. Initiative without orientation isn’t manoeuvre. It’s just noise with confidence attached.

I never resolved the tension between those two models, and I stopped trying to. What I noticed instead was that each one was better than the other at something specific. The hierarchical model was good at consistency and accountability, you always knew who owned a decision after the fact. The manoeuvre model was good at speed and fit, decisions made by whoever actually understood the terrain, rather than whoever happened to hold the title. Watching them sit side by side in my own week, year after year, was the first time I really understood that “authority” wasn’t one thing. It was at least two different designs, built to solve two different problems, and most organisations only ever consciously chose one of them.

It would be a long time before I had proper language for any of this. John Boyd’s OODA loop; observe, orient, decide, act, eventually gave me a way to talk about why the manoeuvre model worked when it worked: not because someone was fast, but because their orientation was current. A commander with stale orientation making a quick decision is just making a confident mistake faster. That distinction, between speed and correctness of orientation, turned out to be far more portable than anything specifically military about it.

I’ve spent a good part of the years since watching organisations of every kind get this backwards: rewarding decisiveness while doing almost nothing to keep the person deciding actually oriented to what’s changed.

I don’t think the Army handed me a governance theory. What it handed me was a live demonstration, running in parallel with my day job for a decade, that authority is a design choice with trade-offs, not a fixed fact about how organisations have to work.

That’s a small thing to take from ten years of Saturdays. It’s also, looking back, one of the load-bearing pieces of how I now think about the question at all.

At the time I was doing the kind of work that doesn’t photograph well: moving data across refineries and power stations, standing in the gap between technical teams and the customers who had to live with what got built.

I’d learned, mostly the hard way, that the problems everyone called “technical” usually weren’t. The technology tended to work fine. It was the decisions around it, who got asked, who got skipped, when someone finally said yes…that caused the damage.

The Microsoft Solutions Framework (MSF) certification wasn’t sold to me as a governance course. It was a project methodology, decision rights, versioned releases, the structured trade-off between authority and delivery momentum. But somewhere in the middle of it, something clicked that I didn’t have a name for yet: this was a governance methodology, dressed as a technical one.

It was teaching, explicitly, that certain decisions had to be settled, and settled by the right person, before the technical work was allowed to proceed. Not because process demanded it. Because the work would eventually surface the decision anyway, at a worse time, at a higher cost, with less room to get it right.

I didn’t walk out of that course able to explain what I’d learned. I just started noticing it everywhere.

Projects that skipped the authority question didn’t fail cleanly, they failed slowly, months later, in a change request nobody could approve or a handover nobody was accountable for. The pattern was consistent enough that I started treating it as a kind of rule, long before I had any research behind it: governance precedes delivery, and if it doesn’t, delivery pays for it later.

It would be another three decades, through a services-marketing pivot that reframed “technical failures” as design failures, a stint in uniform that gave me a second, harder-won vocabulary for authority and initiative, and a run of infrastructure and network projects on three continents, before I’d end up studying this properly, in the one region where I’ve watched the pattern play out with the least room to hide from it.

Pacific digital and data programmes have a way of putting the authority question front and centre, whether anyone planned for that or not. I’m not sure yet how much of what I noticed in the 1990s survives contact with formal research. That’s rather the point of doing the research.

But the recognition itself, that governance is a precondition dressed as a technical detail, not an overlay applied afterward, is where this whole line of thinking started, and it seemed like the right place to start writing too.

The instinct isn’t original to me.

Decision-rights frameworks in IT governance, Weill and Ross’s (2004) work is the standard reference, have been making a version of this same argument for two decades: that the organisations getting real value from technology investment are the ones who worked out who decides what before they worked out what to build.

I arrived at the same intuition from the factory floor rather than the literature. It’s taken me a while to find out they were describing the same thing.

References:

P. Weill and J. W. Ross, “IT Governance: How Top Performers Manage IT Decision Rights for Superior Results,” Harvard Business School Press, 2004.