A
PERSONAL
NOTE

A personal note

Same Song, Different Players

I have followed Playing for Change for twenty years. If you have not seen it, look it up — musicians around the world, each recording their part separately, layered together into one song. A guitarist in New Orleans, a drummer in Congo, a vocalist in India. They never meet. They never rehearse together. Yet the result is extraordinary.

It works because someone defined the minimal common framework — the song, the tempo, the key. Within that frame, each musician brings everything they have. No one tells the guitarist how to play. The framework is what makes the freedom possible.

That image has shaped how I think about organizations for my entire career. Twenty-five years of building and running operations across companies and continents taught me that the best teams work the same way — a clear shared framework, maximum creative freedom within it, and someone watching the whole to make sure it all fits together.

That someone is the Conductor. Not a manager. Not a controller. The person who hears all the parts and knows whether they are becoming music or noise.

This book is what I have learned about building that framework — updated for a world where the instruments have changed but the need for coherence has not.

It is also a first edition in every sense. I wrote it to start a conversation, not to end one. If you try what is described here — even one cycle, one nest — I want to hear what happened. What worked, what did not, what surprised you. I will read every message, incorporate what I learn, and share updates with all readers. You can find me at ruthamichay.com.

Ruth Amichay
2026

Contents

Personal Note · ii     Prologue · 1

PRO
LOGUE

Prologue

A system designed for its time.

For decades, every new idea required an investment — real people, real budget, real months of work. Before anything could start, someone had to ask whether it was worth the cost. That single question shaped how software companies were built and run.

Time to market was measured in quarters. Time to value took even longer. Each step along the way — architecture, development, testing, sales enablement, customer documentation — had its own team and its own schedule. That pace created natural checkpoints, moments where people could review what was happening, align on direction, and catch problems before they reached customers.

Failure was expensive. A wrong bet meant real money lost and real quarters gone. That consequence kept people disciplined about what they started and how carefully they planned it.

The entire system — the departments, the roles, the sprints, the governance structures — was built around these forces: cost, time, and the weight of failure. They limited what you could do. But they also held everything together.

Then AI arrived

The cost of execution collapsed almost overnight. A feature that used to need a team and a full sprint can now be built by one engineer in a few days. A marketing campaign that took weeks of research, copywriting, and design can be drafted in hours. Pricing analysis that required a dedicated analyst can be generated from live data in minutes. Sales enablement, customer documentation, competitive analysis — every function got faster at the same time.

Most companies responded by adding AI to what they already had — same structure, same roles, same processes, just faster. That delivers real value and it is a reasonable first step.

But the operating model underneath was designed for a world where cost and time kept things in check. Those forces have weakened dramatically. And nothing has taken their place.

Time was your safety net. And it's gone.

The path forward

What This Book Does

To answer that question — to design coherence where there was none — this book follows a clear path.

WHAT
CHANGED

COST
TIME
FAILURE

Constraint 1

Trying Things Was Expensive

Building a feature required a team. A product manager wrote the spec, designers created the interface, engineers built it over several sprints, QA tested it, and DevOps deployed it. That process typically involved five to ten people across four to eight weeks, at a fully-loaded cost that was impossible to ignore.

That cost acted as a natural filter. Before anything started, someone had to make the case that this specific investment was worth making over every other option. The business case, the ROI calculation, the quarterly prioritization — these rituals existed because the price of being wrong was real.

This constraint did something valuable that is easy to overlook: it forced selection. Not everything that seemed like a good idea could actually start. Someone had to choose, and that choice created focus.

Constraint 2

Getting to Market Took Time

From the moment someone decided to build something to the moment a customer could use it, months passed. Architecture had to be designed. Code had to be written and reviewed. Environments had to be set up. Sales needed to learn the positioning. Support needed documentation.

Each of these steps involved different people, and each handoff created a natural pause — a moment where someone could look at what was happening and ask whether it still made sense. These pauses were not designed as governance. They were a side effect of how long things took.

Time also kept the number of things in motion manageable. When each initiative took a quarter, you could only run a handful at once. That limit was frustrating, but it also meant that everyone roughly knew what was happening and could stay aligned.

Constraint 3

Failure Was Painful

