Finance supports the AI initiative because it expects lower operating costs. Marketing sees a faster content engine. Operations expects better forecasts. HR hears a change to roles and skills. Technology is already thinking about data, architecture, access, and all the ways this could go sideways at 2:00 on a Sunday morning.

Everyone says yes.

To five different plans.

The problem usually stays hidden because the word *AI* feels specific enough to move the conversation forward. It sounds like a category. In practice, it can hold several very different capabilities, changes to work, investments, and risks.

That makes agreement surprisingly easy.

It also makes execution surprisingly hard.

Listen for the strategy hiding behind the word

When Finance says AI, the conversation may be about automation and cost. Which repeatable steps could happen with less manual effort? How much time or expense might that remove?

When Marketing says AI, the conversation may be about generation. How could a team produce drafts, concepts, variations, and analysis faster while protecting quality and brand judgment?

When Operations says AI, the conversation may be about prediction. Where could patterns in existing data improve a forecast, surface an exception, or support a decision?

When HR says AI, the conversation may be about work. Which tasks change? Which judgment becomes more important? What will managers need to evaluate that they have never had to evaluate before?

When Technology says AI, the conversation may be about the system underneath all of it. What data does it need? What can it access? How reliably does it perform? Who maintains it when the business changes?

Each interpretation can be reasonable. Each points toward different spending, ownership, measures, and consequences when something fails.

Yet the meeting may record one line in the plan: “Launch the AI initiative.”

That line can survive several rounds of approvals because everyone gets to keep their own version of the future inside it.

Leave a comment

Finance approved a cost case.

Marketing approved a production engine.

Operations approved a decision system.

HR approved a change to work.

Technology approved an architecture problem.

The disagreement may simply have been scheduled for later.

Watch where the hidden meanings reappear

The first clue often shows up in the budget.

One leader expects a software purchase. Another expects a data project. Someone else assumes training is the main expense. The person leading the initiative receives a budget built for one interpretation and a mandate built from several.

Then ownership gets fuzzy. Technology may own the platform, while a functional leader owns the business result. HR may own the role changes, while Legal and Risk set boundaries on use. Those can be sensible divisions of responsibility, but only when the handoffs are visible. A broad instruction to “partner cross-functionally” leaves everyone supportive and nobody clear about the decision they hold.

Success measures drift too.

A generative system might be judged on quality, review time, and rework. A predictive system may need to beat the current forecasting baseline. An automation may need to reduce cycle time without raising exception rates. An agent with permission to act brings questions about escalation, supervision, and the consequence of a wrong action.

One AI metric rarely carries all of that.

Usage may show that people opened a tool. It says little about whether the intended work changed, whether the output was good, or whether the business outcome improved.

This is why some apparent execution problems begin as language problems. The team starts building before it has made its different assumptions visible.

Subscribe now

Give the ambiguity a name

Computer scientist Marvin Minsky used the phrase “suitcase word” for familiar labels that carry a jumble of different meanings. In his writing on consciousness, he argued that one ordinary word can appear to name one thing while packing many different processes inside it.

AI has become exactly this kind of word in leadership conversations. Leaders can use the same label while referring to different technologies, risks, workflows, and desired outcomes.

The metaphor is useful because it turns a vague communication concern into something a team can inspect.

If “AI” is the suitcase, what has each person packed inside?

A perfect definition that settles every technical debate would ask too much of this exercise. The useful move is smaller: make the meaning precise enough for this decision.

That means the next question after “Should we invest in AI?” becomes:

What exact capability are we considering, what work will it change, and what business outcome should that change produce?

The wording creates room for several answers. It also stops those answers from hiding inside one label.

Try this in your next leadership meeting

Choose one active or proposed AI initiative. Give each leader the prompts below and ask them to answer independently before anyone discusses them. Five quiet minutes can be more revealing than another hour of general conversation.

Share

The AI suitcase exercise

1. The business outcome

What should become observably better if this initiative works?

2. The work

Which workflow, task, decision, or customer moment will change?

3. The capability

Are we asking the system to automate steps, predict an outcome, interpret images or video, generate new material, take actions as an agent, or combine several of these?

4. The system action

What will the AI actually produce, recommend, decide, or do?

5. The human contribution

Where will people add context, judgment, approval, correction, or escalation?

6. The consequence of error

What happens when the output is incomplete, wrong, biased, stale, or delivered at the wrong moment?

7. The accountable owner

Who holds the business outcome, distinct from the executive sponsor and the technical owner?

8. The evidence

What would we compare with today’s process to decide whether the change helped?

Once everyone has written an answer, compare the pages. Circle the places where answers differ. Those differences are the meeting.

You may find that the team has one initiative with a few wording gaps. Good. Clarify them and carry on.

You may find that two or three separate initiatives have been packed into one. That gives you a choice: separate them, sequence them, or state which one has priority.

You may also find agreement on the technology and disagreement on the outcome. That deserves attention before a vendor, pilot, or project plan gives the ambiguity a more expensive form.

Leave a comment

Leave the room with a sentence you can test

The exercise can end with one shared sentence:

It may feel almost painfully specific. That is part of its value.

Finance can inspect the outcome and baseline. Technology can test the capability and controls. HR can see the work and human contribution. The functional leader can confirm the operational change. The CEO can see who holds the result.

Now the team has something more useful than agreement on AI. It has an initiative people can explain the same way after they leave the room.

A shared word can start the conversation. A shared definition gives the work somewhere to go.

If your leadership team is stuck inside broad AI conversations and needs a practical way to turn them into decisions about real work, subscribe to the Work Redesigned Lab at lab.workredesigned.co.

Source note

Marvin Minsky, “Suitcase words in Psychology,” a draft chapter from *The Emotion Machine. https://www.mit.edu/~dxh/marvin/web.media.mit.edu/~minsky/eb4.html, July 28, 2005.

You explain the assignment. You reintroduce your role. You paste in the background. You remind it how your manager wants the answer structured and what “good” looks like. When the first response misses something important, you correct it and try again.

Then the AI does something useful.

It summarizes the meeting. Drafts the update. Organizes the research. Gives you a starting point.

That is the behavior of a helpful tool. It waits for a request and works from the context available in that moment.

A Work Partner should carry more of the relationship. It should understand the part of your job it supports, the people who use your work, the standards you apply, the decisions you can make, and what has changed since the last assignment.

Right now, the burden of continuity sits with you.

*Give it the task.*

*Load the background.*

*Correct the assumptions.*

*Do it again next time.*

Most employees are operating a capable tool one request at a time. The partner layer remains to be built.

If this is your workflow, you can still get good output. Reliability remains fragile because the understanding lives with you. The system receives whatever portion you manage to provide in that conversation.

This article is about moving that understanding into a maintained professional context base. That base helps the AI recognize your role, standards, current operating situation, and judgment boundaries before you assign the next responsibility.

Subscribe now

Your AI needs a maintained picture of your work

Context engineering is the ongoing work of selecting, organizing, delivering, and maintaining the information an AI system needs for the task in front of it.

For an employee, that information includes more than company documents. The system also needs a maintained picture of the employee’s role, how the work creates value, which audiences receive it, how judgment is applied, and what is happening right now.

I call that a professional context base.

I am using the phrase as an ordinary description. The useful structure may vary by role. A context base contains the background you repeatedly explain and the operating information your Work Partner repeatedly needs.

Capture the context that changes slowly

Some parts of your work remain useful across many assignments:

• Your role and the contribution you are expected to make

• The responsibilities you carry and the decisions you support

• The people who use your work and what each audience needs

• Your communication preferences and accepted output formats

• Examples of work that met the standard

• The principles you use when evidence is incomplete

• Professional boundaries and information you keep out of the system

• The direction you want your contribution to move

For a Program Manager, for example, this might include a short explanation of her role in program decisions, a stakeholder map, examples of accepted updates, rules for labeling proposals, and a note on how leaders want issues presented.

Much of this can live in a small set of maintained documents. The format matters less than the discipline. Someone can read the material, correct it, identify its owner, and replace it when the work changes.

The personal boundary deserves care. A company AI tool rarely needs your private life story. Professional values, judgment principles, and working preferences may be relevant. Medical information, family details, political views, private aspirations, and other sensitive material deserve a much higher threshold before they enter an employer-managed system.

Useful context earns its place by helping with approved work.

Leave a comment

Capture the context that changes with the week

The second kind of context moves faster:

• Current priorities

• Active projects and milestones

• Recent decisions and open questions

• Commitments, owners, and dates

• Risks and dependencies

• Changes in stakeholders or decision rights

• Temporary constraints

• The next outcome the employee is trying to produce

This is where an AI setup quietly goes stale.

