Companies are experimenting with AI, but that doesn’t necessarily mean they’re seeing meaningful business results.

In my first Substack Live, I explored a challenge I’m seeing in conversations with business leaders: different executives often have very different ideas about what AI should accomplish.

A CTO might focus on technology and infrastructure. A COO might see opportunities to improve operations and efficiency. A CHRO might be thinking about how roles, training, performance, and the employee experience need to change.

These are all important perspectives. The problem is that they don’t automatically add up to a shared business strategy.

Without that alignment, companies risk remaining in what I call AI dabbling, where individuals and teams experience productivity improvements, but the business as a whole struggles to capture measurable value.

Leadership Alignment Comes Before Technology

One of the biggest opportunities for leadership teams is developing a shared understanding of AI and the broader technology landscape.

That doesn’t mean every executive needs to become a technical expert. But leaders should understand enough about emerging technologies, including different types of machine learning, to recognize what may be possible beyond today’s popular AI tools.

It’s also worth looking three to five years ahead. The technology available today is only part of the picture.

More importantly, leadership teams need to agree on the business result they’re trying to achieve.

Improving efficiency or increasing revenue is a starting point, but those goals are still too broad on their own. Leaders need to identify where the opportunity exists, what needs to change, and how those changes will translate into value.

Stop Adding AI to Business as Usual

For years, businesses have adopted software that helps them execute existing processes more efficiently.

Salesforce, for example, provides tools for managing the sales process, from an initial lead through closing a deal.

AI introduces a different possibility.

Rather than simply purchasing software to improve an existing workflow, businesses can increasingly explore building systems around their specific needs.

This changes the role of leadership.

Instead of asking how AI can make an existing process faster, leaders should be asking what that process would look like if they were designing it today.

What steps could disappear entirely? Where could AI take on work previously performed by employees? Where would people and AI collaborate? And where does human judgment remain essential?

Simply accelerating an existing process can create new bottlenecks, increase pressure on employees, and amplify problems that were already there.

The opportunity isn’t just to make business as usual faster. It’s to reconsider what business as usual should look like.

And even when AI performs more of the work, people remain accountable for the decisions, customer experience, and business results.

Think Bigger Than One Use Case, but Start Small

Another distinction I explored was the difference between selecting an individual AI use case and redesigning a larger customer or operating experience.

A single use case might improve one task.

Redesigning an experience requires understanding how multiple activities, decisions, technologies, and people work together to produce an outcome.

That doesn’t mean transforming the entire company at once.

I recommend choosing one high-value domain, such as operations, sales, finance, technology, or HR, and identifying an experience within it that could produce meaningful business value.

From there, consider multiple ways that experience might work differently using AI and other technologies.

Your organization’s data is an important part of this conversation. Understanding what data you already have, how it connects, and where it needs improvement can help reveal opportunities that aren’t obvious when you start by comparing software products.

Don’t Start Change Management Before You Know What’s Changing

I also discussed why organizations sometimes begin talking about change management too early.

It’s difficult to prepare employees for a transformation when leaders haven’t defined what the future way of working will actually be.

Changes to work affect more than efficiency. They influence responsibilities, employee expectations, and how people identify with their contributions.

Rather than immediately introducing a major organizational change, businesses can test alternative ways of working through smaller pilots.

Those experiments help leaders understand what works, what doesn’t, and what adjustments are necessary before expanding.

The goal is to learn before committing the entire organization to a new approach.

One Leadership Meeting You Can Run

If you’re leading a business or working with an executive team, here’s an exercise I recommended during the Live:

1. Choose one customer or operating experience. Focus on an experience within a business domain that has meaningful potential for improvement, rather than picking an isolated AI task.

2. Agree on the business result. Define what should improve for customers and the organization, whether that’s revenue, efficiency, speed, or another measurable outcome.

3. Explore how the work could be redesigned. Consider the roles of people, AI, existing systems, and organizational data. Don’t begin by choosing a product.

4. Develop two to four possible ways of working. Challenge assumptions about how the experience currently operates instead of automatically preserving every existing step.

5. Test before scaling. Use smaller experiments to understand what creates value, what needs adjustment, and what employees will need to succeed.

This gives leaders something more useful than a collection of AI ideas. It gives them a shared direction and a way to begin testing it.

From Incremental Improvement to Business Innovation

In the Live, I also shared observations from my work with companies, including opportunities for double-digit improvements in efficiency, revenue, or a combination of the two.

The timeline varies depending on the size and complexity of the organization. Smaller businesses may be able to make meaningful changes within months, while larger organizations may need a year or longer.

These results aren’t automatic. They depend on the opportunity, the quality of implementation, and whether the organization can sustain the new way of working.

But the broader point is that AI creates an opportunity to think beyond the incremental improvements businesses have traditionally pursued.

It asks leaders to become innovators, not just operators.

And there’s a reason to start exploring now.

Businesses that wait until competitive pressure or declining performance forces them to change may have fewer options and less room to experiment.

Starting while the business is healthy gives leaders the space to question existing assumptions, test possibilities, and make thoughtful decisions about the future.

Continue the Conversation

The question I want to leave leaders with is this:

If you were building your business today, knowing what AI and emerging technologies can make possible, what would you design differently?

That’s a much more valuable conversation than simply asking which AI tools your company should adopt next.

