How to get your whole organization to adopt AI

Getting an entire organization to adopt AI means making it useful in the work each team already owns. Set a shared direction, choose workflows for each department, give people time to practice, and measure complete results. Leaders need to participate, while teams need clear ownership, reliable context, and a way to challenge the output.

I've helped organizations adopt AI across support, engineering, leadership, and GTM. That broader scope matters. A company can have enthusiastic individual users while its customer handoffs, planning process, and delivery bottlenecks stay exactly as they were.

The goal is for useful practices to become part of how the business runs. Getting there takes strategy, implementation, and sustained work with the people whose jobs are changing.

What should organization-wide AI adoption achieve?

Start with the business problems people recognize. Support may spend too much time reconstructing customer history. Engineers may receive incomplete bug reports. Managers may spend hours assembling updates that arrive too late to inform a decision.

Write down the improvement you want: less time finding context, better first drafts, faster resolution, or clearer decisions. Then identify who benefits and how you would know the work improved.

Give the organization a clear position on where AI fits, which tools and data uses are approved, and how people can get help. DORA's guidance on a clear and communicated AI stance emphasizes that teams need to understand expectations, permissions, and support in terms that apply to their roles.

A shared direction leaves room for different implementations. A support agent, an engineer, and a CEO have different tasks and different ways to judge a useful result. They do not need identical tools or the same rollout schedule.

Find a useful starting point in each department

Talk to the people doing the work before selecting a platform. Ask them to walk through a recent task: where the information came from, what they had to reconstruct, who reviewed it, and what happened next. Include experienced people, newer colleagues, and people who are skeptical of AI.

Look for recurring work with accessible inputs and an output someone can evaluate. These are proposed starting points, to be tested against the organization's actual needs:

Map opportunities across the business, then choose a small number of pilots the team can support. A small company might start with one workflow that crosses two departments. A larger organization might run several pilots with shared evaluation standards. The aim is to learn what works before making a larger commitment.

For a specific GTM example, my article on choosing the workflow before building the agent covers how to define a useful output and its review process.

Leadership has to participate in the work

Executive sponsorship needs to show up in decisions about time, priorities, and resources. If a team is expected to learn a new workflow, its manager should make room for that work. Someone also needs authority to resolve access problems, fund useful tooling, and stop pilots that are going nowhere.

Leaders should use an appropriate workflow themselves. A reviewed decision brief is a useful example: inspect the sources, question the assumptions, and show where the draft needed correction. That makes the standard visible. People can see that judgment and verification remain part of the job.

Be candid about what adoption means for roles. Explain what has been decided, what remains uncertain, and how changes will be discussed. Involve the people team where job design, training, or performance expectations are changing. Promising that nothing will change is hard to reconcile with asking people to work differently.

Managers also need to recognize useful contributions: improving a shared workflow, documenting a failure, or helping a colleague learn. A target for daily AI usage can encourage activity without showing whether the work got better.

Teach people through their own work

A general introduction can help people get started. Follow it with practice on tasks they actually handle. A support agent needs to learn when a suggested answer is missing customer context. An engineer needs to evaluate a proposed change against the codebase and tests. A leader needs to spot an unsupported conclusion in a polished summary.

Work through a good example and a difficult one together. Show the source material, the AI's contribution, the review, and the final result. Include cases where the right decision is to reject the output or finish the work manually.

Research gives a reason to avoid assuming everyone benefits in the same way. A 2025 study in the Quarterly Journal of Economics examined 5,172 customer-support agents and found a 15% average increase in issues resolved per hour with AI assistance. Benefits varied substantially with experience and skill; the most experienced, highest-skilled agents saw small speed gains and small quality declines. This was one company's support setting, not a forecast for every team.

Give people recurring opportunities to practice and ask questions. That might mean short team sessions, office hours, and a colleague who can help with the actual workflow. Give that colleague time and recognition for the work. Training should become easier to access as adoption grows.

Connect the handoffs between departments

Some of the most useful opportunities sit between teams. Consider this illustrative customer-issue workflow:

1. Support prepares the context. AI helps organize the conversation, relevant documentation, and troubleshooting already attempted. The agent checks the summary.
2. Engineering receives a useful escalation. A draft issue includes evidence, reproduction details, and open questions. An engineer confirms the problem and decides what to investigate.
3. Leadership sees patterns. Reviewed issue summaries help show recurring friction and its customer impact. Leaders weigh that evidence alongside delivery capacity and other priorities.
4. The customer gets a clear follow-up. The account or support owner reviews a draft based on the verified resolution. Product and marketing can use approved learning to improve documentation and messaging.

This is a proposed design, not a client case study. Its value would need to be demonstrated in use. A faster summary is only helpful if the next person gets accurate information and can act on it.

Keep the underlying records identifiable and respect access permissions at every handoff. A leadership summary does not require distributing every private support conversation. Agree who maintains the source material and how corrections travel back through the workflow.

Give each workflow an owner and clear boundaries

Each pilot needs a business owner who is responsible for its usefulness and a person who maintains its implementation. They may be the same person in a small team. Include IT, security, and other relevant functions early enough to resolve practical questions before people build habits around the workflow.

Write a short operating guide that answers:

• What task does this workflow handle, and where does it stop?
• Which tools, information sources, and data uses are approved?
• Who checks the result before it reaches a customer, changes a system, or informs a decision?
• Where do people report an error or request a change?
• Who can pause it, and how does the team complete the task without it?

The amount of review should reflect the consequences of getting the task wrong. Drafting an internal outline and changing a production system require different controls.

NIST's voluntary AI Risk Management Framework Playbook offers a broader structure for governing, mapping, measuring, and managing AI risk. Use the guidance that fits the work, and translate it into instructions people can follow during an ordinary day.

Measure the complete job

Tool access, training attendance, and repeat usage help show whether people are getting started. Pair them with measures of whether the work improves. Count preparation, review, corrections, and downstream effort when comparing the old process with the pilot.

Support might resolve a case faster but create more repeat contacts. Engineering might produce a change quickly while spending longer in review. Leadership might get a shorter report that omits an important uncertainty. Those outcomes need to be visible in the evaluation.

Take a representative sample before the pilot, including awkward cases. Compare similar work during the pilot and record where the cases differ. Look at results by task and experience level, and ask the people receiving the output whether it helps. Include running costs and the time needed to maintain the workflow.

DORA's 2025 software development research describes AI as amplifying existing organizational strengths and weaknesses. That is a useful reason to examine the whole delivery process: faster work in one step can expose a bottleneck in the next.

What could the first 90 days look like?

The following is a planning example, not a promised rollout schedule. Adjust the pace to the organization's size, data access, and ability to review the work.

1. Days 1–15: agree the direction and baseline. Interview people across functions, identify recurring friction, clarify approved uses, and select a few workflows. Name owners and record how the work happens today.
2. Days 16–45: build and practice. Run the workflows with the people who will use them. Provide role-specific training, collect corrections, and make review and support part of the routine.
3. Days 46–75: test the handoffs. Check whether downstream teams benefit. Fix missing context and unclear responsibilities. Compare quality, effort, and outcomes with the baseline.
4. Days 76–90: make a decision. Expand useful workflows, revise the ones with a solvable problem, and stop those that do not justify their cost. Document ownership and make the working process part of onboarding.

Keep the wider organization involved through examples and feedback. Teams waiting for a later phase should know what is being tested, what has been learned, and how to suggest a useful next problem.

Make adoption something the team can sustain

When people avoid a workflow, investigate the reason. It may take too much review, lack essential context, or solve a problem they do not have. People may also be unclear about permission or concerned about how their work will be judged. Those are different problems and need different responses.

Keep a visible list of issues and improvements with named owners. Update examples and source material as the business changes. Recheck representative tasks when a model, integration, or important instruction changes. Make sure a new hire can learn the workflow without depending on the person who built it.

To start, ask each function to bring one recurring task that creates avoidable effort and one example of what a good result looks like. Bring those people together, choose a manageable pilot, and agree who will judge the outcome.

That is the work behind my approach to AI adoption and workflows across the organization: connect strategy to implementation, help people use what gets built, and leave the team able to run and improve it.