The role description may still be accurate while the program priority changed last Thursday. The accepted update format may still be useful while the decision record contains a new owner. The Work Partner can retrieve an authentic source and still produce the wrong answer for today.

Give changing context an owner and a review rhythm. A current program brief may need a weekly check. A role description may deserve review when the job changes. An example can expire when leadership changes the format.

Put the review date next to the context so its currency stays visible.

Turn conversation into a context asset

Many employees have not written this material down because they learned it through work. They know that the finance leader wants the risk before the recommendation. They know which meeting notes count as decisions. They know that “final” means three different things across three systems.

The knowledge is real. It is also tacit.

A guided AI conversation can help extract it. Ask the system to interview you about one topic at a time. Two or three questions are enough for a pass. Let it reflect what it heard, correct the weak parts, and compile the result in your language.

For example:

Ask me three questions about my role in this program, the decisions I support, and the decisions that stay with other people. Reflect my answers before drafting a one-page role brief. Use my language. Mark anything you inferred so I can correct it.

Then repeat the process for communication standards, current operating context, judgment boundaries, and goals for the responsibility area.

The result should become a maintained source, rather than another useful exchange buried in chat history.

Chat history can help a model recognize patterns. Its contents may also mix old priorities, abandoned ideas, private conversations, and corrections that were not promoted into a current source. A reviewed document gives the employee something concrete to inspect and update.

Share

Select the context for one part of your job

A broad professional context base can support several kinds of work. A specific Work Partner should receive the parts relevant to its assigned responsibilities.

The useful scope is often a coherent responsibility area. Three to five recurring responsibilities can belong together when they use many of the same sources, serve related stakeholders, and contribute to the same outcome.

For the Program Manager, that area could be program coordination:

• Prepare a daily program brief

• Assemble meeting context

• Draft a decision brief

• Prepare meeting follow-up

• Draft the weekly program update

Each responsibility draws from the shared professional context base. Each also needs its own working information.

The daily brief needs current milestones, commitments, and risks. The decision brief needs decision rights, alternatives, evidence, and the question requiring resolution. The weekly update needs the accepted format, current plan, completed work, and leadership audience.

The employee maintains the background once and chooses the relevant parts for the work at hand.

Context gives background; procedures give the Work Partner a job

A professional context base can make an AI response more specific to the employee. Each responsibility requires its own operating details.

Each responsibility still needs:

• A trigger that starts the work

• Approved inputs

• A procedure, including common exceptions

• The expected output and audience

• Examples of acceptable work

• A quality standard

• Permission boundaries

• Stop conditions

• A test case

Imagine the Work Partner preparing the weekly program update. It needs to know that the Program Manager supports the decision and does not make it. It also needs a procedure for comparing the current plan with the prior update, preserving approval status, listing commitments by owner and date, and surfacing conflicts for review.

Personalization shapes how the system interprets the work. Job design tells it how to perform the responsibility.

That is the point where an AI tool begins to resemble a Work Partner.

Subscribe now

Keep company authority separate from technical access

A connected source is technically available. Company policy determines whether the system may use it for this purpose.

The same boundary applies to action. A Work Partner that drafts an email and a Work Partner that sends it carry different exposure.

For each responsibility, record what the Work Partner may research, draft, recommend, prepare for approval, or execute through an approved company process.

People decisions, payments, legal obligations, compliance, security, customer commitments, and external communication deserve a visible human checkpoint unless the organization has approved another control.

“Stop and ask” remains a useful capability. It belongs next to the context because the Work Partner needs to recognize the situations that exceed its role.

Test whether the context actually works

A polished answer cannot tell you whether the context base is dependable.

Test four different things:

1. Access: Was the current source available?

2. Retrieval: Did the system find the relevant information?

3. Application: Did it apply the information according to the procedure and boundaries?

4. Evaluation: Could a person judge the result against a written standard?

Start with work you already understand and are permitted to use. Include a known answer, missing information, conflicting sources, an out-of-scope request, and an awkward exception.

Then test the context itself. Ask the Work Partner to explain your role in the responsibility area. Ask which source has authority. Ask what changed recently. Ask it to show which part of the context shaped a recommendation.

The test may reveal that the document is missing information. It may reveal a retrieval problem. It may reveal that the decision rule remained tacit.

All three are useful findings.

Give your manager a view of the arrangement

The manager needs enough visibility to evaluate the work design while the employee keeps unrelated personal notes outside the view.

A one-page manager view can include:

• The responsibility area the Work Partner supports

• The professional and company context it uses

• Information deliberately excluded

• The outputs it prepares

• The employee’s review responsibility

• Actions requiring approval

• Known limitations and test results

• The owner and review rhythm for changing context

The employee could open the conversation this way:

That gives the manager a specific arrangement to review.

Start with the explanation you are tired of repeating

You can try this with one piece of context today.

Write down the explanation you keep giving your AI. Perhaps it is your role in a decision, the way your manager wants updates, the difference between a proposal and a commitment, or the current priorities shaping your work.

Turn that explanation into a reviewed source. Add its owner and review date. Use it in one recurring responsibility. Test whether the system retrieves and applies it.

Then decide what deserves to become part of the maintained context base.

An AI Work Partner grows from two kinds of clarity: a current picture of the employee’s work and a bounded description of the responsibilities the system supports.

If you keep explaining your role, priorities, and standards every time you open AI, subscribe to my Substack and get the revised My AI Work Partner Builder. It will help you capture your professional context, configure one responsibility area, and show your manager how the arrangement works.

Subscribe now

Then somebody asks what it would take to get there, and the room produces a roadmap, a budget, a vendor shortlist, and a slide with four arrows on it. What the room does not produce is a definition. Nobody can say what would have to be true for the answer to be yes, which means nobody can say what would have to change, which means the budget is being pointed at a word.

(You have sat in this meeting. Possibly this quarter.)

Dabbling is easy to recognize. Everybody in your company could describe it accurately in one sentence. Enabled is a state, and states cannot be funded or verified unless somebody defines the edges. So here are the edges.

Everybody publishes a framework, and that is fine

Before the list, the concession, because you have seen this before.

A named set of conditions is a commodity format. McKinsey publishes six shifts. Accenture publishes five success factors. Reuters publishes five dimensions. KPMG publishes six maturity levels. If you work in a company of any size, at least two of those have crossed your desk in the last eighteen months, probably attached to a proposal. I am not going to stand here and tell you nobody else has a framework. Everybody has a framework.

What is different is the shape.

Every one of those models is a ladder. You are at level two, here is level three, here is what it costs to climb. A ladder is a comfortable instrument because it always returns good news: you are somewhere on it, you can always move up one, and nobody has to say anything failed.

This is not a ladder. It is six conditions that have to hold at the same time, and failing any one of them breaks the system regardless of how mature the company looks everywhere else. A ladder gives you a score. A conditions model gives you a named failed condition with an owner attached, and only one of those can be taken into a leadership meeting on Monday.

The order below is fixed and it is not a ranking. I am going to write one piece about each of them over the next eight weeks, and that order is a reading order rather than a sequence you install in. You do not finish condition one and move to condition two. You find the one that is missing.

The six conditions of an AI-enabled company

1. Owned. Every function has a name attached to the outcome, and each leader knows which part they hold. The question it answers: who holds this outcome?

2. Legible. The work is documented so a person or an agent can execute it without relying on unwritten background knowledge. Can a person or an agent execute the work as documented?

3. Capable. People can build and maintain useful automations. Managers can evaluate the output and the way the work was produced. Can people build and maintain automations, and can managers judge the output?

4. Visible. Every build is registered, costed, assigned an owner, and maintained. Duplication and orphaned workflows can be seen before they become expensive. What is built, what does it cost, and who maintains it?

5. Measured. Capability, behavior, and performance tracked on a rhythm the company can run itself. Is the company getting better, on a rhythm it runs itself?

6. Pulled. People bring their own problems without being asked. Do employees bring the next opportunity forward themselves?

Six conditions, six different questions, and each one is being asked out loud right now by a different person in your building. Your CFO is asking four and five. Your senior technical person is asking two and four. Your People leader is asking one. Your CEO is asking six and does not have the words for it yet.

What dabbling actually is

Dabbling is the inverse of all six, and written out it is unmistakable.

Nobody owns it. The work lives in people’s heads. They can prompt but cannot build. Nothing is registered. Nothing is measured. And everything has to be pushed.