When a feature failed, everyone felt it. The team had spent months on it. The budget was gone. The opportunity cost was visible — the things you did not build because you chose this instead. And the board wanted to know why.

That pain made people cautious in a productive way. Teams planned more carefully. Estimates were taken seriously. Commitments were conservative because the cost of missing them was tangible.

This constraint also created a culture of accountability. When something went wrong, people wanted to understand why, because the same mistake would be equally expensive next time. Post-mortems were meaningful because the stakes were real.

Chapter 1

What the Forces Held Together

Taken together, these three forces created an operating model that worked without anyone having to design it deliberately. Cost forced selection. Time created checkpoints. Failure enforced learning.

Every role you have, every process you follow, every meeting on your calendar exists because of these three forces. All of it was shaped by a world where trying things was expensive, slow, and risky.

That is the world you built your company in. And it is the world that is now disappearing.

WHAT
HAPPENS

What happened

Execution Cost Went to Nearly Zero

A feature that used to require a team of five working for six weeks can now be built by one engineer with AI tools in a matter of days. A go-to-market campaign that required a strategist, a copywriter, and a designer working for three weeks can be produced in an afternoon. A pricing model that needed a dedicated analyst can be iterated in real time. Across every function — engineering, marketing, sales, support, operations — the cost of producing work has dropped by an order of magnitude.

This is not a marginal improvement. When the cost of trying something drops by an order of magnitude, the number of things worth trying grows by a similar factor. The filter that cost used to provide has lost most of its power.

What happened

The Boundaries Blurred

When execution was expensive, roles were clear. AI dissolved many of these boundaries. A product manager can now generate a working prototype. An engineer can design, write copy, and deploy in the same afternoon.

The consequences show up in four areas that used to take care of themselves.

These boundaries were not just conventions. They were how your company stayed coherent.

What happened

Management Needs Different Tools

When execution was the bottleneck, managing a software company meant managing execution. Sprint velocity, headcount planning, pipeline reviews — these metrics worked because the limiting factor was how much work people could do.

When execution is no longer the constraint, these metrics — designed for a different bottleneck — need to evolve.

Management was about ensuring work gets done — and it did that well. In the age of AI, execution is no longer the challenge. The focus shifts to ensuring the right work gets done and that it all fits together.

What changed — at a glance

NOT
JUST AI

Chapter 3

A Good Model, Different Economics

The natural first step is to take what you have and add AI to it. Give engineers a coding assistant. Give sales an AI research tool. Give support a chatbot. Same departments, same handoffs, same planning cycles — just faster. Most companies start here, and it delivers real value.

But the system underneath was designed for different economics — and it was designed well. The departments exist because execution was expensive and needed to be specialized. The handoffs exist because work moved sequentially. The planning cycles exist because you could only start a few things per quarter. These were good design decisions for the world they were built in. The economics have changed.

Adding AI to the current model gives you a faster version of a system that was designed for different constraints. To fully capture what AI makes possible, you need a model designed for the economics you actually have now.

That means rethinking the operating model — not the technology, not the people, but the system of decisions and handoffs that connects them. If you were designing a software company today, knowing everything AI makes possible, what would that system look like?

what
now?

THE NEW
MODEL

THE
CYCLE

The cycle

How Work Actually Moves

A software company does three things in a continuous loop. The third step feeds back into the first. Multiple loops run at the same time.

This is not a project management methodology. It is how value moves through a company — from an idea to a customer outcome and back to the next idea. Every software company already follows this flow. The difference is whether it is designed deliberately or left to happen on its own.

In the previous model, these steps ran sequentially — a design that made sense when each step took weeks and needed dedicated attention. In the new model, most of the work runs in parallel and multiple cycles overlap.

Step 1

Select

Every cycle begins with a decision: what should we work on next? The output is a selection record — a single document that answers five questions. AI drafts it from customer data, market signals, and usage patterns. The Visionary reviews, sharpens, and signs off.

Step 2

Build & Prepare

The moment the selection record is signed, all functions begin working from it at the same time. This is the fundamental shift — not because the previous approach was wrong, but because AI now makes parallel execution practical.

These streams are not independent. They feed each other as they progress. The Builder completes a prototype and the Dealmaker adjusts the demo. The Conductor watches convergence across all streams.

Step 3

Operate & Learn