If you’re exploring how to move from scattered AI activity to measurable business value, I’d love to connect.

Learn more about my work at Work Redesigned, or reach out to me on LinkedIn or here on Substack.

Get more from Keith Anderson in the Substack app

Available for iOS and Android

Get the app

But when Thursday evening arrives, you’re still finishing estimates after dinner while a customer waits for a quote. Someone has asked whether the price includes materials, so you’re digging through messages to find out what was agreed

While the writing got faster, your evening still disappeared.

When you use AI, how do you connect what it does to something you actually want to improve?

The tool can be useful while the problem remains

There’s plenty to enjoy about experimenting, especially when you try a prompt and discover that a task you’ve been avoiding is more manageable than you thought. That learning has value.

The trouble starts when choosing tools takes over the conversation, because you can spend an afternoon comparing features without deciding which problem deserves your attention.

Before another subscription joins the family, it helps to ask what you want to be different.

Maybe customers wait too long for answers because employees are correcting information that should have been right the first time. Or perhaps the business runs fine as long as you’re available every waking minute.

Because those problems have different causes, they need different changes, and success will look different for each.

I’ve been developing REALIZE to help work through those decisions, drawing on management ideas from my work with small to mid-sized businesses, McKinsey’s AI Transformation Frameworks and adapting them into a working approach for smaller businesses and teams.

The goal is to connect a credible AI possibility to a first measurable business result while making sure people can keep the improved process running.

REALIZE gives each stage a decision to make

Here’s how I’m organizing that work to make sure your AI efforts deliver measurable business value, rather than simply creating more activity without a clear return on investment.

1. Recognize The Possibilities

Start by understanding what AI can contribute to your business today, including where its limitations could affect the work.

AI is advancing so quickly that what you thought was impossible even a few months ago may already be achievable, while tasks that once required significant technical expertise may now be much easier to accomplish.

For the home renovation business, AI might help organize a messy customer inquiry, prepare a draft using approved information, or coordinate parts of a workflow that previously required several manual steps.

A successful example helps the owner imagine what’s possible, while an example that fails reveals where human judgment, oversight, or better information is still needed.

The goal of this stage is to establish a current baseline of what AI can realistically do for your business, while also developing an informed perspective on how its capabilities may evolve over the next 6 to 12 months.

You don’t need a perfectly defined AI project to begin exploring, but you do need to understand both today’s possibilities and limitations so you can make informed decisions without building your strategy around assumptions that may soon be outdated.

2. Establish The Priority

Once you understand what AI can make possible, the next step is to narrow your focus to the specific business value you want to achieve. Rather than trying to improve everything at once, identify one meaningful outcome that would make a measurable difference to your business.

That outcome might be reducing customer onboarding time, increasing customer lifetime value, lowering operating costs, or freeing up eight hours a week so the owner can focus on growing the business. For our home renovation business, the owner might prioritize reducing the hours spent preparing proposals in the evening while maintaining accurate estimates and a positive customer experience.

The key is to be clear about what success looks like, including what you want to improve and how you’ll measure the change.

Although AI may present dozens of promising opportunities, choosing one specific business outcome gives your experiment a clear purpose, a manageable scope, and a way to determine whether the investment is actually delivering value.

Share

3. Assess The Current Work

Before deciding what to change with AI, take a close look at how the work actually gets done today, not just how you think the process works.

Even if your current workflow seems streamlined, chances are there’s more complexity beneath the surface. Think about all the exceptions you handle, the workarounds you’ve developed, the unexpected situations that require someone to step in, and the contingencies you’ve built into the process to keep things moving. These details are easy to overlook because they’ve become such a normal part of running your business.

And don’t worry if things are messier than you expected. I see this all the time, and I’ve found that those willing to show how the work really happens, including the messy parts, often uncover the greatest opportunities for AI to deliver business value.

As you follow real examples through the workflow, document where time is spent, where people wait, what gets corrected, and how exceptions are handled. Talk to the people doing the work, including whoever receives the output next, because an improvement for one person shouldn’t simply create more work for someone else.

For our home renovation business, this might reveal that preparing proposals isn’t actually the biggest time drain. Perhaps the owner spends more time chasing missing customer details, revising estimates when project requirements change, or coordinating with subcontractors. Understanding these realities helps identify where AI could make the biggest difference while establishing a reliable baseline for measuring the results.

The goal isn’t to make your current process look good on paper. It’s to understand it well enough to make it better.

4. Lay Out The Improvement

Once you understand how work happens today, the next step is to design how it should happen with AI. There’s a lot to consider here, and this stage deserves a few articles of its own. For now, the important thing is to recognize that not every part of your workflow needs AI, and not every task should be handed over to it.

Start by reimagining the workflow rather than simply recreating your existing process with AI.

One of the biggest mistakes businesses can make is assuming that AI should follow the same steps people have always followed, just faster. Instead, ask yourself how the work might be accomplished if you were designing the process from scratch with today’s AI capabilities. Some steps may no longer be necessary, others could be combined, and entirely new approaches may become possible.

You don’t have to figure all of this out yourself, either. ChatGPT and Claude have extensive knowledge of business processes, automation approaches, and AI capabilities. Use them as brainstorming partners. Describe the business outcome you’re trying to achieve, share how the work happens today, including its exceptions and complications, and ask how the workflow could be redesigned to achieve that outcome more efficiently.