Read that again with your own company in mind and notice that most of it is probably true, and that the company is not doing badly by the standards of the market. Seven percent of companies have fully scaled AI (McKinsey State of AI 2025, n=1,993). Twenty-five percent have moved 40% or more of their pilots into production (Deloitte, n=3,235). Among companies at $100M to $1B in revenue, 14% have a formal AI strategy implemented in operations, against 30% at $1.1B to $5B (Grant Thornton 2026 AI Impact Survey, n=950). The mid-market is not behind because it is careless. It is behind because nobody handed it a method.

I spent this summer talking with People and HR leaders at SaaS companies between 200 and 2,000 employees. Every one of them had bought the capability. Not one could tell me whether it was changing anything. Two of the eight were paying for AI that was switched off, and nobody in either company had noticed.

Here is what I think is actually happening in those rooms:

We bought the licenses over a year ago. I cannot ask what changed without admitting I do not know. If I say we are behind, it becomes my program to fix. If I say we are fine, somebody will eventually ask me to prove it.

Nobody says any of that out loud. So the meeting produces another roadmap.

The one question that tells you where you are

Each of these six conditions is a thing you can walk into a company and ask to see.

Owned is a name. Legible is a document. Capable is a skill. Visible is a registry. Measured is a rhythm. Pulled is an intake path.

Which gives you the question, and you can ask it on Tuesday:

How many of those six could somebody hand you this week?

Not describe. Hand you. A name is a person, not a committee. A document is a file an agent could execute from. A registry is a list with costs and owners against it. A rhythm is a report that got produced last month because it was scheduled, rather than because somebody asked for it. An intake path is a route from “this step eats my Thursday afternoon” to something built, with a maximum elapsed time on it.

If the honest answer is one or two, you are not behind. You are dabbling, which is where almost everyone is, and now at least you know which two.

The reason this test matters more than a maturity score: it cannot be passed by intention. Every company in this category can produce a strategy deck. Very few can produce the registry. The artifact test is what keeps this model from being a mood reading, and it is the test I would apply to any condition anybody proposes adding to the list, including mine.

The honest problem with the sixth one

Now the part that costs me something.

Five of these you can install. Owned, Legible, Capable, Visible, and Measured are all things a competent team can put in place on a schedule, and I will tell you roughly how long each takes.

Pulled is different. Pulled is the one that tells you whether the other five took.

A company can hold all five, with the name and the documents and the registry and the rhythm all in place, and still be pushing every single thing uphill. Every initiative starts in a leadership meeting. Attendance is mandatory. Somebody sends a monthly reminder about the licenses. The program has a champion and no gravity. That company is going to stop the quarter the budget moves, and the five conditions it holds will not save it.

So yes, the sequencing objection is real: Pulled is partly a consequence of the other five and it lags them. That is exactly why it belongs on the list rather than in the appendix. It is the condition that decides whether you bought a project or a change.

The question that gets at it is unkind and worth asking anyway. If you stopped pushing for one quarter, what would keep running?

What to do in the next 30 days

None of this requires calling anybody, including me.

Week one. Run the artifact test on your largest function. Ask for the six things. Give people a week and take whatever arrives. What arrives is your baseline, and it is more accurate than any assessment you could fill in yourself, because it measures what exists rather than what is intended.

Week two. Name the failed condition, singular. Resist the urge to declare all six broken. Pick the one that is blocking the others, attach one person’s name to it, and give that person the authority to set a standard rather than the task of writing a plan.

Week three. Find your shadow AI and read it correctly. Somebody in your company is using a tool you did not buy, for work you did not scope. The category reads that as a governance failure. Read it as demand that found no legitimate path. Those people have already told you where the next build should go, and they told you by going around you.

Week four. Ask your CFO what number would settle it. Not what metrics are available. What number, in the units the business already uses, would make them stop asking. Write it down. Whether you can answer it in twelve months is the entire game, and most companies have never written the question down.

If you got handed AI and you are the one now expected to say whether it is working, this is the place I write about how that actually gets done. One condition a week for the next eight weeks, each one written to the person in your company who cares about it most, and each one built to be forwarded to them. Subscribe at lab.workredesigned.co.

I also built the self-assessment version of the artifact test. Six conditions, a handful of questions each, and it returns a named failed condition with an owner attached rather than a score out of six. To get access, become a paid subscriber to get this and other premium resources.

Works Cited

Accenture. (2023, August 9). The Art of Ai Maturity. https://www.accenture.com/us-en/insights/artificial-intelligence/ai-maturity-and-transformation

AI capability maturity assessment. KPMG. (n.d.). https://kpmg.com/de/en/insights/digital-transformation/artificial-intelligence/ai-capability-maturity-assessment.html

Deloitte. (2026, January 21). From ambition to activation: Organizations stand at the untapped edge of AI’s potential, reveals Deloitte survey [Press release]. PR Newswire. https://www.prnewswire.com/news-releases/from-ambition-to-activation-organizations-stand-at-the-untapped-edge-of-ais-potential-reveals-deloitte-survey-302666072.html

Deloitte AI Institute. (2026). The state of AI in the enterprise (2026 ed.). Deloitte. https://www.deloitte.com/us/en/what-we-do/capabilities/applied-artificial-intelligence/content/state-of-ai-in-the-enterprise.html

Grant Thornton Advisors LLC. (2026). 2026 AI impact survey report. https://www.grantthornton.com/services/advisory-services/artificial-intelligence/2026-ai-impact-survey

Jadematusick. (2026, August 4). The five dimensions of AI impact: A reality check for law firms of all sizes AI’s impact on law firms and its 5 dimensions. Thomson Reuters Law Blog. https://legal.thomsonreuters.com/blog/the-five-dimensions-of-ai-impact-a-reality-check-for-law-firms-of-all-sizes/

McKinsey & Company. (2025, December 10). AI at work but not at scale. https://www.mckinsey.com/featured-insights/week-in-charts/ai-at-work-but-not-at-scale

Singla, A., Sukharevsky, A., Hall, B., Yee, L., & Chui, M. (2025, November 5). The state of AI in 2025: Agents, innovation, and transformation. McKinsey & Company. https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai

Six shifts to build the agentic organization of the future | McKinsey & Company. (n.d.). https://www.mckinsey.com/capabilities/people-and-organizational-performance/our-insights/the-organization-blog/six-shifts-to-build-the-agentic-organization-of-the-future

Somebody in your company has already typed “AI-enabled” into a slide. It sailed through the review. Nobody stopped to ask what it meant, and here’s why that happened: everyone in the room had a private definition, and every single one of them was reasonable.

• Your CTO heard infrastructure and access.

• Your CFO heard a line item that has finally started giving something back.

• You heard people using it well, safely, without you having to chase anyone about it.

Three people, three different sentences, one nod.

I find that genuinely fascinating. That phrase is the only claim in the whole deck that can’t be checked. You can’t verify it, so you can’t be wrong about it, so it can’t be funded and it can’t fail. It just sits there being pleasant.

(You’ve sat in that meeting. Possibly this quarter.)

So let’s talk about what it’s standing in for, because the thing underneath it is usually not a mistake at all.

Can we give the AI Pilots their due for a second?

The dabbling stage was the right call.

Think about where you were in 2024. Nobody could have told you which workflow to aim this at, because the technology was moving faster than anyone could point it anywhere. Letting people try things was the only sane response available, and it did work that a plan could never have done.

It found your willing people. The four or five in the building who’ll pick up something new without being asked twice. You know exactly who they are. It found the live use cases, the ones people actually cared about instead of the ones a consultant would have nominated in a workshop. And it surfaced your objectors early, which sounds like a problem and is really a gift, because most of those objections were correct.

If you ran that stage, you did a good thing, and being wrong about any of it cost you almost nothing.

Which is the part that changed.

Experiments were cheap in 2024 because nothing was sitting on top of them. Two years in, that arithmetic flips. Every quarter you spend in the experimental stage adds automations nobody wrote down, licenses nobody costed, and builds that were good enough for one team quietly getting copied into three more. Those get harder to unwind every month they run, because the next thing gets built on top of them.

There’s a point where pulling an automation out is riskier than leaving it in. After that point you’re paying to maintain something you can no longer change.

Waiting doesn’t hold the problem still. It makes the problem more expensive.

Why the question resists an honest answer

Here’s what I keep noticing about “are we AI-enabled.”

Nearly every published model in this category is built as a ladder. Levels, stages, tiers, dimensions. The big firms all have one, and so do most of the platforms. If you’ve taken three vendor calls this year you’ve met at least two, and they’re serious work by serious people. I’d be insulting you to pretend otherwise.

But a ladder answers “how far along are we,” and that question comes with a built-in escape hatch. You’re at level three. Level three feels like progress. Level three gets filed. Nothing about Monday changes.