The initiative is live. Customers are using it. The work is no longer about building — it is about watching, measuring, and deciding what comes next.

The Advocate tracks adoption — not just whether customers signed up, but whether they are getting value. Are they using the feature the way it was designed? Are they hitting friction points? Are they asking for things that were explicitly descoped?

The Guardian monitors production — performance, reliability, cost. Is the system behaving as expected under real load? Are there operational patterns that need attention before they become incidents?

The Dealmaker watches the market signal — are deals closing around this capability? Are prospects responding to the new positioning? Is the competitive landscape shifting? Does the pipeline reflect what was predicted in the selection record? The Dealmaker is the bridge between what the company builds and whether it drives revenue.

All of this signal feeds forward. It becomes the raw material for the next selection record. The Visionary reads it and asks: based on what we now know, what should we do next? The cycle continues — not as a restart, but as a continuation of a learning loop.

SIX
PERSONAS

The six personas

What a Company Actually Needs

If you strip a software company down to what it actually needs to do — not the departments, not the job titles — you end up with six functions. Each one is carried by a persona whose judgment AI cannot replace.

What changed

What Each Role Becomes

In the previous model, each function was a department organized around execution tasks — and it delivered well. In the new model, the function still exists but the nature of the work shifts from execution to judgment.

In every case, AI took over the volume. What remains is the judgment: decisions that require context, experience, and the ability to weigh trade-offs that AI cannot see.

Important

Personas Are Not Job Titles

A fair question is whether we are just renaming departments. The difference is what you are hiring for. Previously, you hired a frontend developer to write frontend code — and that made sense when code was the bottleneck. Now, you add a Builder because the architectural decisions have become too complex for one person to carry. AI writes the code in both cases.

And yes, personas overlap. The Visionary will have opinions about the UI. The Builder will have opinions about what to build next. That is expected and healthy. What matters is who owns the decision.

At a glance

The Six Personas — Summary

THE
NEST

The unit

The Minimum Nest

The basic operating unit is a nest — one set of six personas running the cycle together. At minimum, a nest needs one person per persona, though some can be shared early on.

Every organization will find its own weights. What matters is that all six personas exist. Scaling means adding people to a persona or adding nests. Never adding management layers.

The rhythm

Everyone Is Always Working

A nest runs several initiatives at the same time, each at a different stage. This is what keeps every persona busy — not by switching nests, but by working on different initiatives within their own nest.

The Conductor staggers initiatives so no persona is heavy on two at the same time. Too many in the build phase? The next selection waits.

THE
FLOW

Chapter 7

How Work Moves Between Steps

In the previous model, work moved sequentially. Product defined it, engineering built it, QA tested it, marketing positioned it, sales sold it, support handled it. Each handoff was a discrete event. That sequence made sense when each step took weeks.

In the new model, work moves through the three steps — Select, Build & Prepare, Operate & Learn — but the steps overlap. Multiple initiatives are in different steps at the same time. While one initiative is being built, another is being selected, and a third is in operation. The Conductor staggers them so that no persona is overwhelmed.

Within each step, the work is parallel, not sequential. The Builder, Dealmaker, Guardian, and Advocate all start from the same selection record and work simultaneously. They do not wait for each other. They watch each other — through the convergence view — and adjust as they go.

The flow is not linear. It is a set of overlapping loops, each at a different stage, each feeding signal to the others. The Conductor's job is to manage the pace — how many loops can run concurrently without losing coherence.

The overlap

Why Nothing Runs Alone

At any given moment, a healthy company is running three to five initiatives at different stages. One is being selected, another is in build, a third is launching, a fourth is being validated. They share the same people, the same tools, and the same Conductor.

This is not multitasking. It is staggered flow. The Conductor's job is to ensure that no persona is at peak intensity on two initiatives at the same time. When Initiative A passes its launch gate, the Builder's load drops — and that is when Initiative B enters build. The rhythm is deliberate.

In the old model, this happened accidentally — or not at all. Teams were either idle between projects or drowning in too many. The flow was managed by calendar, not by design. In the new model, the Conductor reads the convergence view and stages the next cycle based on actual capacity, not scheduled dates.

THE
GATES

The three gates

What Replaced the Natural Checkpoints

Time used to create natural pauses. The gates replace them deliberately. Nothing passes a gate without meeting the criteria defined in the selection record.

