Working Backwards from an organization that works with AI

What this method is for

The usual question is which tasks AI can take over inside the current structure. That question has a ceiling: the structure itself encodes decisions made when coordination and information handling were expensive and human. This method asks the structural question instead, and it uses the same mechanism as a product design.

It is a design exercise, not a forecast. The output is a description of a target organization and a list of what would have to be true, which is something a leadership team can argue with and act on.

The three steps

1. 1
   Describe the organization you would want

   Write the experience of working there: how a piece of work gets started, who or what coordinates it, how information reaches the person who needs it, and where judgment is exercised. Written out, in the present tense, as though it exists.

   The same discipline as a PRFAQ. A description nobody can picture is a description that has not decided anything.

2. 2
   Name the capabilities that description requires

   Work back from the description to what it depends on: how teams form and dissolve, how work is matched to people and to systems, how information is shared across both, and how decisions get made when the analysis and the judgment come from different places.

3. 3
   Design back to where you are now

   For each capability, ask what structure, policy or process would produce it, and what currently prevents it. Performance management, career paths and accountability are usually where the description meets resistance, and that resistance is the real finding.

The shifts a description like this usually implies

• Coordination that sat with a management layer moving into the way work is instrumented, which changes what those roles are for rather than only how many of them there are.
• Teams formed around an objective and dissolved after it, rather than standing structures that outlive their reason.
• Roles defined by capability rather than by task, once the tasks are the part that moves first.
• Governance written for decisions made jointly by a person and a system, including who is accountable when they disagree.

These are consequences of a description, not recommendations. An organization that works through this method and concludes its current structure is right has still learned something, and has learned it in writing.

What to do before redesigning anything

• Build first-hand literacy in what these systems do well and badly. A structure designed on an inaccurate picture of the capability inherits the inaccuracy.
• Pilot the collaboration pattern on real work, small enough to stop: how tasks are split, how handoffs happen, who decides.
• Work out how contribution is measured when a result comes from a person and a system together, because the old measure quietly stops meaning anything.
• Treat it as a change programme, not a tooling decision. People need to understand the capability before they can be asked to work alongside it.

How this is delivered

This runs as a leadership engagement rather than a workshop: sessions with the people who can actually change the structure, and enablement for the functions who will operate it.