Two numbers get my attention here. McKinsey’s Global Survey on the state of AI, 1,993 participants across 105 nations, fielded June through July 2025, found 7% of respondents saying AI had been fully scaled across their organization. Meanwhile RSM’s cybersecurity special report, 501 middle market executives, fielded in January 2026, found 44% with defined roles and responsibilities for AI decision-making, and 35% with a formal AI governance framework.

So a lot of companies have named somebody. Very few have scaled anything. That gap is basically the whole subject.

Share

And here’s where I’d push back on my own framing

I used to talk about this as a finish line. Get one function done, then the next one. There’s something useful in that, and I’d like to correct the part that’s misleading.

AI enablement doesn’t finish. There isn’t a state where you’ve arrived and can stop paying attention. Anyone who sells you that is selling you a project when what you have is a way of operating.

What you’d actually want, if I’m being precise about it, is something that expands on its own. Where the second function starts from what function one learned rather than from zero. Where somebody in finance builds a thing and it lands in the same registry as everyone else’s, because that’s just how it’s done here. Where new people arrive and absorb the standard without you running a session about it. Where the thing keeps growing and keeps holding without needing to be rebuilt every time a tool releases a new version.

Self-sustaining is closer to it than finished. The question I’d ask isn’t which function you completed. It’s more like: **which function keeps going without you pushing it?**

The part that surprises people

Most of what makes that possible has very little to do with the technology.

I’d put it at a strong majority, and the majority is culture, people, the context your AI tools are working from, and the processes underneath both. The tools are the easiest part and the smallest part.

Culture, meaning whether somebody can say “I tried this and it was wrong” in a room without it becoming a thing. Whether a manager can admit they can’t evaluate what just crossed their desk. Whether a person who builds something useful gets asked to share it or gets quietly resented for it.

People, meaning the four or five who’ll actually carry this, and whether they’re supported or just tolerated. And the managers in the middle, who are the layer every AI program skipped and the layer that decides whether any of it lands.

Context, meaning what your AI systems know about your company before they do anything. Which brings me to the condition that has changed shape since I first wrote it down.

Subscribe now

Legible goes much further up than people expect

Most people hear Legible and think process documentation. SOPs, the real sequence including the workaround and the shadow spreadsheet everyone pretends isn’t load-bearing, the failure path written next to the happy path.

All true, and it’s the smaller half.

The bigger half sits upstream of any process. It’s whether your company’s own foundation exists somewhere readable. What the company is for. Who it serves and who it deliberately doesn’t. What it will and won’t do. How it sounds. What it’s trying to have become true in eighteen months. Held in one place, kept current, and actually checked against rather than written once and admired.

Here’s why I’d put that inside a condition instead of leaving it in a values workshop.

The moment AI goes into real work, you’ve handed judgment to something that can’t read the room. Every output it produces gets evaluated against a standard. If that standard was never written down, it lives in the head of whoever happens to be reviewing that day. It differs between reviewers. It drifts. And nobody can point at the drift, because there was never anything to point at.

A company with an undocumented foundation doesn’t have a governance problem yet. It has one waiting, and it tends to show up on the day AI-assisted output exceeds what one careful person can read.

The test for it is unglamorous. Could somebody outside your team tell what your company is for, who it serves, and what it refuses to do, from a document, without asking a human? If that’s a no, then Legible is already struggling at the top before it gets anywhere near your processes.

Share

Something to try, if you feel like it

This isn’t homework and I’m not going to tell you how to run your company. But if you wanted a version of the question you could actually answer, here’s the one I’d reach for.

Pick one function. The company as a whole is too big to answer for honestly, so take the single place where the most is already happening.

Then sit with the person who’d have to live with the answers and go through six of these out loud. All six want to be true at the same time, and to keep being true, which is the part that makes it a way of operating rather than a milestone.

1. Is there one name attached to the outcome here, with the method and the budget to act on it?

2. Could an agent run the core process from what’s written down today, and could a stranger tell what this company is for from a document?

3. Do these people build and maintain their own automations against a shared standard, and can their managers judge the output?

4. Could you produce a list of every build running in this organization, with a cost and a maintenance owner against each one?

5. Is there a baseline from before any of this started, and is something measured against it on a schedule?

6. Are people here bringing you problems to solve without being asked?

Six yeses and that function is running itself, and the next one gets cheaper because of what this one learned.

Anything short of six gives you a named condition that isn’t holding, which is a smaller and much more workable thing than a level on a ladder.

And it gives you something to put in the next board update that could turn out to be wrong. Which, for my money, is the only kind of claim worth making.

---

So. Which of the six would your company struggle with? Reply and tell me the one that made you wince.

References

McKinsey & Company. (2025). *AI at work but not at scale*. https://www.mckinsey.com/featured-insights/week-in-charts/ai-at-work-but-not-at-scale

McKinsey & Company. (2025). *The state of AI: Global survey*. https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai

RSM US LLP. (2026). *RSM’s cybersecurity special report finds middle market racing into AI faster than it can secure it*. https://rsmus.com/newsroom/2026/rsm-cybersecurity-special-report.html

“And how do we build this in house? We use the context created using thousands of examples from employees. These are the employees’ words that we are just copying.”

Pause.

“Should we be paying those employees more? Should we not be? Is it like a shift differential when you’re...”

And then he trailed off, because there is no end to that sentence. Nobody has written one.

He was not reciting a hot take he read on LinkedIn. He is a working people leader at a company with about a thousand US employees and a call center in Texas, and the question arrived in his own head, mid-sentence, while he was describing something else entirely. Which is how you know it is real.

Share

The moment the question showed up

Here is the setup, and you already know it because you are living inside some version of it.

Health insurers already auto-adjudicate somewhere around 80 to 85% of claims. IDC projects straight-through processing north of 65% across auto, home, and commercial auto by 2026. Lemonade says nearly half its claims resolve without a human touching them. Sixty-five percent of insurers are scaling AI agents in claims this year.

None of that fell out of the sky. Somebody built it. And they built it out of the actual working knowledge of actual claims people: their scripts, their call recordings, their macros, their judgment about which weird edge case is fraud and which one is just a guy whose flight got canceled in Lisbon.

Those people sat in the process interviews. They explained the thing they are good at. They corrected the outputs when the model got it wrong the first eleven times. They flagged the exceptions.

Then the project shipped, and somebody sent an email thanking the working group for their partnership on this important initiative.

That is the whole story. That is the question.

Four questions wearing one coat

Most people who bump into this collapse it into one blurry grievance about AI and fairness. It is actually four questions, and they have completely different answers.

One: contribution. My work product became training data. Do I get anything for that?

Two: extraction. I sat for the interviews, wrote the scripts, corrected the outputs, flagged the edge cases. That was labor, stacked on top of my actual job. Was I paid for that?

Three: supervision. I now oversee three agents doing what I used to do myself. Bigger job or smaller job? Every comp system ever built says supervising humans is a bigger job. Nobody has decided what supervising agents is.

Four: leverage. My output is five times what it was. My pay is exactly what it was. Somebody captured that difference and it was not me.

Question three is the one your HR team could actually fix this quarter. Questions one and two are the ones that eventually end up in front of a judge. Question four is the one you feel in your body long before you can put words to it.

Subscribe now

Hollywood struck over this and still lost

I want to be honest with you about how this goes, because hopeful is not the same as useful.

In 2023, the WGA and SAG-AFTRA shut down an entire industry for months, substantially over AI. These are not disorganized people. They are among the most leveraged, most media-savvy, most publicly sympathetic labor groups in the country, and they had the whole world watching.

They won real things. Consent and negotiated compensation for digital replicas. Protections around synthetic performers. Genuine wins.

They won nothing for training data.

The WGA agreement requires studios to disclose if writers’ material was used to train a model. It requires no payment for it. Both guilds “reserved the right” to argue later that training on covered work is prohibited, which is the contract-language version of putting something in a drawer and closing the drawer.

So if you are a claims adjuster in Dalas with no union, no strike fund, and no press coverage, I want to be very clear about your leverage here.

You have none.

Which is not the end of the piece. It is the beginning of the interesting part.

The same work pays $350 an hour outside the building

Here is the thing that made me put my coffee down.

The market has already priced this work. It priced it a while ago. It just refuses to price it inside your building.

Mercor, which recruits people to train AI models, pays an average of about $105 an hour. Specialists go much higher. A psychiatrist designing clinical scenarios and evaluating model outputs against evidence-based standards can pull up to $350 an hour. Mercor’s CEO says training agents “is going to become the largest job category in the world.”

Now hold those two facts next to each other.

A doctor who trains a model as a contractor: $350 an hour.

A claims adjuster who trains a model as an employee: her salary. On a Tuesday. As part of a process improvement initiative. With a catered lunch, if it is a good company.