Challenge their recommendations, explore alternatives, and have them identify risks or assumptions you may have overlooked. You bring the understanding of your business, while AI can help you discover approaches you might not have considered.

As you explore these possibilities, start separating the parts of your process that are deterministic from those that are non-deterministic.

• Deterministic tasks follow clear rules and produce predictable results, such as checking whether a required field is complete or calculating a price using a fixed formula.

• Non-deterministic tasks involve interpretation, judgment, or decisions where there may be more than one acceptable answer, such as understanding a customer’s unusual request or drafting a personalized response.

While it’s tempting to assume AI should handle the entire redesigned workflow, a combination of traditional automation, AI, and human judgment will often produce better results. It’s also worth understanding the difference between these approaches. Traditional automations follow predefined rules, AI tasks use models to interpret or generate information, and AI agents can coordinate multiple steps, use tools, and make decisions within defined boundaries. More sophisticated doesn’t necessarily mean more valuable.

Next, look closely at the data your process depends on.

• What information is needed, and at which points in the workflow?

• Are you providing that information yourself, collecting it from customers, or retrieving it from another system?

• How accurate, complete, and current is it?

Even a capable AI system will struggle to deliver reliable results if it’s working with incomplete or incorrect information.

Then comes an important question: How much of this process are you actually comfortable trusting AI to handle?

You don’t need to give AI control over everything to get meaningful business value. In fact, I recommend beginning with internal workflows where errors can be caught and corrected before they affect customers. Your first implementation should help you build confidence in the technology while delivering a measurable improvement, rather than introducing unnecessary risk into customer-facing work.

For our home renovation business, a redesigned workflow might begin with a clearer intake form that gathers the essential project details. A traditional automation could check whether required information is present, while AI could organize the customer’s description and prepare a proposal draft using approved information. Before anything reaches the customer, the owner would review the proposed scope, pricing, and commitments.

But what if we challenged that design further? Rather than having the owner manually collect every detail, perhaps an AI-powered intake assistant could ask customers follow-up questions, identify missing information, and organize their answers into a structured project brief. The owner might only need to review the completed brief and address unusual situations. That’s the value of reimagining the workflow instead of simply automating each existing step.

If any part of that process makes you uneasy, that’s useful information. It doesn’t mean you need to abandon the idea. It means you should establish clear boundaries and personally evaluate the AI’s output until you have enough evidence to trust it. As you see consistent results, you can decide whether to expand what the system handles independently.

Finally, compare your proposed design with simpler alternatives. Sometimes a better form, a checklist, or a few fixed rules will solve the problem without AI at all. The objective isn’t to fit as much AI into your business as possible. It’s to design a workflow that delivers the business outcome you’re after, with the right balance of efficiency, reliability, cost, and human oversight.

5. Investigate Through Testing

Once you have a working prototype of your redesigned workflow, the next step is to evaluate whether it consistently delivers the results you expect. Getting AI to complete a task successfully once is encouraging, but that doesn’t mean you have a reliable process.

Think of AI as an employee. Well, sort of. Give it the same task several times, and it might approach things differently each time. It could overlook instructions, forget details, introduce information you didn’t request, or find creative solutions to unexpected problems. Some variation is useful, but you need confidence that the results consistently meet your business standards.

This is where quality checks, often called evaluations or evals, come in. Test your workflow with different examples, including ones that contain missing information, unusual requests, or conflicting details. For our home renovation business, what happens when a customer leaves out important measurements, requests a service you don’t offer, or provides information that could lead to an incorrect estimate?

Start by reviewing the results yourself, checking both accuracy and whether the output meets your expectations. Human review is valuable, but it becomes difficult to scale. As your workflow matures, consider adding AI-based reviewers that automatically evaluate outputs against defined criteria. For tasks with clear, deterministic rules, such as verifying that required fields are present or calculations fall within established limits, simple coded checks can provide more predictable validation.

The goal is to build quality checks directly into your workflow, rather than relying on someone to catch mistakes afterward. Remember to measure the time spent reviewing and correcting AI’s work, too. If generating a proposal becomes faster but fixing its mistakes takes longer, you haven’t achieved the business value you’re looking for.

A successful prototype shows what’s possible. Consistent, measurable performance tells you whether it’s ready for your business.

6. Zero In On Adoption

Once you’re satisfied that your AI workflow consistently produces reliable results, the next step is to make it a standard part of how your business operates.

A successful prototype is one thing, but getting employees to use it effectively during their normal working day is another.

Start by defining how the workflow will operate.

• How often should it run?

• What does the employee need to do for it to succeed?

• What are they responsible for reviewing or approving, and what happens when something goes wrong?

Someone should clearly own the process, including handling exceptions, fixing problems, and knowing when to fall back on the original way of doing things.

Employee adoption is just as important as the technology itself. Depending on how much the workflow changes someone’s responsibilities, you may need to provide training, opportunities to practice, and clear instructions for handling unusual situations.

Don’t assume that because a process is easier or faster, employees will automatically know how to use it or feel comfortable trusting it.

