Mary Fung

The scarce thing is not access to tools. It is the ability to turn cheap output into useful work, shipped systems, and better judgment.

Most companies are still asking the wrong AI question.

They are asking how to get employees to use AI. The better question is how to build a team that can turn AI into useful, shipped, trusted work.

That difference sounds small until the first wave of adoption lands. Access to tools creates activity. It creates drafts, summaries, mockups, prototypes, prompt libraries, internal demos, and a temporary feeling that the organization has become faster. Sometimes it has. Often it has only become louder.

The test is not whether the team can produce more ideas. AI has made ideas cheap enough that this is no longer a meaningful advantage. The test is whether the team can carry an idea through the messy middle: from problem to workflow, from workflow to system, from system to adoption, and from adoption to something the business can honestly say changed.

A demo is not transformation. A prototype is not a product. A prompt library is not an operating model. A hackathon is not a strategy.

The teams that win in the AI age will not be the ones with the longest tool list. They will be the ones with the highest agency, the clearest standards, the best judgment, and the discipline to stop work that no longer earns its place.

Draft chapter index

This is the review map for the full guide draft.

The real AI shift

AI is not just another productivity layer. It changes the cost of producing work.

Drafting got cheaper. Research got cheaper. Code generation got cheaper. Mockups got cheaper. Analysis got cheaper. The first version of almost anything got cheaper.

That does not mean the final version got easier.

When production was expensive, the bottleneck was often making the thing. Now the bottleneck is more often deciding what should exist, what is good enough to trust, what should be killed, and who is accountable when the polished answer is wrong.

This is why weak teams do not become strong teams because they adopt AI. AI does not remove the team's habits. It amplifies them.

A team with clear ownership, good taste, and a bias toward shipping can become much faster. A team that is passive, political, vague, or afraid of judgment can become a very efficient producer of plausible-looking work that nobody should use.

The real AI shift is not output. It is accountability under conditions where output has become abundant.

What an AI-enabled team actually is

An AI-enabled team is not a team where everyone has access to the same chat interface.

It is a team where AI has changed the way work moves.

Research starts with better questions and leaves a trail. Drafting becomes an iteration loop, not a blank-page event. Customer insights are synthesized faster, but still checked against reality. Code is generated with tests, reviews, and architecture in mind. Internal knowledge becomes easier to reuse. Meetings produce decisions instead of more documents describing the decision that still needs to be made.

The team does not ask, "What can we do with AI?" forever.

It asks better questions:

Where is work slow?
Where is quality inconsistent?
Where are experts becoming bottlenecks?
Where are customers confused?
Where are decisions delayed because context is scattered?
Where are people doing repetitive work that no longer deserves human time?
If this succeeds, what stops?

That last question matters. If nothing stops, the AI initiative is probably an addition story, not a strategy. The work becomes more expensive because the old process remains and the new tooling sits on top of it.

Useful AI enablement changes the work. It does not just decorate it.

High agency is no longer optional

High agency is often described as proactivity, but that is too soft.

High agency is the ability to move when the path is unclear. It is the habit of turning ambiguity into a next action without waiting for someone else to translate the work into a perfect set of instructions.

In the AI age, this matters because AI rewards people who can define the work. The tool can help draft, compare, summarize, code, critique, and simulate. It cannot rescue a person who does not know what they are trying to do.

The low-agency employee waits for the approved tool, the approved training, the approved use case, and the approved workflow. The high-agency employee starts with the work in front of them and asks where judgment, speed, quality, or reuse could improve.

Some agency is temperament. Some of it is trained. A team can build more of it by rewarding ownership, making decisions visible, giving people room to test, and refusing to treat passivity as harmless.

But there is a limit. You can train someone to use a tool. You cannot easily train someone to care about the outcome.

That is uncomfortable, and it is still true.

Developers may move up the business stack faster

One of the more interesting shifts is that AI may make it easier for developers to become business people than for business people to become developers.

This is not because developers are smarter. It is because software work already trains a person in systems, constraints, debugging, edge cases, dependency, architecture, and the difference between something that runs once and something that can be maintained.

AI gives those people a faster path into adjacent work: product framing, customer research, copy, market narrative, pricing logic, workflow design, and business analysis. They can move up the stack because they already understand that a nice-looking answer is not the same as a working system.

Business people also gain leverage. They can prototype, test messages, explore interfaces, draft workflows, and make ideas more concrete before involving an engineering team. That is a real change.

But AI does not give them engineering judgment by default. A generated prototype can hide architectural problems, security problems, data problems, and maintenance problems behind a clean interface. It can make a fragile thing feel real.

The winning profile is not "developer" or "business person." It is the business-minded builder: someone who can move between customer problem, technical constraint, product shape, narrative, and adoption without pretending any one of those lenses is the whole answer.

The end of single-lane work

AI increases the value of people who can borrow the lens of another discipline.