Same work. Same output. Same asset created at the end of it.

The only variable is which side of the employment relationship you happened to be standing on when they asked you to explain your job.

Leave a comment

Nobody is legally wrong here, which is the problem

I know what you want me to say next. I am not going to say it.

Employees have no claim. Work produced in the scope of employment belongs to the employer. Your scripts, your recordings, your annotations, your beautifully weird workaround for the state of Massachusetts: company property. Training a model on company property is a company using its own property. There is no legal theory where you are owed a check.

That is settled, and pretending otherwise helps no one.

The closest historical rhyme is the offshoring wave, and it went badly. In 2015 Disney laid off between 200 and 300 IT workers and made training their H-1B replacements a condition of receiving severance and bonus. Train the person taking your job or forfeit the money. Workers sued under RICO. The court found the allegations insufficient. The practice was upheld as lawful.

Perfectly legal. Also one of the most self-inflicted employer-brand wounds of the decade, a story that is still being told eleven years later, in this very newsletter, as a cautionary tale.

Legality was never the constraint that mattered.

The span of control nobody counted

Let me hand you the version of this that gets a comp committee’s attention, because “it feels unfair” does not.

Every compensation structure on earth pays a premium for supervising people. Supervisors earn roughly 13% more than team leads. Second-level supervisors run about 59% above supervisors. Third-level managers, about 73% above that. Managers and senior managers currently average 4.9 direct reports.

We built an entire philosophy of pay around span of control. Decades of it. Job architectures, banding, leveling frameworks, the whole apparatus.

Then we invented a brand new kind of span, handed it to people without asking, and decided it was free.

Because supervising agents is not nothing. You decide what they work on. You check the output. You own the errors. You are the one who gets asked why when something goes sideways at 4:45 on a Friday. That is a load. It is just a load with no band, no title, no line in the job architecture, and no number anywhere.

*I trained it on my own calls.*

*It does the part of my job I was actually known for.*

*Now I check its work.*

*My title didn’t change. Neither did my number.*

*And I’m the one who looks bad when it’s wrong.*

(If that landed, you already know the sound of it.)

Share

Some companies have figured out the mechanism

Here is the part where I stop being grim.

Nobody is solving the training-data contribution question directly yet. But several companies have built machinery that could, which means this is a design problem, not a physics problem.

Brex has paid out more than 225 spot bonuses for AI-driven projects, ranging from $150 for small improvements up to several thousand for the big ones. One of the largest went to a team that took onboarding from a multi-day, four-person slog down to under five minutes.

Omnisend gives standout AI users a 2 to 4% raise, judged on three things: time and cost saved, actual outcome impact, and how widely the workflow they built got adopted by everyone else. That third criterion is the sharp one. It pays you for contributing to the system, not just for personally being fast.

A regional bank ran straight gainsharing. An analyst automated a quarterly variance analysis from 20 hours down to four. The bank handed back 25% of the savings as a $1,125 bonus and reinvested the rest in training.

Shoosmiths, a UK law firm, put up a £1 million bonus pool tied to hitting a million Copilot uses across 1,300 staff, roughly £770 a head.

Notice the quality gap, because it is instructive. Shoosmiths is paying for activity. Activity metrics produce activity theater, and somewhere in that firm there is a paralegal asking Copilot to rhyme things. The bank and Omnisend are paying for realized value and for contribution to the system. Only those two are aimed at the thing that actually matters.

What to do with this if you are the person it happened to

You cannot invoice anyone. Let’s start there.

But you can stop treating the capture step as an administrative chore that got scheduled over your lunch. That process interview is the most valuable hour you will spend this year, for somebody. Go in knowing that. Ask what happens to the output. Ask what the agent gets deployed to do. Ask whether contribution to it shows up anywhere in the review.

You will probably be told nobody has thought about that yet. That is a real answer, and it is more useful than a fake one.

And if you are running the rollout instead of being run over by it: understand that the quality of your agents is capped by how honestly your best people describe their work. Not by your model. Not by your vendor. By whether the person who is genuinely great at the job decides to tell you the whole truth about how she does it, or the tidy version that leaves out the three judgment calls that make her irreplaceable.

She is doing that math. She is doing it right now, in the meeting you scheduled for Thursday.

Decide the compensation question before the capture step, or negotiate it afterward with people who already know what you took.

---

If you got handed an AI rollout, or you got handed a seat in the room where your job gets turned into a workflow diagram, this newsletter is about making that go better than it usually does. No hype, no doom, just what actually works when real people meet real tools. Subscribe at lab.workredesigned.co.

“I’m your four-day guy,” he said. “Retiring in four days.”

He had been there thirty-five years. He knew which customers actually meant it when they threatened to switch suppliers, which vendors would bend on price if you asked the right way, which piece of equipment always broke in August. None of it was written down. In four days, all of it would walk out the door with him, and the company would find out what it didn’t know exactly when it needed to know it.

Nobody in that story got replaced by AI. That’s the part worth sitting with.

The question everyone’s asking is the wrong one

Almost every conversation about AI and work starts from the same fear: is this going to replace me? It’s a reasonable question. It’s also the wrong one to spend your energy on, because it’s mostly out of your hands. The technology is going to do what it does regardless of how you feel about it.

The question that’s actually yours to answer is smaller and much more useful: now that some of the busywork can be handed off, what am I going to do with what’s left over?

Subscribe now

That’s the whole game. Two people can have access to the exact same tool. One uses it to do the same replaceable work slightly faster. The other uses the freed-up hours to do something a machine genuinely can’t: read a room, catch the account that’s about to churn, write down what the retiring guy knows before he’s gone. Same tool. Very different five years from now.

What actually walks out the door when nobody’s watching

The four-day guy is not a rare case. Every organization has a version of him: the person who has absorbed twenty or thirty years of undocumented judgment and is on a countdown clock everyone can see coming, and mostly ignores.

This is where the AI conversation gets interesting, because the tool that could have helped here has almost nothing to do with replacing the four-day guy. It has to do with capturing what he knows before it’s too late to ask.

The customer experience leader I mentioned has a call and email platform sitting right now with an AI notetaking feature that’s never been switched on. Not because leadership doesn’t see the point. It’s because a half-broken rollout of a feature meant to build trust with customers is worse than no rollout at all, and she’d rather wait and do it right than launch something that embarrasses the team in front of the people they’re trying to serve.

That instinct is correct. It’s also exactly backward from where most of the fear in this conversation gets pointed. The risk was never “the machine takes my job.” The risk is “the knowledge that only exists in one person’s head disappears because nobody thought to point a tool at saving it while there was still time.”

The tech industry isn’t as far ahead as you think

There’s a specific kind of anxiety that shows up in legacy industries: the sense that companies like this one are hopelessly behind, while somewhere out there, sleek AI-native companies have it all figured out.

Here’s a story that should put that fear to bed. At a panel a few weeks ago, a moderator asked someone from a well-known tech company how her organization was actually using AI day to day. Her answer: she’d left herself a Slack message to reminder her about a task she needed to do the next day.

That’s not even using AI. That’s a to-do list with a basic automation and possibly better branding.

The person telling me this story took it as reassurance, and she was right to. If people working inside companies built on this technology are giving answers like that, then the gap between “behind” and “ahead” is much smaller and much fuzzier than it looks from the outside. Almost everyone is improvising. The organizations that end up ahead won’t be the ones who started with more certainty. They’ll be the ones who used the uncertainty to ask a better question earlier than everyone else did.

The only plan that survives contact with the pace of change

Ask most leaders for their five-year AI roadmap right now and you’ll get a shrug or a slide deck that’s already stale. The honest ones have stopped pretending otherwise. “I don’t think we can have a five-year plan,” the customer experience leader told me. “It’s: what are we doing this year, and what do we learn from it, and then we plan the next year.”

Given how fast the tools underneath everyone are shifting, a plan that only reaches twelve months out and gets rebuilt on purpose might be the only honest planning horizon available right now. It also happens to be the posture that keeps the real question in view: not “did we deploy the tool,” but “what did we free up, and did we spend it on something that mattered.”

Impact, not replacement, is the actual scoreboard

Nobody in this story is losing their job to a machine. The customer service reps aren’t being replaced, they’re being pulled off order entry, which nobody, not the customers and not the reps, ever found meaningful in the first place, and pointed toward the harder, better work of actually helping someone who doesn’t know what they need yet. The four-day guy isn’t being replaced either. He’s leaving on schedule, the way people do. The only question is whether anyone captured what he knew before he walked out.