For our home renovation business, the owner might hand off proposal preparation to an office manager who now reviews AI-generated drafts instead of creating them from scratch. That employee needs to understand what the AI handles, how to verify estimates, when to intervene, and who to contact if the system stops working.

After the workflow has been running in your business for at least a few weeks, sit down with the person responsible for it and review what’s actually happening.

Are employees using it as intended? Where are they encountering friction, creating workarounds, or spending more time than expected? Look for opportunities to simplify the process, improve reliability, and reduce unnecessary oversight.

The goal isn’t simply to introduce a new AI workflow. It’s to make the improvement a sustainable part of your business, with clear ownership, confident employees, and a process that continues to get better over time.

7. Evaluate Value

Now it’s time to measure whether your redesigned workflow is delivering the business value you set out to achieve. Start by comparing how the work was done before AI with how it operates today, looking at the time required to complete each task, total employee hours involved, operating costs, and how much work the business could handle with its previous process.

Then measure those same factors with your new AI-powered workflow. How much time are you saving? Has the cost of completing the work decreased, including the cost of AI tools and human oversight? Can your business now handle more customers or complete more work without adding employees?

For our home renovation business, perhaps preparing proposals previously required 10 hours of the owner’s time each week, but the new workflow has reduced that to two hours. That’s eight hours the owner can now spend meeting potential customers, managing projects, or simply getting their evenings back.

Focus first on the measurable business outcome you identified earlier in the framework. Did you achieve what you set out to accomplish? Once you’ve answered that question, look for additional benefits you may not have anticipated, such as faster customer responses, fewer errors, increased capacity, or improved employee satisfaction.

Finally, use what you’ve learned to decide what happens next. You might continue with the workflow, make further improvements, expand it to other parts of the business, or even stop using it if the results don’t justify the investment. All are valid decisions when they’re supported by evidence.

Remember that these stages aren’t always linear. As you measure results and learn more about how AI performs in your business, you may discover opportunities to revisit earlier decisions. The goal isn’t simply to prove that AI works. It’s to prove that it’s making your business better.

How to Use REALIZE in One Small Experiment

Seven stages can sound like the beginning of a very large change.

For a small, low-risk workflow, the essential decisions may fit in one shared document, provided the effort still reflects the consequences, dependencies, and complexity of the work.

A personal drafting experiment needs less structure than a process making customer commitments, while a consequential decision may require specialist help even in a tiny company.

A small experiment can still ask useful questions.

Choose one part of your work and write down what you want to improve, what currently happens, and what would count as evidence of a better result. Once you’ve done that, name the uncertainty you need to investigate first.

You can start there.

Where have you tried AI in your work, and what were you hoping would improve? Leave a comment or reply and tell me where you got stuck.

If you’re trying AI but struggling to connect it to a useful change in the work, subscribe for practical ways to choose and test your next step at

Work Redesigned w/ Keith Anderson

Practical guidance for managers, leads, and senior ICs who can see what AI could do for their team but aren't sure how to make it real from where they sit.

That’s useful work, but you may still be unable to explain how a team should change its workflow, what its people need to contribute, or how their performance will be evaluated.

Acceptable-use boundaries answer part of the question, but a shared plan has to connect those boundaries to everyday work.

When HR’s involvement ends at policy, business and technical decisions can reshape responsibilities before anyone has joined up the workforce implications. A task gets faster, but review becomes someone else’s problem. Employees hear encouragement to experiment while wondering what their experimentation means for their jobs.

Two consequences deserve attention:

1. Useful local improvements may struggle to scale

2. Employee trust can erode as expectations change without a clear conversation.

I think HR needs to lead that conversation, working with business and technical leaders on a shared plan. The framework I like to use when working with the role HR plays in AI is called the 3Ws: Work, Workforce, and Workplace. This framing gives HR leaders the language and advocacy points needed to steer the conversation from a People perspective while collaborating with fellow executive peers.

Work needs a plan for the whole workflow

Start with what the company needs to accomplish, then follow the work through its tasks, handoffs, decisions, and quality expectations. Within each workflow, ask:

• What should remain human-led?

• What AI can handle?

• Where people and AI can work together?

Then decide where a person needs to exercise judgment, challenge an output, or make the final decision.

Imagine a hypothetical sales team that starts using AI to draft proposals. Drafting gets faster, so more proposals arrive with the commercial team for review. Nobody has agreed what evidence a draft should include, which commitments require checking, or how the next team will handle the extra volume.

Although drafting has improved in this example, its value across the workflow remains an open question.

Business leaders need to agree what changes upstream, what the reviewer receives, who approves exceptions, and how the downstream team uses the result.

Better performance might mean shorter time to an approved proposal, less rework, or more reliable commitments. Choose the measures that fit the business outcome.

McKinsey’s March 2025 report, based on 1,491 respondents across 101 countries, linked workflow redesign with greater self-reported financial impact from generative AI. That association supports looking beyond isolated tasks; it doesn’t prove redesign caused the gains.

The decision is how the workflow should change and what would count as better performance.

Have we agreed on how the work should operate with AI, or are individuals deciding for themselves?

Workforce contribution needs to be clear

Once the workflow changes, the capability conversation becomes specific.

While the proposal writer judges whether generated claims are supported, the reviewer may need to spot omissions, test assumptions, and explain why a plausible recommendation should be rejected. Responsibility needs to remain clear when several people and an AI tool contribute to the same output.