The Conductor operates all three gates. AI checks the criteria. The Conductor makes the call.

Chapter 8 · in practice

What Happens at Each Gate

At the selection gate, the Visionary presents the selection record. Every persona reads it and asks: can I deliver my part? The Builder evaluates technical feasibility. The Dealmaker evaluates whether this maps to real revenue opportunities and current pipeline — if the sales team cannot sell it, it should not be selected. The Advocate evaluates whether customers are ready for this. If any persona raises a fundamental concern, the initiative does not start. This is not a veto — it is a design constraint. The selection record is adjusted until all personas can commit.

At the launch gate, the Conductor checks convergence. Every persona's stream must meet the criteria defined in the selection record. Not "mostly done" — criteria met or not met. If the Dealmaker's positioning is ready but the Advocate's onboarding materials are not, the initiative does not launch. The gate ensures the company launches, not just the product.

At the validation gate, the team reviews real data against the predictions in the selection record. Did customers adopt the way we expected? Did the market respond? Did the operational metrics hold? The decision is explicit: continue investing, maintain as-is, or stop. This is the gate most companies skip — and skipping it is how you end up with dozens of features nobody uses.

COHE
RENCE

The layer

What Keeps It All Aligned

Every persona has powerful AI tools, and each one optimizes for its own domain. But none of them asks whether what was decided matches what was built, what was sold, and what was delivered. That question belongs to the Coherence Layer.

The Conductor builds this layer by connecting the tools that already exist — linking data sources, configuring thresholds, designing the views that make alignment visible. The tools are available. What is rare is the discipline to connect them into a system that keeps the result coherent.

Chapter 9 · what it looks like

Building the Layer

The Coherence Layer is not a product you buy. It is a set of connections you build between the tools you already have — your project management system, your CI/CD pipeline, your CRM, your monitoring stack, your documentation platform. Each tool serves one persona's needs. The Coherence Layer connects them into a single view.

Practically, this means: when the Builder marks a criterion as met in Jira, the Conductor sees it in the convergence dashboard. When the Dealmaker updates positioning in the CRM, the Conductor knows whether it aligns with what the Builder is actually shipping. When the Guardian's monitoring shows a threshold breach, the signal reaches the Conductor before it reaches the customer.

Today, most of this requires manual configuration — APIs, dashboards, alerts. The Conductor builds it iteratively, one connection at a time. Over time, AI will automate more of the signal collection. But the interpretation — whether the streams are truly converging toward a coherent outcome — remains a human judgment.

SCALE

Scaling

Adding Nests, Not Layers

You add a second nest when the product or market domains become different enough that one Visionary can no longer hold the judgment for both. That is the trigger — not headcount, not revenue. It is a judgment capacity question.

If this sounds like the squad model, the resemblance is intentional. Squads solved execution autonomy but struggled with coherence across teams. This model builds the Coherence Layer in from the start.

Not every nest replicates all six personas as dedicated people. The Visionary, Builder, and Advocate are almost always local. The Guardian and Dealmaker may be shared if products run on the same infrastructure or serve the same customers.

ready

GETTING
THERE

THE
PEOPLE

Chapter 11

Nobody Wants to Say It First

Every leadership team thinking about AI has the same unspoken question in the room: what happens to the people? It is the question nobody wants to ask first, because once you say it out loud, you own it.

So let's say it clearly. When AI handles a significant portion of execution, you will need fewer people to produce the same output. That is not a prediction. It is arithmetic. If one engineer with AI produces what three did before, if one marketer generates campaigns that used to require a team, if one analyst covers the territory of three — the math changes across every function.

But the answer is not as simple as the math suggests. You have two genuine options, and most companies will use both.

Neither option is wrong. What is wrong is pretending the question does not exist — or worse, answering it without telling your team.

The honest conversation

What Changes for Each Role

The pattern is consistent across every function: judgment stays, tasks move to AI. The people who thrive are the ones whose work was always more about decisions than deliverables. The ones at risk are those whose value was defined by volume.

The best version of this conversation is the one where you share the model with your team and ask: where does each of us fit? Let them see themselves in the personas. Let them tell you where their judgment matters most. People handle change far better when they are participants, not subjects.

LEGACY

Chapter 12

