AI transformation: faster work, different constraints?

AI can make research, analysis, development and production faster, sometimes even considerably better. I am optimistic about that, and you could also say, I'm an optimist in general. But once a team can do in an afternoon what used to take a week, it matters rather more what happens to the work afterwards.

Does someone use it? Does it wait for a decision? Does it come back because a requirement nobody mentioned at the start has suddenly become important?

I recognise this from a production business I used to run. We could build, adapt and localise assets at a speed and cost the client could not match in-house. Making the work had become manageable. Getting it released could still be excruciating complicated.

Image rights differed between countries. Legal clearance and local requirements had to be resolved. Launches needed to happen together with a "global" or at least regional launch date, with a lot of competitors watching. A perfectly good asset could sit waiting for someone who had several other priorities and very little reason to share our urgency.

I spent a surprising amount of my time working out whose yes we needed, in which order, and flagging local risks the client had not yet seen. It was probably the most political role I have held.

What we changed

We started with the briefing. We halved the number of steps, where able to moved a part of the approval process of distribution, before production started, and we automated parts of the briefing questions so that work could be completed and picked up faster. Where the necessary decisions had already been made, work delivered to the agreed brief could go straight to publishing.

Across those changes, we reduced the hours spent correcting and adjusting work after first delivery by 30%.

Some of the judgement we needed had simply been arriving too late. By the time someone raised a concern, people had invested time, a deadline was approaching and changing direction meant redoing finished work. It seems so logical now, asking for feedback before we run production, saved us and the client a lot of work.

That experience predates the current AI wave, which is partly why I find it relevant. We already know something about what happens when one part of an organisation becomes much faster than the parts around it.

Goldratt described the underlying problem in The Goal, written with Jeff Cox. Improving an activity does not necessarily improve the output of the whole system. You have to understand what limits it, and revisit that diagnosis when the constraint changes as a continuous loop.[1] AI gives us plenty of reasons to revisit it.

Sometimes the answer will be a decision. It could equally be poor source data (lack of data unification), an unclear brief or a lack of demand for what we have become so good (and quick) at making. However, calling everything a governance problem would be another way of avoiding the diagnosis.

The politics is already there

Thomas Marzano has written about the shift in authority that comes with agentic systems. In From Politics to Protocol, he examines how informal influence can become embedded in permissions, escalation rules and workflow design. His later Who Sets the Defaults follows that authority upstream.[2]

I recognise much of what he describes. It also leaves me thinking about the practical difficulty of changing those arrangements inside a business that still has work to deliver on Monday.

Research by Hickson and colleagues in 'Theory of Intra-organizational Power,' helps explain that difficulty. Their work links departmental power to the ability to handle uncertainty that others depend on you to resolve, the centrality of your work and how readily you can be replaced.[3] Making the process better may change all three. A proposal to simplify an approval can therefore mean something quite different to the person giving it than to the person waiting for it.

And sometimes the person everyone depends on would be delighted to have less power, if it meant having an uninterrupted afternoon. Brent, a great character of the overworked and indispensable engineer in The Phoenix Project (which derives most of its value from The Goal of Goldratt), is a useful reminder of that. Everything difficult finds its way to him, leaving him little time for the work that might make him less necessary.[4]

Therefore, I think it is vital to understand that dependency before deciding whether to automate the approval, remove it or give the person more help.

A policy people could use

Later, in a group of operating companies of a big B2B buy & build, I encountered an AI policy that hardly anyone knew existed or seemed to follow. People were already experimenting with free accounts, dozens of different tools, all with little practical guidance about the consequences.

The marketers working in those companies were quite clear about what they wanted: tell us what we can do, what we cannot do, but please let us also experiment.

We wrote a handbook around the decisions they were actually facing. Which tools were approved for work. What information could go into them. Which uses of AI generated imagery needed further checking, and where to find an approved alternative.

I wanted people to have enough information to think before they acted, without needing permission for every ordinary task. There would still be questions the handbook could not settle. At least we could make the everyday ones easier to answer.

The fact that a policy existed told us very little about how the work was being done. This might be an uncomfortable thing to admit when your job includes governance, but it is a useful place to start.

One book that is able to make room for this distinction is Sutton and Rao's The Friction Project: some friction obstructs useful work; some helps people make better decisions.[5] I tend to look at the consequence, whether a decision can be reversed, and what we still do not know (unknown - unknowns). A variation of an approved asset under the same conditions may need very little checking. A new product-safety claim needs someone qualified to examine it, however quickly the copy was produced. I believe the purpose of improving the process is to give that judgement time where it matters.

After the first improvement

Choudary argues that AI changes where scarcity, and therefore advantage, sits.[6] Inside an organisation, I think the implication is quite practical: the process you have just improved needs to be watched again, in a continuous loop. More capacity in one place changes what is asked of another.

That does not mean continually reorganising everyone. It does mean paying attention to where work waits, what gets redone and which questions keep coming back to the same person. Those observations can tell you way more than a dashboard showing how many hours an AI tool saved.

The questions I have been using and implementing are fairly ordinary. What is worth improving? What limits it now? Who can change that? What needs to remain dependable while we do?

I would ask the people doing the work, including the ones who keep raising inconvenient concerns. They may have spotted the next constraint before it appears in the numbers. They should be able to explain what they see, and have a way to get it addressed.

In conclusion:

AI makes it possible to improve and deliver more "work", more quickly. Realising that possibility will involve changing decisions, responsibilities and habits that were reasonable under different conditions. In my experience, that work takes longer than introducing a few useful tools. It is also exactly where much of the value can be created.

That is why I built the Enterprise AI map: to explore where the work waits once the agents are in place, and who is accountable for making it all work together (found on my website)

Sources and further reading

Eliyahu M. Goldratt and Jeff Cox, The Goal: A Process of Ongoing Improvement (1984). See Goldratt Research Labs' Introduction to Theory of Constraints for the five focusing steps, including returning to the diagnosis once a constraint has been overcome.Thomas Marzano, “From Politics to Protocol”, 10 March 2026; “Who Sets the Defaults”, 19 April 2026. These directly address political authority, permissions and the governance of AI-mediated work. His “The Agentic Brand Operating System”, 12 June 2026, develops the operating architecture, including decision rights and escalation. For further reading and exploration, find his Field Guide here; https://www.marzano-consulting.com/agentic-brandingDavid J. Hickson and colleagues, “A Strategic Contingencies' Theory of Intraorganizational Power,” Administrative Science Quarterly 16(2), 216–229 (1971). University publication record. See also “Structural Conditions of Intraorganizational Power” (1974), full text, the subsequent empirical study of uncertainty, workflow centrality and nonsubstitutability. Applying this research to AI transformation is my interpretation.Gene Kim, Kevin Behr and George Spafford, The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win (2013). See the publisher's 10-minute summary for Brent's role as an overworked constraint.Robert I. Sutton and Hayagreeva Rao, The Friction Project: How Smart Leaders Make the Right Things Easier and the Wrong Things Harder (2024). See Stanford's “Career Advice: How to Become a ‘Friction Fixer’”. Consequence, reversibility and uncertainty are the practical considerations used here, rather than a framework attributed to the authors.Sangeet Paul Choudary, “Strategy in the age of AI: Eight points beyond the obvious”, 23 August 2026. A directly accessible account of his argument about shifting scarcity and system-level advantage, developing ideas from Reshuffle.

Related pieces: The hidden politics of AI adoption and The coordination problem no agentic roadmap has priced.