Chapter 5: What Done Looks Like

Here’s where Part I left you, and it’s further along than it may feel: you can name the patterns your organization normalized, you know roughly what they cost, and you can tell your appetite from your readiness. So the natural next instinct — I watch it happen in the first ten minutes of every architecture conversation — is to start fixing. The data’s a mess; let’s clean it. The handoffs are killing us; let’s automate them. Somebody pull up the tool we bought.

Hold that instinct for one Part of this book, because it’s the optimization reflex wearing work clothes. Fixing the left side of the diptych, pattern by pattern, makes you better at operating the left side. You already know why that’s not the move — a new approach entirely, not a better version of the current one. The move is different in kind: you design the right side first, and then you build toward it. Architecture before action. This Part is the design.

And design starts with a question I’ve learned to ask before any other, because almost no organization can answer it: what does done look like?

Not “what are we going to do” — every organization has that, usually as a roadmap of activities stretching to the horizon. I mean the other thing, the one that’s strangely missing: a concrete picture of the operating model you intend to run when the work is finished. How customer identity is held. What the frameworks are. Where the intelligence lives. How work moves and where it stops for a human. What your people open in the morning. Ask for the activity list and you get fifty rows in a spreadsheet. Ask what done looks like and you get a pause — because the honest answer, at most organizations, is that nobody has drawn it.

That picture is what this Part produces. It has a name — the Target State Architecture — and a standard: when it’s drawn, anyone in your organization should be able to read it and know which world they’re building toward. By the end of Part II you’ll have its skeleton; the three chapters after this one make the three big design decisions inside it. This chapter gives you the method — and the method is plain enough to state in one breath.

The method in one breath

For each of the five layers you met in Chapter 2: name the current state — what actually holds this layer together today. Name the target state — what should hold it together in the model you intend to run. Name the gap — the specific knowledge that has to move from someone’s head into shared form for the current state to become the target. Then sequence the gaps bottom-up, in dependency order, until the whole journey is visible end to end.

That’s the entire method. Five layers, three questions each, one ordering rule. Everything else in this chapter is the discipline of doing it honestly — because each of the three questions has a cheap answer and a true one, and the cheap answers are the ones that come naturally.

Current state: observable, not editorial

The current-state question is not “do we have a tool at this layer?” You have tools at every layer; everyone does. The question is how much undocumented human knowledge sits between the tool and the work — how many of Chapter 2’s dots and glue lines this layer runs on.

A real current-state answer is a sentence an outside observer could verify. At Layer 1, something like: customer identity lives in the CRM, the accounting system, and three spreadsheets, and the reconciliation rules live in one operations person’s head. At Layer 4: nothing moves to delivery without crossing one manager’s desk, and her prioritization logic has never been written down. At Layer 5: every team works in its own tool, and “where is this customer right now?” has a different answer depending on whom you ask.

Notice what those sentences are not. They’re not editorial — no “our processes are pretty mature,” no “the team is strong,” nothing you’d nod along to in a kickoff meeting. Editorial answers are how the left side of the diptych defends itself: vague enough to be agreeable, agreeable enough to never get fixed. A current-state sentence earns its place by naming what is specifically, observably doing the holding-together work today — and whose head it’s in. If Part I’s assessment was honest, most of these sentences are already half-written: every trap you named in Chapter 3 is a current-state sentence waiting for its layer.

Target state: the slogan test

The target-state question has an even cheaper failure mode, because target states attract aspiration the way whiteboards attract arrows. “A single source of truth empowering data-driven decisions.” “Seamless AI-powered operations.” I’ve read a hundred of these, and they all share one property: nobody could build from them, and nobody could ever be found in violation of them.

So here’s the test I hold every target-state sentence to: if it sounds like a slogan, it’s wrong. A target state is not what you hope the future feels like. It is the actual operating model you will run — specific enough that a new hire could read it and know how the place works. The CRM is canonical for customer identity; the accounting system owns financial reality; the sync between them follows written record-of-truth rules. That’s a target state. Work flows automatically through delivery stages and stops for human judgment at pricing exceptions and scope changes — that’s a target state. The right side of the diptych gives you the structural shape of all five; your job is to make each one specific to your business, your systems, your people. Concrete enough to build. Concrete enough to be wrong about — that’s the point. A design you can’t be wrong about isn’t a design.

The gap: a person, not a process

Now the question that carries the whole method, and the one most organizations have never once asked at this altitude.

The gap between current and target is not a list of tasks, and the discipline here is refusing the three cheap shapes the answer wants to take. The first slip is curriculum: “the team needs to learn the new system.” The second is calendar: “we’ll get to that in phase two.” The third is tooling: “we need to configure the integration.” All three feel like answers. None of them names the thing actually standing between the two states.