Your Systems Work. The Frame Is Changing.

Your Jira instance has years of configuration in it. Your CI/CD pipeline is battle-tested. Your CRM has custom fields that encode institutional knowledge nobody remembers creating but everyone depends on. These systems work. They are the result of thousands of small decisions made by smart people solving real problems.

The model in this book does not require you to throw any of that away. What it requires is a different frame around it — different questions asked of the same data, different rhythms applied to the same tools.

There are three patterns for making this transition, and most companies will use all three in different areas.

Chapter 12 · continued

The choice depends on how much of your current system still serves the new model. In most cases, the tooling is fine — Jira, Confluence, your CI pipeline, your CRM. What changes is the layer of meaning on top: what you track, what triggers a review, how you know things are converging.

LEADER
SHIP

Chapter 13

The Org Chart Stays. The Focus Shifts.

You still have a VP Engineering, a CRO, a CMO. The model does not eliminate functional leadership — it changes what functional leadership pays attention to.

In the previous model, each leader managed execution within their function. The VP Engineering tracked velocity and delivery. The CRO tracked pipeline and quota. The CMO tracked campaign performance. These were the right metrics when execution was the constraint.

In the new model, execution is handled. What each leader is responsible for is the judgment quality of their function's personas across all nests. The VP Engineering is not tracking how much code ships — they are ensuring every Builder across every nest is making sound architecture decisions. The CRO is not chasing pipeline volume — they are ensuring every Dealmaker is shaping what gets built toward real revenue opportunities and that promises match delivery.

The leadership team together becomes the company-level Coherence Layer. In a single-nest company, the Conductor handles this. In a multi-nest company, the leadership team watches coherence across nests — portfolio balance, shared infrastructure decisions, resource allocation, and strategic direction.

How each role evolves

How each role evolves · continued

NINETY
DAYS

Chapter 13

Start With What Hurts

You do not need to transform the entire company at once. You need one initiative, one cycle, one nest. Pick the area where the current model hurts the most — where the gap between what AI makes possible and what your operating model allows is widest.

What to expect

The Hardest Part Is the First Week

Writing the first selection record will feel slow. You will sit in a room with people who have launched products dozens of times, and they will struggle to answer five simple questions in writing. That is the point. The clarity was never there — it was hidden behind familiarity and momentum.

By week three, the team will start to feel the difference. Conversations become sharper because everyone read the same document. Disagreements surface early — in the selection room, not at launch. The Conductor will report that they can see things they could not see before.

By week eight, the first cycle will complete. It will not be perfect. Some criteria will have been too vague. Some convergence gaps will have been caught late. The Conductor will have learned which signals matter and which are noise. That is the learning — and it only comes from doing it once.

By day ninety, you will know whether this model works for your company. Not in theory — from experience. And from that experience, you can decide how far to expand.

TWO
RHYTHMS

The current rhythm

A Week Running Operations Today

Consider someone running operations, delivery, or a PMO in a mid-size software company. Three product teams, two active launches, one quarterly review coming up. Here is how a typical week might flow.

This is competent, professional work. It got companies to where they are today. The question is whether this rhythm — built for managing execution — is the right one when AI changes what execution means.

The new rhythm

A Week as the Conductor

Same company, same three product areas. But the operating model has changed. The person is now the Conductor — and the week feels fundamentally different.

The difference is not that one rhythm is good and the other bad. The first manages execution. The second manages coherence. When AI handles more of the execution, the second becomes the higher-leverage use of a leader's time.

THE
RISKS

MARKET
SPEED

Chapter 16

The Absorption Problem

You can now ship ten features a quarter. Your customers are still trying to learn the first three. Your channel partners need time to update their demos. Your support team needs time to internalize what changed. Your documentation needs to catch up. Your customers' internal processes need to adapt.

This is a new kind of constraint — not on your side of the equation, but on the market's side. And no amount of AI can accelerate your customer's willingness to change how they work.

The temptation is to keep shipping because you can. The discipline is to ask: is the market ready for more? This connects directly to the Advocate persona — the person watching adoption, not just delivery. And it connects to the validation gate — where "continue, maintain, or stop" should also consider whether the previous cycle has been absorbed before the next one lands.

Chapter 16 · continued