That’s the reframe worth taking from all of this. AI was never going to be the thing that decided whether you stayed relevant. What you chose to do with the time and trust it freed up was always going to be the thing that decided that. Most people are still asking the wrong question. The ones who switch to the right one now get a real head start on everyone who’s still waiting to feel less scared before they move.

If you’re trying to figure out where the real impact is hiding in your own team’s busywork, that’s what the newsletter is for: subscribe at lab.workredesigned.co

An AI program lead walks into a quarterly business review with a slide deck. The deck is full of good news. Adoption is up. Training completion rates are strong. The vendor dashboard shows daily active users climbing week over week. There is a bar chart. The bar chart goes up.

The CFO looks at it for about 45 seconds and asks: “What did this change about how we work?”

Silence.

Then: “What did we actually get for the $800,000?”

More silence.

The program lead has dozens of data points. None of them answer that question.

This is not a rare situation. It is the situation. The 88%/5% gap that researchers keep documenting — 88% of organizations reporting AI use in at least one function, 5% of pilots materially accelerating revenue — is not a technology failure. It is a measurement failure dressed up as a deployment success.

The bar chart goes up. The P&L doesn’t move. And nobody in the room can explain why, because nobody built the measurement architecture to answer the question.

This is the guide for fixing that. Practically. Before your next board review.

The question the board is actually asking

When a board or executive team reviews an AI investment, they are not asking whether employees like the tool. They are asking two things:

• Did the unit economics change?

• Can you prove it?

Unit economics means: what does it cost to produce a unit of work, and did AI make that number go down? That might be cost per support ticket resolved, cost per proposal generated, cost per code review completed, cost per hour of analysis delivered. The specific unit depends on the function. The question is always the same.

“Can you prove it” is where most programs fall apart. Because proving it requires something most organizations skip: a documented baseline captured before the rollout, a pre-defined methodology for comparing against it, and a formula that finance can audit line by line.

Without the baseline, you have a story. Finance does not fund stories.

What makes a number defensible?

A defensible metric has three properties. This sounds obvious until you try to build one.

It is pre-defined. The metric was agreed on before anyone could see the results. This is the single most important property. When you define success metrics after you can already see how the rollout went, both sides have an incentive to interpret “success” favorably. The fix is structural: define the metrics before the work starts, in writing, with both sides clear on what the formula is and what the baseline is.

It is formula-based. The same calculation applied consistently across the measurement period. “We felt like people were saving time” is not a formula. “Time per eligible task type measured via system logs, averaged across the team, compared to the pre-rollout baseline of the same task type” is a formula.

It is traceable. You can show where the number came from, one step at a time. If someone asks “how did you get to $336,000 in reclaimed labor value,” you can walk them through the exact calculation: here is the task count, here is the time-per-task delta, here is the loaded hourly rate, here is the formula. Each line traces to a source.

A number without all three is an estimate. Estimates are fine for internal planning. They are not sufficient for a board review.

The four metrics that hold up in a business review

Different organizations use different terminology, but the metrics that reliably survive finance scrutiny fall into four categories.

Time reclaimed per employee. Not hours logged in the AI tool. Hours of productive work completed faster than the pre-rollout baseline, for the same output. The evidence benchmarks here are well-established: median recovery of about 6.4 hours per week per seat when AI is genuinely embedded in workflows, with customer service roles recovering 8-9 hours, developers 6-8 hours, and knowledge workers broadly around 5-6 hours. Senior leaders typically see the smallest raw time savings (2-3 hours per week) but the highest dollar value per hour.

A critical adjustment to make before presenting this number: subtract the rework factor. Research shows roughly 37% of time saved by AI is spent correcting or validating AI outputs. Net hours reclaimed is the number that survives scrutiny, not gross hours saved.

Cost per hour reclaimed. This is where you translate time into money in a way finance accepts. The formula: take the employee’s base salary, multiply by 1.4 to get the fully-loaded rate (taxes, benefits, overhead), divide by 2,080 productive hours per year. That’s the loaded hourly cost. Multiply by net hours reclaimed. That’s the dollar value of what you recovered.

For a team of 100 knowledge workers at an average loaded hourly cost of $80, recovering 3 net hours per week per person produces $1.25 million in recovered labor value annually. Set that against your license and implementation costs and you have a number the CFO can work with.

Adoption rate trajectory. Not a snapshot number — a trend. The benchmark that holds up in business reviews: above 60% monthly active use at 90 days is healthy; below 40% at the same point signals structural problems that training alone will not fix. The trajectory matters as much as the current figure, because boards want to know whether this is still moving or has plateaued.

Note: “active use” means something specific here. It does not mean logging in. It means the tool was used in completing an eligible work task during the period. Defining “eligible work task” is the measurement decision that makes this metric defensible or not.

Before-and-after productivity comparison. The most compelling presentation and the hardest to do rigorously. This requires: a documented baseline from before the rollout (captured during the diagnostic phase, not reconstructed afterward), a consistent unit of output to compare (tickets resolved, drafts produced, reports completed, analysis cycles run), and a measurement design that accounts for what else changed in the same period.

Rigorous before-and-after comparisons use either a control group (some teams without AI access, some with, compared over the same period) or staggered deployment (teams brought on in waves, with earlier waves compared against later waves during the transition). Both are more credible than a simple “this is how long it took before, this is how long it takes now” with no controls.

The 90-day window and why it matters

Boards and CFOs reviewing AI investments want to see results organized across three time horizons, because the metrics that are meaningful differ depending on when you’re measuring.

In the first 30 days, the relevant data is engagement: who is using the tool, how often, and for what task types. This tells you whether the rollout is reaching the right people. It does not tell you whether it’s working.

At 60-90 days, performance metrics become measurable: time-per-task, output quality, reduction in revision cycles. This is where a rigorous before-and-after comparison starts to be meaningful, because you have enough data to separate novelty behavior from actual workflow change.

At 90-180 days, business impact metrics start to appear: changes to cost-per-output, cycle time reduction, and in some cases revenue or margin effects. These are the metrics that belong in a board deck. Presenting them at week four is guessing with a chart behind it.

The 90-day mark is also a useful diagnostic. If adoption is still below 40% at that point, something structural is broken. The question is which variable: workflow redesign (the tool isn’t embedded in how work actually happens), manager behavior (leaders aren’t modeling or reinforcing the new approach), or cue installation (the signal to use the tool at the right moment isn’t present). Each has a different fix.

The board-ready one-pager

One page. This is not a stylistic choice. Boards have more information competing for their attention than they can process. A concise summary that leads with the conclusion forces clarity that sprawling appendices hide.

The structure that works, in order:

The result. One sentence. The headline number with a dollar sign or a percentage or both. “AI reclaimed 4,200 productive hours in Q1 at a net value of $336,000 against $180,000 in license and implementation costs.”

The context. Two to three sentences. What was the rollout, which team or function, over what period.

The methodology. Three to five sentences. How you measured, what your baseline was, what the formula is, what counts as an eligible event. This is what makes the result defensible rather than claimed.

The comparison. The before-and-after. Specific numbers, same unit of measure, same time window.

The next step. One sentence. What you’re recommending or requesting based on the result.

Everything on the page serves one of those five sections. If a data point doesn’t serve any of them, it belongs in an appendix you didn’t print.

The reason most rollouts can’t generate this

Most AI rollouts are not designed with measurement in mind from the start. The diagnostic work that would capture baselines doesn’t happen. The pre-defined measurement protocol doesn’t exist. The eligible work events are never defined.

So at the 90-day mark, or the board review, or the budget renewal conversation, the program team is left with log-in counts and training completion rates and a vendor dashboard that shows very exciting graph shapes. None of which answer the question the CFO is actually asking.

Building the metrics that hold up requires a specific sequence: baseline first, redesign second, measure third. Organizations that invert this — deploying first, then trying to reconstruct what “success” means afterward — almost never produce defensible numbers. They produce stories.

The programs that generate documented, verifiable results are the ones where the measurement architecture is designed before the rollout begins. Not because that is harder. Because that is the only order in which it works.

The good news: 90 days is enough time to do this right. It is also, not coincidentally, the window that produces results defensible enough to put in a deck.

If you are sitting in that room where the bar chart goes up and the CFO goes quiet, this is what was missing. Not the bar chart. The formula behind it.

Subscribe for more from the field on AI adoption and the gap between deployment and actual results: lab.workredesigned.co

Eighty-three percent licensed. Seventy-one percent completed the training. The line chart pointed up and to the right. The steering committee nodded.

Nobody asked what was underneath that number.

Here’s what was underneath it: the seventy-one percent who completed training were not a random sample of the workforce. They were, in ways that would not surprise anyone who has worked in I&D for more than six months, the employees who already felt the most comfortable being visibly bad at something new.