Tool training helps people get started, but role-specific judgment, accountability, and changing responsibilities still need deliberate attention.

In a 2023 experiment involving 758 BCG consultants, AI improved performance on tasks within its tested capabilities. On a task outside those capabilities, AI users were 19 percentage points less likely to reach a correct solution. Those results concern GPT-4 and the study’s tasks, rather than today’s tools generally. They illustrate why capability development should include deciding when and how to rely on AI.

Managers need support too.

When you give them work samples, agreed review standards, and time to coach, they have a practical basis for assessing the work. Otherwise, an important decision is left to personal interpretation.

What will someone be valued for as their responsibilities change?

For an employee whose professional identity rests on producing the first draft, a move toward review and judgment may need explanation, practice, and a credible development path.

Invite employee input before expectations harden, and be clear about what is decided and what remains open, including workload, role changes, and evaluation. Avoid promising certainty you don’t have.

Agree what employees and managers must be able to do and how they will be supported.

Can people explain their changing contribution, and do they have the capability and manager support to deliver it?

Workplace support needs to survive everyday use

The workplace question concerns ownership, decision rights, review, support, and escalation. Policy belongs here alongside the practical arrangements people need when something goes wrong.

In another hypothetical example, an employee builds a useful tool that summarizes internal requests, and colleagues begin using it regularly. Then its creator takes leave. Nobody can explain who maintains it, who reviews changes, or where users should report an unreliable result.

Before wider use, agree who owns the tool, what needs review, how support works, and when use should pause. Make room for shared experimentation and learning so colleagues can compare results and resolve questions together.

Check incentives as well. If people are encouraged to improve a shared tool while being evaluated entirely on their existing workload, that extra responsibility needs an explicit decision.

These arrangements support scaling and give employees clearer grounds for trusting how the work is managed. Decide what operating conditions will support effective human-AI collaboration.

When an experiment becomes part of everyday work, can we name who owns it, how it is reviewed, and where people get support?

HR connects decisions across the 3Ws

HR leads the workforce conversation and connects its implications to the wider plan. Business leaders own workflow decisions and business outcomes. Technical leaders own technical decisions and support requirements. Relevant risk specialists contribute where needed.

A change to proposal drafting may require new review capabilities, manager guidance, and a support process, so those decisions need to be made together, with employee input.

Choose one AI experiment already happening in your company. Can you explain how the work is changing, how people are being prepared, and how the workplace supports it?

Sources

1. Paul McDonagh-Smith, MIT Sloan Executive Education. From AI Adoption to Adaptation in Work, the Workforce, and the Workplace, January 13, 2026. Teaching source for the three lenses; the diagnostic questions here are my application.

2. McKinsey/QuantumBlack. The state of AI, March 12, 2025. Survey of 1,491 respondents across 101 countries; fieldwork conducted in July 2024.

3. Dell’Acqua and coauthors. Navigating the Jagged Technological Frontier, HBS Working Paper 24-013, 2023. Randomized experiment with 758 BCG consultants using GPT-4.

4. Lane, Williams, and Broecke. The impact of AI on the workplace, OECD, 2023. Surveys of 5,334 workers and 2,053 firms in manufacturing and finance across seven countries; fieldwork conducted in 2022.

5. MIT Sloan Office of Communications. Why some organizations turn AI experiments into business value while others quietly fail, September 9, 2026. Institutional report of a two-year field study of two organizations by Kellogg, Wiesenfeld, and Karunakaran.

People across your organization are using AI to prepare drafts, analyze information, and handle tasks differently. Yet when someone asks, “What’s actually happening across the business, and what is this work turning into?” you find yourself reaching for examples without a clear account of what they add up to.

You can describe the activity from what you’ve heard, but explaining where it is taking the organization is harder.

For an HR leader, that uncertainty has practical consequences: you may be supporting employees through changes whose implications for their roles are still unresolved, while the decisions about processes, systems, and authority sit across several parts of the business. How do you help people develop for work that leaders haven’t yet described clearly?

The distinction between Work, Workforce, and Workplace, described by Paul McDonagh-Smith at MIT Sloan, gives you a way to examine the moving pieces. He emphasizes their interdependence; looking at them together helps you connect changes in tasks to changes in people’s contribution and the environment that supports both.

In this framing, Work concerns what gets done and how it produces a business result. Workforce concerns the people whose capabilities, responsibilities, and professional identities are changing. Workplace concerns the physical, organizational, and digital conditions in which that work happens.

Those distinctions can help you describe what is changing now, identify what remains unresolved, and consider how the organization could develop from scattered activity into a more deliberate way of working. Here’s how I would bring them to a leadership conversation.

Share

Work: what changes between the task and the business result?

The Work lens follows a task into the decisions and handoffs around it, so you can examine how an AI-assisted output contributes to the result the business needs.

Consider a hypothetical customer-onboarding team in which AI helps prepare an account summary before Sales hands a customer to Implementation. Describing the change as “AI writes the summary” tells you what happens at one point in the workflow. The more consequential question is whether the receiving team can understand the customer’s requirements, recognize what Sales has promised, and decide how to proceed.

Following the summary through that handoff could reveal several design questions:

• Which details need to be checked against their sources?