Designing for absorption means building pauses into a system that no longer has natural ones. It means the Conductor watching not just internal convergence but external readiness. It means the Visionary asking not just "should we build this?" but "is the market ready to receive it?"

This is perhaps the most counterintuitive lesson in the new model. AI removed the old constraints. The most important new constraint is one you have to design yourself: the pace at which your market can absorb change.

DIVER
GENCE

Chapter 17

What Divergence Looks Like at Speed

In the old model, drift happened slowly. A product decision made in Q1 would gradually diverge from the sales narrative over a few quarters. Someone would notice in a QBR. There was time to correct.

When cycles compress from quarters to weeks, the same drift happens in days. What engineering builds on Monday might not match what sales promises on Wednesday. Not because anyone did anything wrong — but because the system does not ensure they are working from the same selection record.

This is the core argument for the Coherence Layer. Without it, speed does not make you faster. It makes you divergent faster.

Chapter 17 · continued

Every one of these is a coherence failure, not a competence failure. Smart people, working hard, producing good work — that does not fit together. The Conductor's job is to prevent this. The gates exist to catch it. The convergence view makes it visible before it reaches the customer.

START
MONDAY

FIRST
NEST

Chapter 18

Three Things Before Monday

You do not need a transformation program. You do not need executive alignment workshops. You do not need to restructure the org chart. You need three things, and you can have them by Friday.

That is it. Three decisions, no new tools, no reorganization. On Monday, start the cycle. The selection record is signed, all personas read it, work begins in parallel, the Conductor watches convergence. You are running the model.

What changes

What You Will Notice in the First Cycle

The first time you run a cycle with the new model, several things will feel different. Not all of them will feel comfortable. That is normal.

The selection conversation will take longer than expected. Writing down the five answers forces a level of clarity that verbal discussions do not. You will discover that the team has different assumptions about what you are building, who it is for, and what success looks like. Surfacing those differences now, rather than at launch, is the entire point.

Parallel work will feel unfamiliar. The Dealmaker starting positioning before the Builder has finished the prototype? The Advocate designing onboarding before the feature is complete? It feels premature. But they are all working from the same selection record. When the Builder's work evolves, the Dealmaker adjusts. This is not waterfall and it is not chaos — it is coordinated parallel work.

What changes · continued

The Conductor will feel uncomfortable. Watching convergence without controlling execution requires a different kind of discipline. The instinct is to jump in and manage. The discipline is to observe, connect, and intervene only when streams are diverging.

The launch gate will feel surprisingly simple. When every persona has been working toward explicit criteria from the start, the launch gate is not a ceremony — it is a confirmation. The work to get there happened along the way.

After the first cycle, you will have enough experience to decide: is this worth expanding? The answer, in almost every case, is yes. Not because the model is perfect, but because the clarity it creates is immediately visible.

MAKING
IT REAL

Chapter 19

Everything Else That Needs to Change

Adopting the model without updating the systems around it creates friction. The model tells you how to work. The rest of your infrastructure needs to support it.

Chapter 19 · continued

NEW
DISCI
PLINE

Chapter 20

For decades, discipline in a software company meant getting things done. The constraint was execution — there was never enough capacity, never enough time, never enough people. Discipline meant squeezing the most out of what you had. Ship faster. Do more with less. Optimize the machine.

That discipline served us well. It built an industry. It created products that changed how the world works. It was the right discipline for the economics of the time.

But it was a discipline of scarcity. And scarcity is no longer the condition we operate in.

When AI makes execution nearly free, the old discipline becomes dangerous. "Do more" is no longer a virtue when you can do everything. "Ship faster" is no longer progress when nobody is asking whether what you shipped should exist. The machine runs beautifully — but nobody is watching where it is going.

Choosing what to start. Choosing what to stop. Choosing what deserves the company's attention and what does not — even when it is easy, even when it is free, even when someone is excited about it. This is harder than the old discipline. Saying no to something cheap is harder than saying no to something expensive. When the cost of trying is near zero, the only thing that prevents clutter is judgment.

The shift

This is ultimately what the model in this book is about. Not the personas, not the gates, not the convergence dashboard. Those are mechanisms. What they serve is a deeper shift in how leaders think about their role.