The other twenty-nine percent completed the onboarding email. They did not open the tool again.

And of the seventy-one percent who “adopted”? About forty of them are doing something genuinely new with it. The rest are using it to reformat bullet points.

This is what uneven AI adoption looks like from the outside: a dashboard that says it’s working.

This is what it looks like from the inside: a productivity gain that belongs to the already-confident, while the employees who needed the rollout to reach them are exactly where they were before the licenses were purchased.

Sound familiar? Good. Then this is for you.

Why adoption splits along the lines belonging already breaks

The most important finding in the behavioral science of AI adoption is this: the variable that predicts whether someone will persist through early awkwardness is not technical ability. Not interest in technology. Not job function.

It is the cost of looking incompetent.

For employees who have built deep credibility, long tenure, visible sponsorship inside the organization — looking uncertain with a new tool is a recoverable event. They try something in front of a peer, it doesn’t work, they shrug and try again. The social cost is manageable. So they experiment. So they find the use cases. So they become the internal champions who get featured at the next all-hands.

For employees who are still building credibility — who are already managing the cognitive load of navigating environments not fully built for them, who calculate more carefully how each visible moment lands — looking incompetent with the new tool is not a recoverable event. It’s evidence. So they don’t experiment publicly. They wait until they can do it privately. Private practice requires time they don’t have and a scaffolded space to fail that the rollout didn’t provide. So they close the tab.

This is completely rational behavior under the actual conditions these employees work in.

The adoption gap maps, with uncomfortable precision, onto familiar coordinates: confidence, tenure, first language, proximity to leadership, and whether the employee has ever felt like the room was built for them. The efficiency gap and the inclusion gap widen in the same rollout. Just never in the same sentence.

And here is the thing I want to say as clearly as possible: this is a design problem. Not a people problem. Not a capability problem. A design problem. Which means it has a design solution.

The Want, Ease, Cue Behavioral Lens

Behavioral science gives us a clean diagnostic here. Call it the Want, Ease, Cue framework. For a behavior to take root, three things need to be true.

Want: The person needs to believe this tool will help them, specifically, in their actual work. Not “help people generally.” Help me, on my tasks, in my role, this week. Generic ROI pitches don’t create Want. They create an abstract awareness that AI is probably useful somewhere. Awareness is not the same as motivation.

Ease: The first attempt needs to be easy enough to produce a result that feels good. Not impressive. Just good enough to keep trying. This means low stakes, a place to practice, and enough scaffolding that the first use doesn’t require performing competence in front of people you’re trying to impress.

Cue: Something in the person’s actual environment needs to remind them to use it, at the right moment. Not a launch email. Not a Slack announcement sent to all eight hundred employees. A specific, recurring signal built into the normal rhythm of their actual work.

Most rollouts address these three things once each. The kick-off call addresses Want. The ninety-minute training addresses Ease. The monthly newsletter addresses Cue.

Then the rollout declares it’s done and moves to measurement.

Here’s what actually happened: Want worked for people who were already motivated. Ease worked for people who were already comfortable learning publicly. Cue worked for people who were already paying attention to company communications.

For the employees who needed more from each of these, one pass through the funnel was not enough.

The employees who were already confident went home and experimented on their own until they got it. The rollout just gave them a timeline. The employees who needed the rollout to meet them where they were — they needed the rollout to actually do that. It didn’t. And now they’re in the twenty-nine percent.

What to look for in the equity audit

Before a rollout hardens into permanent adoption patterns — typically somewhere between months three and six — there’s a real window to change it. After month six, the patterns tend to calcify. Here is what to audit and where to look.

Adoption data, cut by demographic proxies. Not by stated identity — that creates compliance issues and asks for data many organizations can’t legally collect or use. By tenure band, by department, by job level, by location. These are imperfect proxies. But they surface the shape of the gap. If adoption is significantly higher among employees with ten-plus years of tenure, or among senior individual contributors, or in certain locations, that pattern is not random. It’s telling you something.

The training design, specifically the performance requirement. Does the onboarding require employees to practice in front of each other? Share outputs for group feedback? Does the group format put some employees in a position where being wrong has a different cost than it does for their peers? High-performance-risk training disproportionately deters the employees who most need a safe place to try. It’s the design equivalent of teaching swimming by requiring everyone to demonstrate their stroke in front of the class before they’ve had a chance to practice.

The cue architecture. What actually tells an employee to use the tool on a given Tuesday afternoon? If the honest answer is “their own motivation” or “the all-hands from last month,” the cue architecture is relying on intrinsic drive. Intrinsic drive is a resource distributed unevenly. Rollouts that depend on it reach people who were already motivated — which is a fine thing to do, but it’s not a rollout. It’s a self-selection event.

The manager layer. What are managers doing with AI? What are they modeling publicly? What are they explicitly making space for? Employees take behavioral cues from the person whose opinion of their work matters most. A manager who has not visibly adopted the tool sends a clear signal: this is optional. That signal lands differently on different employees. For the employee already calculating every visible risk, “optional” reads as “not worth the exposure.”

The moves that close the gap

Let me be very clear about something before we get into specifics: these are not equity initiatives bolted onto an efficiency project. They are better rollout design. Every employee benefits. The employees who most needed the rollout to reach them experience the largest difference.

Segment the Want conversation. One kick-off deck does not address Want for every job function, every seniority level, and every person’s actual daily frustrations. Build use-case conversations by team and by role, facilitated by a manager or peer, that help each person connect the tool to the specific thing they most dread doing. Not “here’s what AI can do.” Here’s how this might help you stop doing the thing you hate most. That conversation takes twenty minutes. It creates genuine motivation in a way that forty-five minutes of ROI data does not.

Design practice that doesn’t require an audience. Small cohorts of three people, matched for role and seniority, with a structured first-use task and a single clear output. The goal is not for anyone to look impressive. The goal is for everyone to get one win before they have to use the tool in front of someone who evaluates them. One win is enough to create the second attempt. The second attempt is what creates the habit.

Build cues into existing workflows, not alongside them. The question is not “what new reminder can we create?” It’s “which meeting that already happens could include one standing agenda item? Which checklist that already exists could have one step that references AI?” The best cue is one the employee doesn’t have to remember. It appears because the process they already follow makes it appear.

Make manager adoption visible and specific. Not a mandate. A norm. Which manager is going to share, at the next team standup, one thing they tried with AI this week — including what fell apart? That modeling matters more than any amount of training content. The employee who is calculating the cost of looking wrong needs to see their manager willing to look wrong and be fine.

The harder framing

The efficiency case for AI is real. The time-to-value gains are measurable. The business rationale holds.

But a rollout that reaches only the already-confident doesn’t deliver those gains to everyone. It delivers them to a segment of your workforce. Six months later, the employees who were already winning at work are further ahead. The employees who were navigating more are further behind. Quietly. Inside a project that got filed under productivity.

*We spent six months on this.*

*We have the dashboard.*

*Nobody’s going to say the rollout created a two-tier workforce.*

*Nobody’s going to say it out loud.*

I know you’re sitting with this. And the answer isn’t to slow the rollout or turn the efficiency initiative into a committee that deliberates for another two quarters. It’s to design it so it actually reaches everyone. The tools exist. The framework is specific. The window is still open.

**The productivity gap and the inclusion gap widen in the same rollout. You can close both at once — but only if you design for everyone from the start.**

That’s the work. It’s good work. And you can absolutely do it.

This is the space for practitioners doing this work in real time: auditing rollouts for equity risk, building the behavioral architecture that makes AI reach everyone, sharing what’s actually working in the field. Come subscribe at https://lab.workredesigned.co. We’d love to have you.

*AI handles the busywork so your team can focus on the work that matters.*

Somebody made that slide with real conviction. Somebody presented it to a leadership team that nodded along. And then everybody went back to their desks, and the slide quietly became one of the great unkept promises of modern work.

I want to walk you through exactly how that promise breaks, because BCG just published the receipts. And then, because I refuse to leave you in the problem, I want to show you the people who kept the promise and exactly what they did differently.

Deep breath. Here we go.

The good news, then the plot twist

Their 2026 AI at Work report surveyed close to 12,000 workers across 14 markets. Here is the finding that stopped me in my tracks, in the best way.

Forty-two percent of regular AI users on the front line are saving at least a full workday every single week. That is not a vendor projection. That is real people reporting real, recovered time. Eight hours. Gone from the busywork column.

Take the win for a second. The time savings are real. The tool works.

Sixty-six percent of those same people get little or no guidance on what to do with the time they just saved. And more than half never redirect it into anything strategic. BCG’s phrase for what happens next is almost poetic for a consulting firm. The time saved “leaks out of the organization.”