• How will uncertainty appear in the document, and who can resolve a promise that conflicts with the implementation plan?

• If the receiving person has to repeat the research, you also have a question about how context travels between teams.

Each answer affects how responsibility is divided among people and AI. You might use AI to assemble the information while a specialist checks a consequential claim, then bring a conflicting commitment to the person authorized to resolve it. That allocation deserves examination alongside the business result, because a change in preparation can alter what everyone downstream is expected to do.

The question I would bring to the discussion is:

What changes in the workflow when someone uses AI, and what business result are we examining?

An actual handoff or decision record can make this discussion more useful than a general account of tool use. People can follow the same example and see where their assumptions differ.

Leave a comment

Workforce: what are people being asked to contribute now?

Once you examine how the workflow changes, a second question follows: what does the new design ask of the people doing it?

In the onboarding example, an implementation specialist might have built their reputation on gathering scattered information and preparing a thorough account brief. As AI takes on some of that preparation, the person may welcome the help while wondering what will make their contribution valued in the revised role.

“Use the time for higher-value work” leaves that question largely with the employee.

If the specialist is expected to recognize a mismatch between customer expectations and the implementation plan, the organization needs to make that responsibility concrete.

The person will need to understand the business context, practice weighing uncertain information, and learn how to explain a concern to colleagues who may see the situation differently. Their manager also needs a way to recognize and support that contribution.

This is where I want development to sit: inside a real business problem, with affected employees helping shape the responsibilities they are growing into.

A specialist could compare an AI-prepared brief with the underlying account information, discuss the options with a manager, and revisit the reasoning as more becomes known.

Guided discovery gives the person an opportunity to learn through the work itself.

There is a personal dimension too.

A familiar task may have provided pride, status, or a sense of being useful; when it changes, an employee can lose something they valued before they can see a credible next contribution. Asking about that experience can help leaders understand what the redesigned role needs to offer.

The Workforce question is:

What contribution are people growing into, and where will they get to practice it?

A useful answer would connect the revised responsibility to an opportunity for practice and the support needed to carry it. Training can contribute, while the role gives that learning somewhere to go.

Subscribe now

Workplace: what makes the new way of working possible?

The redesigned workflow and the employee’s growing capability depend on the environment around them. Workplace brings that environment into view, including the physical setting, organizational structure, digital tools, information, and decision authority.

Suppose the specialist in our hypothetical example is expected to flag conflicting commitments, but Implementation cannot access the original Sales information. Even when the person identifies a concern, several managerial approvals may stand between them and someone who can resolve it. The new responsibility now depends on access and authority that the organization has yet to provide.

That creates a leadership decision.

The same lens can help you examine whether the organization makes room for learning and collaboration.

A manager may want employees to develop judgment while their schedules leave little time to review an exception; a team may be encouraged to work across functions while its tools separate the context each function needs. Physical space and digital arrangements can either support those interactions or make them harder to conduct.

For HR leaders, these dependencies create a reason to involve operational and technology colleagues. You can help explain what the revised role requires, then work with the people who own the process, systems, or information to examine what needs to change. The resulting decision might concern a source someone can access, a responsibility a manager can delegate, or time the team can use for guided practice.

The Workplace question is:

What needs to change around the work so people can carry out their new responsibilities?

Answering it can show why employee development, workflow design, and organizational decisions need to move together.

The same situation can reveal three different decisions

Because the 3Ws describe connected parts of the same organization, a change under one lens can create a decision under another. In the onboarding example, changing preparation affects the specialist’s contribution, which in turn depends on access to source information and authority to act.

A leadership discussion could capture those relationships like this:

Looking across the lenses may also reveal uneven progress: the tasks have changed, while role expectations remain unresolved; or employees have developed the capability to make a decision, while the systems and approval paths still limit what they can do.

Describing that difference gives leaders a clearer account of where the change is happening and what deserves attention next.

How these moving pieces develop over time

The 3Ws can also help you discuss how the organization is developing. You might begin with scattered AI activity, establish a shared business direction, involve employees in designing new work, and then examine how those designs hold up in everyday practice.

Over time, the question becomes whether internal teams can lead further redesign and carry what they have learned into other work.

The important relationship to examine is how the Ws develop together. A team may be using a redesigned workflow while employees are still working out their contribution and leaders are still adjusting the conditions around them. Their next decision would reflect that situation, rather than an assumption that the whole organization has reached the same point.

A conversation to try with your leadership team

To make the model useful in your organization, you could bring it to a business problem that matters across teams, such as a customer handoff, an escalation, or a decision that keeps returning for clarification.

A work sample gives the discussion a common reference point, while the people who do the work can explain details that a process owner or manager may see differently.

Including relevant process and systems owners gives you a route from understanding the problem to addressing the conditions around it. For each W, the group could record:

• What has changed, supported by a specific example.

• What remains unresolved, including the employee’s experience.

• Which decision needs attention and who can help make it.

The 3W discussion worksheet below provides a place to capture those answers. My preference is to leave with one decision that connects the business problem to people’s ability to contribute, whether that means revising the handoff, clarifying a responsibility, or providing access to the context a person needs. The group can then choose what evidence to examine when it revisits the decision.

Subscribe to access worksheet.

You would have a more specific answer the next time someone asks what AI is changing: this is how the work is being redesigned, this is what people are being asked to contribute, and these are the conditions the organization needs to address.