Not performatively. Not because everyone needs to become a designer, engineer, marketer, architect, copywriter, and educator at expert level. That is not the point.

The point is that AI makes it easier to produce work in a discipline you do not fully understand. That means it also becomes easier to produce shallow work in that discipline unless you know what good looks like.

An AI-enabled builder needs enough design sense to know whether the interface is usable. Enough copy sense to know whether the language creates trust. Enough storytelling sense to explain why the thing matters. Enough architecture sense to ask what breaks later. Enough backend sense to ask where the data lives. Enough frontend sense to notice friction. Enough marketing sense to know who would care. Enough education sense to help others adopt the thing after it is built.

This is not a call for generalists to replace specialists. Specialists still matter. Depth still matters. The difference is that the handoffs get tighter. The person who can see across the handoffs becomes more valuable because the work moves faster and the cost of shallow handoffs goes up.

The rare skill is not knowing every craft. It is knowing enough of each craft to recognize when the output is wrong.

From experiments to shipped value

AI teams can get stuck in experimentation because experimentation now feels productive.

There is always another tool to try, another agent to test, another workflow to map, another internal demo to show. None of these are bad. The problem is when the experiment becomes the product.

Every AI experiment should have an owner, a use case, a time box, a success metric, and a kill condition. If nobody can say what changes if the experiment works, it is probably curiosity with a meeting invite.

A useful experiment answers at least one of these questions:

Does this reduce time on a repeated workflow?
Does this improve the quality or consistency of an output?
Does this make a decision easier to trust?
Does this help customers, employees, or leaders understand something faster?
Does this remove work, not just add another step?
Can the pattern be reused by another team?

The discipline is not anti-experimentation. It is the only way experimentation becomes capability.

Shiny object syndrome is what happens when a team confuses motion with progress. AI makes motion cheaper. That means leaders have to become stricter about what counts as progress.

Culture without the poster language

Culture is not values on a slide.

Culture is what gets tolerated, rewarded, repeated, and promoted.

In AI work, that becomes very visible. If the culture rewards looking busy, AI will create more visible busyness. If the culture rewards polished decks, AI will create more polished decks. If the culture avoids hard calls, AI will generate more options so the hard call can be postponed with better formatting.

The useful culture is less sentimental.

It rewards people who share what they learned. It makes experiments visible without pretending every experiment matters. It lets people ask naive questions early. It separates psychological safety from low standards. It treats resistance as data, not disobedience. It makes quality review normal. It makes ownership explicit. It does not let "AI wrote it" become an excuse.

That is the culture that can absorb a powerful tool without losing its standards.

Motivation, standards, and ruthlessness

"How do we motivate people?" is sometimes the wrong question.

There are cases where people are blocked, unclear, scared, undertrained, or miscast. Those require management. They require clarity, coaching, better incentives, and a more honest conversation about what the work now requires.

There are also cases where people simply do not want to change how they work.

That should not be dressed up as an enablement problem forever.

Leaders need to distinguish between willingness and readiness. Readiness can be built. Willingness has to be present. A person can be behind on AI and still be valuable if they are learning quickly, asking good questions, and taking ownership. A person can know every tool and still be a liability if they hide behind output, avoid accountability, or keep shipping work nobody should trust.

The standard has to be protected. Not cruelly. Clearly.

An AI-enabled team needs patience for learning and very little patience for passivity disguised as caution.

Hiring for the AI age

"Knows AI tools" is a weak hiring signal.

Tools change too quickly, and many people can talk fluently about tools they have not used in serious work. The better signals are slower and more behavioral.

Look for agency. Can the person describe a time they made progress without a clear map?

Look for judgment. Can they compare two plausible outputs and explain which one is better?

Look for learning velocity. Can they show how their workflow changed over the last six months?

Look for taste across domains. Can they name bad work they have shipped and explain what was off?

Look for accountability. Do they own the result, or do they hide behind the process?

Look for translation. Can they explain a technical constraint in business language and a business requirement in technical language?

The best interview question may not be "What AI tools do you use?" It may be: "Show me a workflow you changed because AI made the old version unnecessary."

Assembling the team

The AI-enabled team needs a mix of depth and range.

It needs builders who can make things real. It needs operators who know where the work actually breaks. It needs designers who can make new workflows usable. It needs technical architects who can see what will fail later. It needs storytellers who can explain why the change matters. It needs domain experts who know what the tool is allowed to get wrong and what it cannot get wrong. It needs educators who can turn one person's experiment into a pattern other people can adopt.

On a small team, one person may cover several of these modes. That is fine. The important thing is not job titles. It is whether the team as a whole can move from idea to system to adoption.

If everyone is an idea person, nothing ships. If everyone is a builder, the team may build the wrong thing beautifully. If everyone is a strategist, the work may never survive contact with a real workflow.

The composition has to match the journey from spark to shipped value.