The old role was to ensure the company produces. The new role is to ensure the company coheres. To hold the question — does this fit together? Does what we build match what we sell? Does what we sell match what customers experience? Does what we invest in produce outcomes that justify the next investment? These questions always mattered. The difference is that the speed at which things can diverge has increased by an order of magnitude.

A company that produces more than it can cohere is not a fast company. It is a confused company moving at high speed. The market will not reward that for long.

The companies that thrive in the age of AI will not be the ones that produce the most. They will be the ones that maintain coherence at speed. The ones where what engineering builds, sales promises, marketing positions, and customers experience all tell the same story — not because someone held a meeting, but because the system was designed to keep it aligned.

The conductor

In a Playing for Change recording, the Conductor does not play louder than anyone else. They listen. They hear each part — the guitar from New Orleans, the drums from Congo, the voice from India — and they know whether the parts are becoming music or noise.

They do not tell the guitarist how to play. They do not replace the drummer. They hold the frame — the song, the tempo, the key — and within that frame, every musician brings everything they have. The result is not compromise. It is something none of them could have made alone.

That is the discipline this book asks of you. Not control in the old sense — not more oversight, more process, more approval layers. Control in the deeper sense — the ability to hold a system together while the people inside it do extraordinary work.

The old discipline was about making the most of what was scarce. The new discipline is about making sense of what is abundant. It requires a different kind of leader — one who measures clarity, not activity. One who values stopping as much as starting. One who understands that in a world where everything is possible, the most important thing a company can do is choose well.

That is the new discipline. And it starts with you.

THE
END

The Operations Guide

The following pages contain templates, tool configurations, gate checklists, a KPI scorecard, and a 30-60-90 implementation plan — everything you need to start your first nest.

This guide is also available as a free download at ruthamichay.com — print it, share it with your team, bring it to your first selection meeting.

1 · Persona mapping

Who Carries Each Persona Today?

For one product area or initiative, map each persona to the person (or people) who carry that judgment today. Some people will appear in multiple columns. Some columns may be empty — that is a finding, not a failure.

1b · Leadership role map

How Each C-Level Role Evolves

The org chart stays. The focus shifts. Use this worksheet to map how each leadership role evolves from managing functional execution to governing judgment quality.

1c · The organizational matrix

Who Sits in the Nest, Who Sits Above

Some roles live inside the nest. Others govern across all nests. This is not a reorg — it is a clarity exercise.

1d · Where the specs went

AI Documents What It Builds

In the old model, specs were written before development started. They were the plan. In the new model, AI writes code so fast that traditional specs become obsolete before they are finished.

The shift: documentation moves from input to output. AI documents every change it makes — what was built, why, what changed from the previous version. This documentation lives in Confluence (or equivalent) and is updated continuously, not once.

What this means for Jira: Jira tracks convergence (persona epics, criteria met, gate status). It does not track implementation detail — that lives in the documentation platform, maintained by AI, versioned automatically. The Builder reviews and approves. The Conductor reads the convergence view, not the code.

2 · The selection record

The Document That Starts Every Cycle

One page. Five questions. Written before any work begins. Shared with every persona. This is the single most important document in the model.

3 · The build record

The Builder's Working Document

Created when the selection gate passes. Linked from the selection record and from the Builder's Jira epic. It evolves during the build — page history tracks every change.

4 · Gate checklists

What to Check at Each Gate

5 · Tool configuration

Configuring Jira for the New Model

You do not need new tools. You need a different structure inside the tools you have.

When multiple people share a persona role — two Builders, three Dealmakers — they all work under the same persona epic. The epic unifies the stream regardless of how many contribute.

5 · The convergence dashboard

What the Conductor Sees Daily

At the capability level, Jira rolls up all persona epics into a single view. This replaces the burndown chart, the status meeting, and the executive report.

Two minutes. No meeting. The Conductor sees: Guardian is at risk, load test infra is the blocker. One conversation. That is convergence management.

5 · Signal types

Automated vs. Human-Declared

The convergence view combines two types of signals. Automate what systems can verify. Trust humans for what requires judgment.

6 · KPI scorecard

What You Measure Changes

If you keep measuring the old things, people will optimize for the old model regardless of what you tell them.

7 · Ritual mapping

Every Meeting Maps to Something — or Goes

8 · The 30-60-90 plan

From Diagnostic to Working Nest