What’s standing there — every time, at every layer — is what Part I taught you to see: a specific person’s specific knowledge that exists nowhere outside their head. The gap at Layer 1 is the operations person’s reconciliation rules — applied daily, documented never. The gap at Layer 2 is the founder’s intuition about which opportunities are real — a judgment everyone defers to and no one can reproduce. The gap at Layer 4 is the manager’s triage logic — a thousand one-off decisions that have never become one written policy. Run the method across your five layers and watch what the gap column fills with: names. People. The exact people Chapter 1 taught you to see differently.

This is the moment the HDE thesis stops being a mindset and becomes a design instrument. Tribal knowledge to Human Domain Expertise is not a slogan from Part I — it is, literally, the work plan. Every gap names a specific human’s specific knowledge that must become a specific shared artifact — a written rulebook, a documented model, an encoded policy an agent can follow and a new hire can read. If a gap on your page is generic — “better processes,” “more alignment” — the discipline hasn’t been done yet. Go back and get the name.

And here is the gentlest, most important consequence: the people whose names fill the gap column are not the obstacles to your architecture. They are its authors. The design work ahead of you cannot be done without them — which, if you carried anything out of Chapter 4’s conversation about engaging experts without fear, you’ll recognize as exactly backwards from how this usually goes. Most transformations route around the veterans. This one is made of them.

Sequence: dependency, not appetite

You now have, in principle, five gaps — five movements from current to target. The last question is order, and order is where appetite tries to take the wheel back.

Appetite wants to start where the demo was coolest — usually Layer 4 (automate the work!) or Layer 5 (a beautiful new workspace!). The method says no, and it isn’t being stubborn; it’s reading the dependency arrows you saw in Chapter 2. The layers earn each other from the bottom up, and a target built out of order doesn’t hold:

Layer 1 first. Until customer identity is canonical — one customer, one truth, written reconciliation rules — nothing above it is real. I won’t pretend otherwise: closing the L1 gap is dull, infrastructural, and nobody’s favorite quarter. It is also the single most common thing organizations skip, and the single most common reason everything built on top of the skip fails. Get the data model right at all costs.

Layer 2 second. Once the data is canonical, the meaning frameworks can be built on it — and this is the layer organizations stall on longest, because clean data doesn’t change vocabulary. You can sit on a pristine Layer 1 for a year and still describe your customers in stage gates and scores. The next chapter is about exactly this design decision.

Layer 3 third — the critical waypoint. Only when the meaning layer has shifted can the HDE+AI junction be built honestly. Put agents on top of clean data and industrial frameworks and you get Chapter 2’s warning realized: faster industrial operations, dressed as transformation. The machine learns whatever the layer beneath it says the business means — and if you skip the design and “just point AI at it,” you haven’t avoided architecture; you’ve delegated it to the Training Data Problem. The machine will happily design your operating model for you, from its defaults. You’ve met its defaults.

Layer 4 fourth. Orchestration earns its weight from the junction below it. Automate before the judgment is documented and you’re encoding tribal knowledge into brittle workflows — the system breaks on every edge case, because the edge cases were the part that lived in someone’s head.

Layer 5 last. The interface is the consequence, not the cause. A unified workspace over un-unified layers is a fresh coat of paint on the left side of the diptych.

One honest amendment, so the rule doesn’t become a religion: you can sketch upper layers early — a draft workspace, a provisional automation, a co-designed mock — as long as everyone knows they’re provisional. Sketches are how teams stay motivated through the L1 quarter. The failure isn’t parallel work; it’s pretending the sketch is load-bearing before the layers under it exist.

And note what the sequence is not: a calendar. Two organizations can run the same design and spend wildly different time at each waypoint — gap size sets duration. What never changes is the order. That’s why every milestone in this book is a state, never a date: the layer holds, or it doesn’t. You move when it holds. An architecture paced by the calendar is paced by appetite with a project plan; an architecture paced by dependency is paced by reality. You did not do the Part I work to hand the wheel back now.

One page per layer

Run the method to the end and the deliverable almost writes itself: one page per layer — current state in observable sentences, target state that survives the slogan test, the gap with a name on it — and the sequence binding the five pages into a single arc. That document is the skeleton of your Target State Architecture, and the rest of Part II puts the three big decisions into it.

Because three of those target-state pages contain choices this book hasn’t equipped you to make yet. What should the meaning layer actually say — if not scores and stages, then what? That’s the next chapter, and it has a precise answer. Who owns what in an organization where the doer is abundant — what happens to the org chart you indicted in Chapter 2? That’s the chapter after. And what does all of it run on — the platform question you’ve been patiently not asking since page one? That one gets answered last, on purpose, and then somebody signs the whole drawing.

Not a committee. A person. We’ll get there.