Managers have to change too

Managers cannot delegate AI judgment to their teams and call it empowerment.

They need enough fluency to set standards, evaluate outputs, recognize shallow work, and know which risks matter. They do not need to become the best prompt writer in the room. They do need to understand how the work is changing.

The manager's job is to make the operating system explicit:

Which workflows should use AI by default?
Which workflows require review?
What outputs are safe to share?
What counts as good enough?
What should be documented so others can reuse it?
What should be stopped if the AI-assisted version works?

Without that, AI use becomes hidden and uneven. The aggressive users run ahead. The cautious users wait. The team develops private workflows, inconsistent quality, and no shared learning.

The manager does not need to control every experiment. The manager does need to turn learning into a team asset.

Operating rhythm

AI enablement needs a cadence.

Not a theater cadence. A working cadence.

A team can start with a simple rhythm:

Review one workflow each week.
Name the slowest, most repetitive, or most error-prone part.
Run one small AI-assisted experiment against it.
Decide whether to adopt, adapt, or kill it.
Publish the useful pattern back to the team.
Name what stops if the new workflow works.

The artifact matters. If the learning only lives in one person's head, the team has not built capability. It has built a local trick.

The goal is not to centralize every prompt or standardize every workflow too early. The goal is to make learning visible enough that good patterns spread and bad patterns die before they become process.

Measuring progress

The easiest AI metrics are often the least useful.

Number of tools used. Number of prompts written. Number of experiments run. Number of employees trained. Number of demos shown.

These are activity metrics. They may be useful for administration. They are not evidence that the team is getting better.

Better measures are closer to the work:

Did cycle time improve?
Did quality become more consistent?
Did the team retire a workflow, vendor, meeting, or manual step?
Did decisions move faster with the same or better confidence?
Did customers or employees experience less friction?
Did the same team ship more without lowering the standard?
Did the organization reuse a pattern instead of rebuilding it from scratch?

AI progress should eventually show up as changed work, not only increased activity.

Failure modes

Most AI-enabled teams fail in predictable ways.

They collect tools instead of changing workflows. They confuse prototypes with products. They let prompt libraries become a substitute for judgment. They accept polished output without enough review. They allow every experiment to survive because killing one would make the sponsor uncomfortable. They make AI strategy additive and never name what stops.

Another failure mode is quieter: the organization lets the most capable people become the only ones who can use the new leverage. Those people get faster, everyone else gets more dependent, and the team calls that transformation.

That is not transformation. That is a bottleneck with better tools.

The point of AI enablement is not to create a few heroes. It is to make the team's judgment, context, and reusable patterns stronger.

The employee playbook

For an individual employee, the safest career move is not to become a walking tool directory.

It is to become more useful in the parts of work AI makes more visible: framing, judgment, translation, quality control, adoption, and ownership.

Use AI to learn faster, but do not let it hide whether you understand the work. Use it to draft, but get better at editing. Use it to prototype, but learn why systems fail. Use it to analyze, but keep asking whether the question was the right one. Use it to produce more, but pay closer attention to what should not ship.

The employees who become more valuable will be the ones who can say: I changed how this work gets done, I made the pattern reusable, and I can explain why the new version is better.

The leader playbook

For leaders, the work is more structural.

Choose the first workflows carefully. Pick work that is frequent enough to matter, bounded enough to test, and painful enough that people will care if it improves.

Set the standard in plain language. What does good output look like? What requires review? What cannot be delegated? What data is allowed? What is the human still accountable for?

Create permission and pressure at the same time. Permission without pressure creates hobby projects. Pressure without permission creates hidden AI use and bad incentives.

Build internal champions, but do not let champions become the whole strategy. Their job is to transfer capability, not become a new dependency.

Most importantly, make subtraction part of the plan. If the AI-assisted workflow works, what stops? If the answer is nothing, the strategy is not finished.

Practical worksheets

The guide should probably become more than an essay. The useful version has artifacts attached to it:

An AI team readiness checklist.
A high-agency interview scorecard.
A shiny-object filter for AI experiments.
A workflow transformation canvas.
A build, buy, or ignore decision tree.
A team composition map.
A manager conversation guide.
An AI experiment review template.
A "what stops?" subtraction worksheet.

The worksheets matter because AI adoption fails when it stays abstract. A team does not need another slogan. It needs a better way to decide what to try, what to trust, what to kill, and what to teach the rest of the organization.

The closing argument

AI will not make every team great.

It will widen the gap between teams that can learn, judge, build, and ship and teams that can only produce more activity.

That gap will not be explained by tool access. It will be explained by agency, culture, standards, team composition, and whether leaders had the discipline to turn experiments into operating muscle.

The future does not belong to idea people. Ideas are cheaper now.

It belongs to teams that can make ideas real, useful, trusted, adopted, and eventually boring enough to become how the work gets done.

How to build a team that wins in the AI age