We Hosted Our First Manchester AI Roundtable. The Room Didn't Hold Back.

Most senior leadership teams have now seen AI do something impressive in a demo or a pilot. The harder question is how to turn it into a useful, dependable way of working.

I’ve been building software for more than twenty years. One thing that has become clear is how much successful outcomes depend on iteration: getting an idea into a form we can test, learning from it and improving it. The speed of that cycle matters because we rarely understand everything at the start. Each iteration gives us evidence for the next decision.

AI can shorten parts of that cycle considerably. It can help us explore an idea, build something to test and work through alternatives faster. It also introduces new ways to get things wrong: confident output that is wrong, confidential data pasted into a third-party tool, or an agent acting on a misread instruction. Faster execution only helps if we can assess the results and make sound decisions about what happens next.

A team may be able to demonstrate a capability in days, yet spend months working out whether it can be used. The technology has accelerated one part of the process while the organisation’s decision-making remains unchanged.

Governance is how an organisation decides which AI risks it will accept, and who makes that call. When it is designed from the top down, before there is a clear understanding of the work it will govern, it can become disconnected from both the opportunity and the practical decisions people need to make.

At The Curve, we approach this through use cases. Start with an outcome the organisation wants to achieve, understand the work involved, then establish the risks, controls and accountability around it. There is a useful connection here to an idea I first encountered when microservices were becoming popular.

What microservices taught us about coordination

I came across Conway’s Law around 2014 or 2015. Much of the discussion at the time focused on splitting applications into smaller services.

In a monolithic application, several teams can share a codebase and release process. A change may require coordination across those teams, tying their progress together. As the organisation grows, that coordination can become a constraint.

One appeal of microservices was the ability to give teams ownership of business capabilities, with clear interfaces and services they could deploy independently. James Lewis and Martin Fowler’s 2014 article makes this organisational connection explicit.

Splitting the code alone does not create independence. If every release still requires several teams to move together, much of the coordination problem remains. The benefit depends on aligning technical boundaries with ownership and decision-making.

Conway’s Law helps explain why. In his 1968 paper, Melvin Conway argued that organisations designing systems are constrained to produce designs that reflect their communication structures. His definition of a system extended beyond software.

An organisation’s AI governance process is one of those systems. The way an organisation distributes knowledge, authority and accountability influences the system of governance it can build, and the way AI adoption proceeds within it.

When every decision follows the same route

If AI decisions must travel through a central committee, adoption becomes dependent on that committee’s capacity and understanding.

A marketing team drafting content and an engineering team allowing an agent to change production systems are making very different decisions. They need different evidence, controls and levels of scrutiny. Sending both through the same approval route can make routine work wait while consuming the attention needed for more consequential decisions.

MIT CISR’s research on minimum viable governance describes a financial services organisation where a low-risk agent prototype that used no sensitive data took six months to approve, and frustrated teams went back to unsanctioned tools. Its recommendations include matching review intensity to risk, delegating authority and embedding controls into the platforms people use.

This is a capacity problem as well as a policy problem. As more teams identify useful applications of AI, the volume of decisions grows. A process that depends on a small central group reviewing everything can struggle to keep pace. A committee that meets monthly and can properly consider five proposals a meeting handles sixty a year. If ten departments each find three uses, and each use needs two or three changes in its first year, the committee faces closer to a hundred decisions, before any of them is high risk.

Senior leaders therefore need to consider which decisions require central oversight, and which teams can make within agreed boundaries.

When every improvement repeats the approval process

The coordination problem goes beyond the first approval. Once a team starts using a capability, it learns what needs to change. If each improvement requires another journey through legal, security and technology, the organisation puts the same coordination cost into every iteration.

This is Conway’s Law applied to the governance process itself. Separate functions assess their part of the proposal, and the governance process takes the shape of those organisational boundaries. The team carries information between them, reconciles their requirements and waits for their decisions.

That structure may get a proposal approved. It can also make the capability difficult to improve.

We have seen the equivalent in software: the distributed monolith, where services are technically separate but still require everyone to coordinate before anything can be released. The architecture promises independence, while the way the organisation works prevents it.

AI can make that mismatch more pronounced. A team can test an improvement quickly, but its ability to put that learning into practice depends on decisions elsewhere. The feedback cycle we wanted to accelerate becomes a series of approval cycles.

Give teams a scope within which they can improve

A use case gives us a practical unit around which to organise ownership, controls and authority.

Consider a bid team using AI to prepare first drafts from approved company material. There is a meaningful difference between improving the structure of those drafts and connecting the tool to confidential client records. There is another difference between producing a draft for review and allowing it to submit proposals.

Governance should make those distinctions clear. The team needs to understand which changes it can assess and make itself, what checks remain mandatory, such as a named person approving every draft before it is sent, and which changes require wider review because they introduce new data, access or consequences.

This gives the team room to improve the capability while preserving control over its scope. Authority sits closer to the work, with an accountable owner and a clear route to the expertise needed when that scope changes.

Microservices practitioners call the deliberate use of this effect the inverse Conway manoeuvre: if the organisation’s structure shapes the system, change the structure to get the system you want. Applied to governance, that means giving each use case named contacts in legal and security who know its boundaries and are involved from the start, rather than a review queue that sees each request for the first time. The MIT CISR research makes the same recommendation: bring risk and governance functions into initiatives at the outset.

The useful lesson from microservices is the relationship between ownership, boundaries and independence. A team can move independently when it understands its responsibilities and the conditions under which its changes affect others. AI governance needs to establish those conditions too.

Govern the capability as it develops

Those boundaries will need to evolve. A tool used occasionally by one person can become part of a daily workflow relied on by an entire department. Its importance can grow even when its technical permissions stay the same. In the bid team example, the person who read every draft line by line in the first month may be skimming by the sixth, because the drafts are usually right. The review step still exists, but it no longer catches what it was designed to catch.

Teams therefore need to review what is happening, alongside assessing individual changes. Are the checks still effective? Has reliance on the output increased? Has the use spread beyond its original scope? These questions have measurable answers: how much reviewers change drafts before they are sent, how many people use the tool each week, and whether it is being used for work it was not approved for.

That learning should also improve the wider framework. Controls that prove useful across several use cases can become shared standards. Problems found in one team can inform decisions elsewhere. Central oversight then has a clearer view of where attention is needed.

At The Curve, this is why we start with the outcome and the work involved. A concrete use case helps us establish appropriate controls, give people a clear scope to act and learn whether the arrangement works in practice.

For senior leaders, the question extends beyond whether an AI initiative can be approved. It includes whether the organisation has given the people responsible a dependable way to improve it. In practice, that comes down to four decisions: which categories of use need central review, and on what criteria; who owns each use case and what they can change without asking; which named specialists in legal, security and technology support each use case; and which changes trigger a fresh review, such as a new class of data, new authority to act, a new group of users or output that reaches customers.

Governance needs to support both: approving the initial use and enabling continued improvement as the capability develops. Otherwise, we accelerate the work of creating something while leaving the work of learning from it dependent on the same coordination that slowed us down before.