It leaks. You paid for the tool, your team did the hard work of learning it, the hours came back exactly as promised, and then they slipped right out through a crack nobody thought to seal.

If you have felt this on your own team, it’s a real thing and you aren’t crazy.

Where the hours actually go

Let me make this real, because “time leaks out” sounds abstract until you have watched it happen at your own desk.

The hours do not float off into nothing. They get refilled.

The second someone finishes a task in twenty minutes instead of two hours, the system notices that lovely open space and stuffs it.

More tickets. More drafts. More requests that used to be “we do not have capacity for that” and are suddenly, magically, things you have capacity for. The work expands to swallow the time. It is one of the oldest laws in operations, and AI did not repeal it. AI just made it faster.

And here is the second leak, the one that genuinely surprised me. Forty-seven percent of workers now spend more time managing and directing AI than doing the actual work. We bought tools to take work off our people, and half of those people now spend the day supervising the tool instead.

You have seen this movie. Someone asks the AI to draft the thing. It comes back almost right. So they re-prompt. Still almost. They tweak the prompt again, get closer, then spend ten minutes fixing the parts that are subtly off, and somewhere in there they think the words every rollout dreads: *it would have been faster to just do it myself.*

That is not your person failing. It is not even the tool failing. The tool did exactly what tools do. What broke was the design around it. And design, my friend, is something we can change.

The thing nobody redesigned

Here is the heart of it, and I am going to say it plainly, because that is what this newsletter is for.

Your AI did not save your team time. It offered to. Whether they got to keep it came down to one question almost nobody asked: did you redesign the work, or did you just bolt a faster engine onto the same old process?

Most companies did the second thing, and honestly, that is completely understandable. They took a workflow that was built, step by step, for humans doing every step, and they dropped an AI into the middle of it. The workflow kept its old shape. The handoffs stayed. The approvals, the formats, the who-checks-whose-work, all of it sat exactly where it was the day before the tool arrived. So the AI could only speed up little steps while a human still had to escort it through every junction, catch its mistakes, and reshape its output to fit a process designed for a different kind of worker.

You did not get a redesigned workflow. You got the old workflow with a very fast, slightly unpredictable new teammate wedged into the middle of it, and that teammate needs a lot of supervision.

That is why the time leaks. There was no new container built to hold it. So let’s build the container.

The cohort that kept the hours (this is the fun part)

Here is where I get excited, because BCG did not just find the problem. They found the people who solved it.

They compared two groups.

One bought AI and deployed it: licenses, a launch, some training, done.

The other bought AI and redesigned the work around it. They took whole workflows apart and rebuilt them for a world where the AI does certain steps and the human does the steps that actually need a human heart and brain.

The redesign group was 24 points more likely to see real business improvement. They were 22 points more likely to actually save a full day a week, the exact time savings everyone else was promised and lost. And they were 20 points more likely to report being happier at work, because their people were not drowning in a more demanding version of the same job.

Same tools. Same models. Same price tag. The entire difference was what they did to the work.

BCG put a number on it that I cannot stop thinking about. A better tool lifts AI’s impact by roughly 5 points.

A clear strategy and redesign lifts it by 25. So picture it: an entire industry sprinting around shopping for a better model, a five-point lever, while the twenty-five-point lever sits right there, patient and unglamorous and totally available to anyone willing to pick it up.

You are allowed to be the one who picks it up.

What this actually means on Monday at 1:36PM

Here is the relief. You do not need a bigger budget. You do not need a better model. You do not need to send anyone to another prompting webinar, and honestly I would gently retire those, because teaching people to prompt a broken workflow faster just gets you to the broken outcome sooner.

You need to pick one workflow. Just one. The one where your team feels busiest and least sure why. And you redraw it from scratch with one question in front of you: if the AI is genuinely great at certain steps, what should this whole process look like now? Not “where can I wedge AI into the process I already have.” Start fresh.

That is the move. It is not flashy. It will not get applause at the all-hands. But it is the entire difference between the 42 percent who keep a real workday and the two-thirds who watch it leak away.

The honeymoon ends on schedule either way. BCG found the joy of AI fades within about a year unless there is real direction behind it. The teams that reshaped the work kept the joy and the hours. The teams that just deployed kept the license and the exhaustion. You get to choose which team you lead.

A few years into my career, I helped light roughly $100K on fire at Google.

Of course we did not call it that. We called it an AR rollout.

And before you click away because your problem is AI, not augmented reality: it is the same story. Same rollout, same mistake, same flatline. AR just got there first.

Here’s the scene. We were putting a piece of wearable AR on frontline technical staff.

The thing was genuinely cool. It put instructions right in their field of view: which tools to grab, how to install it, a real-time check on their work. We built a sharp training program. We flew it to our teams around the world. We did everything needed for an enterprise global launch.

And it worked. For about six weeks.

Then it did the thing every rollout does, the thing nobody likes to say out loud.

It quietly face-planted.

Usage chart went up, peaked, and slid right back down like a kid on a water slide. By week eight, people were doing the job the old way again and being very polite about it.

We blamed the training. Of course we did. The training was right there, easy to blame, couldn’t defend itself.

But the training was not the problem. We had made the single most common mistake in the entire field, and I would go on to watch dozens of companies make the exact same one.

We trained the tool, but we never redesigned the job.

Let me say that again because it is the whole ballgame.

We taught people which buttons to press. We never told them what their actual job was now that a machine could press half the buttons for them. So the second the novelty wore off and someone hit a snag, they did the most reasonable thing in the world.

They thought, “you know what, I can do this faster the old way,” and they bailed. The old way was genuinely faster *for them in that moment*, because nobody had redesigned the work so the new way actually won.

(If you have ever rolled something out and watched the usage chart flatline by Q2 while everyone assured you it was “still ramping,” you already know this feeling in your bones. Hi. Welcome. You’re in the right place.)

So here is what I figured out, the expensive way, across a decade of running tech rollouts inside Google, Meta, Uber, YouTube, and DoorDash.

The tool keeps changing and the human pattern does not. Behavior change is not “teach it once and clap.” You do not change how humans work by handing them a slide deck and some encouragement. You change it by quietly rebuilding the work underneath them, so the new way is genuinely easier, feels like an upgrade, and gives people an actual reason to want it.

My favorite proof of this is DoorDash, because it went the opposite direction everyone expected.

We were moving support from all-human phone calls to a tiered setup where AI would handle the boring, repetitive tier-one stuff. The agents were, to put it gently, not thrilled. You can imagine the vibe. “Oh cool, so you built a robot to take my job, love that for me.”

By the end of the rollout, their satisfaction scores went *up*. Significantly.

The difference was one move almost every company skips. We closed the loop. We did not just announce the scary part (”AI is taking some of your calls”) and then wander off to let everyone spiral. We told them the rest of the sentence: “and here is the better work you get to do instead.” The judgment calls. The messy human ones the robot cannot touch. The work the boring volume had been crowding out for years.

Open loop, it reads as a layoff warning. Closed loop, it reads as a promotion. Same exact technology. Wildly different Tuesday.

And that, friend, is why this newsletter exists.

Right now your company is probably spending real money putting AI in front of people, and most of it is landing exactly like my Google AR pilot did. A license, a training, a launch email, and a usage chart that goes flat while everyone nods supportively. The tools keep getting better, but the adoption keeps faceplanting. The gap between those two things is the most expensive problem nobody is actually talking about.

So here is who I am writing for, and it is probably you. Not the executive who signed the contract and went back to their calendar.

The person one level down who actually has to make the thing work. The manager, the team lead, the practicioner who got “drive AI adoption” added to a job that was already full, with no budget and a brave little smile. You can see the rollout wobbling before anyone above you can.

And here is the good news: you are also the person who can actually fix it, even without the fancy title.

Every week I am going to write about the part that actually matters. Why rollouts revert. Why the time AI “saves” mysteriously evaporates back into busywork. How to redesign one workflow so the change sticks. What the research really says once you scrape off the headlines. Plain, useful, occasionally a little spicy, and always aimed at the human doing the work instead of the human who bought the software.

No fifty-tool listicles. No “AI will 10x your synergy” nonsense. Just the behavior side of this whole thing, which, plot twist, is the side that decides whether any of the money was worth it.

If your team got AI and somehow got *busier*, you are absolutely in the right place. Subscribe, and I will see you in your inbox every week.

A tool makes the old job faster. Redesigning the job is what makes it stick. That is the whole thing, and it is what I am going to spend this newsletter showing you how to do.

P.S. Hit reply and tell me where your rollout is stuck right now. I read every single one, and the realest questions become future issues. Misery loves a comment section.