Where does your organization need that explanation most?

If you’re helping people use AI and need a clearer account of what the work is becoming, subscribe to Work Redesigned for practical ways to connect business decisions, employee contribution, and the conditions around the work.

Then a peer asks the awkward question.

Would you call your company “AI-enabled”?

You get quiet because you know that pilot volume and organizational capability are two different things. A company can run experiment after experiment, collect a shelf full of demos, and still lack the ability to turn any of them into dependable operations, changed work, or new value.

That is dabbling at scale.

Subscribe now

Pilots matter. They create evidence, expose limitations, and give people somewhere concrete to begin. Yet a growing pilot count can also become a flattering measure of activity, especially when nobody asks which experiments have moved into ordinary operations or what the organization can now do that it could not do before.

The stronger question is no longer “How many things are we piloting?”

It is this:

What are we moving beyond the pilot, and how is it changing the organization?

Pilot volume tells you that people are experimenting

Experimentation is healthy. It gives teams room to learn before the stakes rise, and it can reveal which ideas deserve a larger commitment.

An organization can accumulate experiments the way a restaurant tests recipes that never reach the menu: lots of creative motion, little evidence of repeatable delivery. At some point, the evidence has to travel. A useful system must survive ordinary demand, become part of the way work happens, and generate learning that shapes the next decision.

Many portfolios never make that turn.

One team proves that an assistant can reduce drafting time, so another team launches a similar pilot. A third tests a different tool against the same task. Six months later, the company has more activity, more subscriptions, and more people who can describe what AI might do. It still cannot show which workflow changed, who owns the operating result, what managers now evaluate differently, or where the next source of value will come from.

We have plenty of use cases.

We have several good demos.

We are learning a lot.

So why does the organization still work the same way?

That private question is the center of the problem.

Subscribe now

An AI-enabled organization can repeat the whole move

For this piece, I am using AI-enabled in a precise, operational sense.

An AI-enabled organization can repeatedly turn experiments into dependable operations, integrate what works into real workflows and decisions, and use what it learns to create new capabilities and sources of value.

One successful pilot does not establish that capacity. Neither do twenty.

The definition raises the bar deliberately because isolated success is easy to misread. A skilled team, a carefully selected use case, a supportive sponsor, and clean pilot data can produce an impressive result. The organizational test begins when the protected conditions disappear and the work has to survive normal volume, competing priorities, messy handoffs, manager judgment, policy constraints, employee questions, and the departure of the person who championed it.

1. Can the organization carry the result then?

2. Can it do so again in another part of the business?

3. Can the learning change what the organization chooses to pursue next?

Those questions move the conversation from pilot success to organizational capability.

Implementation, integration, and innovation reveal what is missing

The distinction that helps here comes from the 3i model created by Paul McDonagh-Smith at MIT Sloan. The model separates implementation, integration, and innovation, while treating them as interdependent capabilities in a recurring system.

Implementation asks, “Can we make this work reliably?”

This is the move from a controlled experiment to an operating system people can depend on. Measures, data, technical infrastructure, governance, review, fallback, staged deployment, and ongoing ownership all matter because a demo can succeed without any of them being settled.

Integration asks, “Can this become part of how work gets done?”

Deployment puts a system into use. Integration changes the surrounding work: workflows, decisions, handoffs, roles, manager expectations, employee responsibilities, business measures, and feedback. When a system performs well inside one team while the organization around it carries on unchanged, the company has deployed AI without becoming more capable at integrating it.

Innovation asks, “What becomes possible now?”

Efficiency projects improve existing work, sometimes substantially. Innovation uses what the organization has learned to question the inherited task, service, decision, or operating model. It asks whether AI can create a capability the company did not have, serve a customer differently, or open a source of value that cannot be described as doing the same work faster.

This is where many portfolios reveal their smallest ambition. They contain dozens of ideas, all pointed at efficiency.

Leave a comment

Efficiency is useful, and it is a narrow destination

A faster summary can matter. So can shorter cycle time, less rework, better routing, or a reduction in repetitive effort. Organizations should capture those gains when the evidence supports them.

Efficiency, useful as it may be, leaves the basic shape of the work intact.

The same report gets written faster. The same request moves through the same departments. The same service reaches the same customer through the same operating model. The organization has improved an activity, which may be worth funding, while its deeper capabilities remain unchanged.

An AI-enabled organization also asks what the improvement teaches.

Faster case summaries may reveal patterns that allow earlier customer intervention; an assistant that improves proposal drafting could expose a better way to bring expertise into the sales process; better forecasting might move decisions closer to the front line. Few initiatives need a dramatic future story. The portfolio simply needs enough room to keep efficiency from becoming the ceiling because it happens to be easiest to measure.

If every item in the portfolio promises time savings, the organization has built an efficiency portfolio. It has not yet demonstrated an innovation capability.

The three capabilities move in a cycle

Implementation, integration, and innovation may look like three stages on a slide, but the useful picture is a recurring loop.

Implementation creates evidence because real operation reveals what a controlled test cannot. Integration carries that evidence into workflows, roles, decisions, and management practice, where more learning appears. Innovation turns the accumulated learning toward possibilities that were difficult to imagine when the organization only knew the technology in the abstract.

