# The first yes is small

> A diagnostic that produces your own number, a proof in one domain, an interim transformation leader, and the platform definition. How Alan Wizemann works...

Updated: 2026-09-06 · Author: Alan Wizemann

I am not going to ask you to reorganize the company. I am going to ask for a few weeks to find out what your own stalled portfolio is worth, and then, if the number deserves it, a quarter or two to prove the model in one domain that the rest of the company can see and build on.

## 1. The diagnostic (Two to four weeks)

Discover the domain architecture your company already has by looking at how work actually moves, audit the stalled and duplicated portfolio, and find the first card – the smoking gun that several stuck projects are all waiting on. Priced like a small project, and the only rung you have to say yes to.

Deliverable: Your own number, from your own portfolio, and the first domain and first card to prove it on.

## 2. The proof (One to two quarters at a small company; longer by size)

One domain organization, one or two small teams owning and exposing the first shared piece of the company, one ownership team taking one card. The smallest version of the governing layer stands up – identity inherited from what you already run, one gate every model call passes through, the board, and spend metering – and the executive team meets as a governance body for the first time. Ownership training for the first owners runs alongside, bootcamp-style, led by people who have done this.

Deliverable: A working example, live and in use – the aim, which the proof either meets or does not, is that other teams have started to build on it – and the governance and change-management structure for what comes next, defined around it.

## 3. Interim transformation leader (Through the change)

The separate, almost consulting-like seat reporting to the chief executive or the executive team as a whole, holding authority over the control plane from the first day. Runs discovery, the choice of the first card and domain, the first team, the training of the first owners, and the sequencing of the domains that follow. The role's measure of success is that the company no longer needs it.

Deliverable: The control plane run through the change, then handed to its permanent owner or kept, as the proof decides.

## 4. Platform definition (Alongside the proof)

The model requires a specific set of capabilities – spend and work tracking per outcome, an org-wide retrieval and memory layer, identity inherited from your existing systems and enforced for agents, observability, the board of work, the catalog, a single governed gateway for every model call. Some exist, some are emerging, and some nobody has built yet. I define which is which for your company, and assemble the partners or the build for each.

Deliverable: The capability map: what exists, what to partner on, what to build, and in what order.

## The projects that don't die

Every transformation I have run has had the same shape financially, and it is not the shape boards expect. There is an upfront cost to build the initial team and set things up. It is real, and it is offset faster than anyone believes, because the first thing a transformation does is stop projects. Some are stopped because the transformation will consume them – the thing they were trying to build is what the new model produces as a matter of course. Others are stopped because they were never really projects; they were products with an end date pretending to be a project, and they will need maintenance forever, so they are either owned properly or ended.

You already know which projects these are, because every executive team does. They are the ones that do not die: the initiative that is on its ninth change request, the program that always needs "others" to finish it, change request that always needs "others" to finish it, the system that has been ninety percent done for two years. They are not failures of the people running them. They are what happens when a project needs a piece of the company nobody owns, which is precisely what the first piece of the proof fixes. Most often that piece is the customer, whose data is scattered across the CRM, order management, support, email and social with no single owner. The customer segmentation effort, the customer cost analysis, the field tool for sales, and one domain over the shipping optimization that supply chain and e-commerce have each tried to build separately – these are the money, and they are already on your books.

## What the diagnostic produces

The diagnostic is short because the method is simple. We look at how projects are created and tracked, which parts of the organization are always involved in every project beyond IT, and what people say always gets in the way. Then we take the existing org chart and draw the lines of that work between the boxes, and where the same lines keep appearing we have found a domain. Alongside that we audit the stalled and duplicated portfolio, and we find the first card – one outcome, big enough to matter to the executive team and small enough for one team to ship, and it is usually a smoking gun, three or four stuck projects all waiting on the same unowned thing. What you get at the end is your own number, from your own portfolio. I will say plainly that it is the only number I would ask you to believe, because I do not put a return figure in a document and I would be suspicious of anyone who did. The full documents behind these pages (the operating model, the platform it runs on, and the complete role map) are read-aheads I send after a first conversation rather than things I publish, and the diagnostic is where they start to be about your company instead of about the model.

## What could stop this

I want to be equally direct about the risks, because they are the reason the ladder is shaped the way it is. Some of the technology does not yet exist in a form a company can buy and install, which is why the diagnostic confirms what is plumbing and what is not before a quarter is spent building it. Some of your leaders do not understand AI, and the model is designed so that they do not need to (a domain leader needs to understand ownership; the transformation leader and a small technical team carry the technical weight). But a leader who will not accept ownership cannot lead a domain, and that is a decision you will have to make. Vendors will tell you their product is the platform, and nothing should be bought that cannot be replaced. And then there is the pattern of expectations, which I have had to say twice at every company. Started correctly and small, this grows organically and cost-effectively, and it keeps growing. Used as a wholesale change too early, it fails fast and costs far too much in dollars and in time. A board that asks for more, sooner, is asking for the failure mode.

## The ask

I am not asking you to reorganize the company. I am asking for four things that let us find out, in a quarter or two, whether you should. First, the approach: agreement that the company will try this model in one domain rather than continuing to adopt AI one department at a time. Second, the patience and the money to get to the proof – a quarter or two, a modest budget, and the discipline not to demand a status deck in week three. Third, a few people, moved under a new leader, to form the first domain organization and the first teams; some of them you will have, and one or two you may need to hire. Fourth, a grounding on what happens after. If the proof works the next step is the next domain, and then the alignment of the org chart around what the company actually does. I would rather you decide now, in principle, that success leads there than discover in six months that a working example is politically inconvenient.

That is the whole request. The room that froze did so because nobody in it had been given those four things. I have come to think that giving them is the most consequential decision a chief executive will make this decade – not because the technology is remarkable, though it is, but because the organization that can use it has to be chosen on purpose.

---
Canonical: https://alanwizemann.com/accelerated-organization/offer