Then the cycle returns.

A promising innovation still has to operate reliably. It still needs a place in the work. It still needs ownership, governance, measures, feedback, and a decision about whether the value justifies a wider commitment.

That repetition is the capability. An AI-enabled organization can move around the loop again and again, rather than treating each pilot as a fresh adventure with a new team, a new vocabulary, and no inheritance from the last one.

Subscribe now

The symptoms tell you where to look

Imagine a hypothetical customer-support team testing AI-generated case summaries.

During the trial, the selected summaries are accurate and reviewers approve the quality. Then peak volume arrives, the data connection becomes unreliable, nobody owns the fallback, and recurring quality checks still depend on the person who ran the pilot.

The idea may be sound. The organization still has implementation work to finish.

Now imagine that the system performs reliably for Support. Product could use the summaries, yet the format does not fit its decisions. Support managers have changed their review process, while Product and Customer Success still rely on the old handoff. Employees received tool training, although nobody clarified the responsibilities created around the new workflow.

The system works. Integration is the constraint.

Change the scenario once more. The organization uses AI only to produce the same summaries faster, and nobody examines whether the information could support better routing, earlier intervention, a different customer experience, or a new service.

The company has found efficiency. Innovation remains mostly untouched.

These are diagnostic hypotheses, so the evidence still matters. Weak data, unclear incentives, an unimportant business problem, overloaded managers, or a fragile vendor can create similar symptoms. The distinction helps the leadership team investigate the right problem instead of prescribing another pilot before it understands the blockage.

Share Work Redesigned w/ Keith Anderson

A busy portfolio can hide organizational dabbling

Most companies have more AI work in motion than any one leader can name from memory. One production system sits beside several team experiments, shared data work, an agent concept, and a collection of vendor contracts that Finance can see by cost center but not by the business decision each one supports.

Put the initiatives in one view and the imbalance becomes easier to see.

A company may be strong at implementation and weak at integration, which leaves dependable systems trapped inside local workflows. Another may invest heavily in communication and training around tools that still lack operating evidence. A third may fund future concepts while current systems continue to struggle with ownership, data, review, and ordinary use.

Then there is the most common imbalance: a large portfolio of incremental efficiency work with almost no protected exploration of new value.

Balance does not require equal spending across the three capabilities. No evidence-backed universal ratio exists. It requires a portfolio whose actual investments match the organization’s stated ambition.

If leadership says AI will create new products, services, or operating possibilities, someone should be able to point to the work where those possibilities are being explored. If the entire portfolio ends at time saved, the strategy and the investment tell different stories.

Leave a comment

Organizational learning determines whether one pilot helps the next

Even a stopped pilot can leave the organization more capable, provided the learning survives the people who produced it.

The team closest to the work discovers where the data fails, which outputs earn trust, what reviewers miss, which exceptions matter, and how the workflow needs to change. If those lessons remain in a meeting, a deck, or one person’s memory, the next team starts over and calls the repetition exploration.

A 2024 MIT Sloan Management Review and Boston Consulting Group study surveyed 3,467 respondents across more than 21 industries and 136 countries, supplemented by nine executive interviews. Fifteen percent reported both strong organizational learning and strong AI-specific learning, and that group also reported more AI value than respondents who reported low levels of both.

Because the study is cross-sectional and self-reported, it shows an association rather than proving that learning practices caused the reported value. Its practical challenge is still useful: what does the organization retain after an initiative produces evidence?

A retained lesson can change the next project’s selection criteria, data plan, review standard, workflow design, manager practice, or investment decision. Once that happens, one pilot has started building an organizational capability instead of becoming another completed experiment.

Ask whether the portfolio is building an AI-enabled organization

The companion tool for this piece, From Pilot to Possibility: An AI Progress Portfolio Diagnostic, is designed for that conversation.

It asks leaders to inventory current initiatives, separate observed evidence from confident impressions, identify whether implementation, integration, or innovation is constraining the next decision, and choose one move that can produce useful evidence within 30 days.

Subscribe to access the diagnostic.

Subscribe now

The diagnostic will not tell every organization to stop piloting. Some questions deserve another bounded experiment. Others already have enough technical evidence, and the neglected work sits in workflows, roles, manager practice, governance, or ownership. A portfolio may also reveal a deeper issue: everything is aimed at making current work more efficient, while almost nothing is building the organization’s capacity to create new value.

So return to the question that made the room quiet.

Would you call your organization AI-enabled?

Count the pilots if you want. Then look for stronger evidence: dependable operations, changed work, retained learning, and new capabilities that the organization can create repeatedly rather than accidentally.

If your company has plenty of AI activity and still struggles to answer what has moved beyond the pilot, subscribe to the Work Redesigned Lab for practical diagnostics you can use with the people who own the work.

Sources

1. Paul McDonagh-Smith, “Creating value with AI,” MIT Sloan, *AI Adoption: Driving Business Value and Impact*.

2. Sam Ransbotham, David Kiron, Shervin Khodabandeh, Michael Chu, and Leonid Zhukhov, “Learning to Manage Uncertainty, With AI,” MIT Sloan Management Review and Boston Consulting Group, November 2024. Global spring 2024 survey of 3,467 respondents across more than 21 industries and 136 countries, plus nine executive interviews.

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.