Marcus Adeyemi manages a 12-person support operations group at a mid-size insurance company. He was the first manager in the building to put an AI assistant in front of his team, and for a while he felt like a pioneer. Then one Thursday his director forwarded him an email thread: the sales team had quietly bought a different AI writing tool, marketing was piloting a third one, and finance had built its own little reporting bot. Nobody was talking to anybody. Three teams, three tools, three sets of rules about what was even allowed. "We didn't have an AI strategy," Marcus said later. "We had four accidents happening at the same time." This lesson is about what he did next: moving from running AI well inside one team to coordinating it across several.

What This Lesson Covers

Coordinating AI use across teams means getting separate groups (sales, support, marketing, finance, and the rest) to align on tools, standards, and shared learning, without forcing every team into an identical box. The goal is not control for its own sake. The goal is to stop the predictable problems that show up when each team adopts AI in isolation, and to capture the gains that only appear when teams pull together.

This is team-level and cross-department coordination work, not org-wide strategy. You are not writing the company's AI vision statement. You are making sure the handful of teams you touch do not trip over each other. We will cover the specific problems that silos create, the mechanisms you use to coordinate, a simple ladder of coordination levels so you do not over-engineer it, three worked situations Marcus actually faced, and the traps that turn coordination into bureaucracy.

Why Independent Adoption Quietly Hurts

When every team adopts AI on its own, the damage is rarely dramatic. It accumulates. Marcus mapped what was happening across his building and found five distinct problems.

• Tool proliferation. Sales picked one tool, support another, marketing a third. None of them integrated. The company was paying three separate per-seat fees for what was largely the same writing capability.
• Inconsistent practices. One team reviewed every customer-facing AI draft before it went out. Another almost never did. A customer who dealt with both teams saw two different levels of care from the same company.
• Duplicated effort. Marcus's team spent two weeks building a prompt that produced clean ticket summaries. Marketing, three floors up, spent the same two weeks solving an almost identical problem. Neither knew the other existed.
• No shared learning. When support discovered that the AI was inventing policy numbers, that hard-won lesson stayed inside support. Sales hit the same wall months later.
• A governance blind spot. Nobody could answer a simple question from Legal: which teams are using AI, on what data, with what safeguards? "I'm not sure" is not an acceptable answer when a regulator asks.

Flip each of those around and you have the case for coordination: shared tools give you a better negotiating position and easier integration, shared learning speeds up everyone's problem-solving, consistent standards protect quality and fairness, and clear governance means you can actually answer Legal's question.

The Real Tensions You Are Managing

Coordination is not just a checklist. It is a balancing act, because teams genuinely differ.

They have different needs. Sales wants AI for proposal writing. Support wants it for categorizing tickets. Finance wants it for pulling together reports. One tool and one standard will not fit all three cleanly. They have different maturity. Marcus's team was a year into daily AI use; finance had touched it for two weeks. Coordination has to support the beginner and the veteran in the same room.

And the deepest tension is autonomy versus alignment. Every team lead wants the freedom to solve their own problems their own way. But the organization needs some shared floor on safety, quality, and governance. The skill is knowing which decisions to centralize (the safety floor) and which to leave local (how each team actually uses the tool day to day). Get that wrong in either direction and you either create a bureaucracy that teams route around, or a free-for-all that lands you back in the four-accidents situation.

The Mechanisms You Actually Use

Coordination happens through a small number of concrete mechanisms. You will not need all of them at once. Pick the ones that solve a problem you actually have.

A standard tool stack. Decide which tools are approved for which functions, negotiate enterprise pricing once instead of five times, and make sure the tools integrate with the systems teams already use. One good writing platform that ten people share beats five separate subscriptions.

Shared standards. A short, written floor for quality (what acceptable AI output looks like), fairness (how to check for biased treatment of different customer groups), and disclosure (when and how you tell a customer AI was involved). Standards do not have to be long. They have to be agreed and known.

A community of practice. A regular, low-ceremony meeting where the AI leads from each team trade what they have learned. "Here is the prompt that finally stopped the model inventing policy numbers." "Here is how we caught a bias pattern." This is where collective intelligence actually lives.

Shared training and documentation. One prompt-engineering workshop the whole company can attend beats every team reinventing onboarding. One shared troubleshooting guide beats five private ones.

Governance and oversight. Clear answers to who approves a new tool, how you assess its risk, how you track what is in use, and what triggers a review. This is the part that lets you sleep when Legal calls.

A Ladder of Coordination Levels

Marcus's instinct was to build a full governance committee overnight. That would have been a mistake. Coordination comes in increasing intensities, and you climb the ladder only as far as your real problems demand.

• Level 1: Information sharing. Teams simply tell each other what they are doing with AI. Almost no overhead, and it already prevents nasty surprises and seeds some learning.
• Level 2: Alignment on standards. The organization sets a shared floor on quality, fairness, and disclosure; each team implements it in its own context. This is the sweet spot for most managers, balancing central guidance with local freedom.
• Level 3: Shared tools and platforms. The organization negotiates and deploys common tools so teams use the same platform where it makes sense, which unlocks integration and shared learning.
• Level 4: Integrated strategy. AI becomes part of how functions connect (the support AI feeds insight to sales, the sales AI connects to the CRM) and leaders make deliberate choices about where AI creates the most value.

Level 4 is where the topic starts drifting up toward the C-suite. As a manager, you mostly live at Levels 1 through 3, and your job is to push your corner of the organization up one rung at a time, not to leap to the top. Marcus realized he had been at Level 0 (pure chaos) and that his honest near-term target was Level 2.

Worked Situation: Aligning Sales and Support

Marcus started where the pain was sharpest: his own support team and the sales team next door. He ran a quick assessment and wrote down what each was doing. Sales was using an AI assistant for proposal drafting, and roughly 85% of proposals now went out with AI help. His support team was using a categorization model for ticket routing, and about 60% of tickets were auto-categorized. The two teams had never compared notes.

He did not try to merge their tools. The needs were genuinely different, so forcing one tool would have helped no one. Instead he aligned the things that should be common and left the rest alone:

• A monthly 45-minute cross-team sync. Just the two leads plus their AI champions, focused on "what is working, what broke, what did we learn."
• One shared quality standard. Both teams agreed that any AI output going to a customer gets a human review first. Same floor, different workflows.
• Shared learning. When support cracked the invented-policy-number problem, the fix went straight to sales. When sales found a prompt that produced cleaner objection-handling, support borrowed it.
• An integration point. If a proposal surfaced a recurring technical question, sales flagged it to support. If support saw a feature confusing customers, they flagged it to sales so the proposal language could change.

The result was modest and real. The tools stayed separate. The standards converged. Learning that used to take months to cross the hallway now took a month. And for the first time, Marcus's director could see what AI was actually doing in both teams.

Worked Situation: Taming Tool Selection

The second problem was the four-accidents problem itself: multiple teams reaching for different tools with no shared process. Here Marcus deliberately climbed to a more formal mechanism, because the cost (paying several times over and risking an integration mess) justified it.

He helped stand up a small tool evaluation group with one representative each from sales, support, marketing, product, IT, and Legal. They agreed on five evaluation criteria: capability, security, cost, integration, and compliance. Then they assessed what every team actually needed and looked for overlap. The big finding was unsurprising in hindsight: four teams all needed general writing assistance. That was one common need masquerading as four separate purchases.

They produced a short approved-tools list (one recommended tool per function, plus a lightweight path for genuinely specialized needs), and IT negotiated a single enterprise agreement for the writing tool. The volume commitment cut the per-seat cost meaningfully versus the scattered subscriptions, and it came with proper privacy controls and a support contact. A quarterly review keeps the list honest: are these still the right tools, and should anything be added or dropped?

Worked Situation: Writing Shared Standards With RACI

The third problem was inconsistency: one team reviewing everything, another reviewing almost nothing, no agreement on disclosure. Marcus convened the AI leads and drafted a short standard together rather than handing one down. The heart of it was a tiered quality rule that respected risk levels:

• Customer-facing output: always reviewed by a human, every time, no exceptions.
• Internal analysis: spot-checked, roughly 10% to 20% of output reviewed for sound reasoning.
• Brainstorming and rough research: minimal review, used internally only, with the team responsible for validating before acting.

The first time the group tried to implement this, it stalled. Everyone nodded at the standard, but nobody knew who was actually on the hook for each part, so nothing happened. Marcus fixed it by laying a RACI matrix over the standard. RACI assigns four roles to each activity: Responsible (the person who does the work), Accountable (the single person who owns the outcome and signs off), Consulted (people whose input is sought), and Informed (people kept in the loop). Critically, exactly one person is Accountable for each row, which is what kills the "I thought you had it" problem.

Here is the slice that unblocked them:

• Review customer-facing AI output. Responsible: the team member who created it. Accountable: the team lead. Consulted: Legal, for anything touching policy language. Informed: the AI coordination group.
• Monitor for bias and report it. Responsible: each team's AI champion. Accountable: Marcus, as the coordination lead. Consulted: Legal and HR. Informed: all team leads.
• Approve a new AI tool. Responsible: the evaluation group. Accountable: the IT director. Consulted: the requesting team and Legal. Informed: everyone.

The moment each row had a single accountable name, the standard stopped being a document and started being behavior. The disclosure rule (be transparent if a customer asks whether AI was involved) and the accountability rule (the human using AI owns the decision, the AI does not absorb responsibility) rounded it out.

Traps That Turn Coordination Into Friction

Marcus nearly fell into several of these, and naming them is the best defense.

Let every team do its own thing. This is the silo problem you started with: sprawl, inconsistency, governance gaps. The fix is to coordinate on tools and standards while leaving implementation local.

One tool fits all. The opposite overreach. Mandating a single tool for every use ignores that support and finance have real, different needs. Teams quietly work around the mandate, and the mandate fails. Provide core tools for common needs and flexibility for specialized ones.

Governance without support. If you publish standards but give teams no training, templates, or help, the standards feel like bureaucracy and breed resentment. Every standard ships with the support to meet it.

No escalation path. If a team hits a bias problem and has no idea who to tell, the problem festers. Make escalation explicit: "If you see biased output, report it here, today."

Overhead without benefit. If a coordination meeting stops producing clarity and becomes status theater, it has failed. Marcus's own rule: every coordination mechanism has to solve a real problem (avoid duplication, share learning, ensure quality). If it does not, change it or kill it.

Keeping Your Own Judgment in the Loop

Coordination has a gravitational pull toward more process. Marcus set himself a few honest checkpoints to push back against it. Are you over-coordinating, paying overhead that no team actually values? Are you creating bureaucracy, where teams feel they need permission before trying anything? Are you still leaving room for local context, or has central guidance hardened into a straitjacket? Is learning genuinely happening in the community of practice, or are those just meetings? And the anchor question: what real problem is each mechanism solving? If you cannot name it, you do not need the mechanism.

One more responsibility belongs squarely to you and cannot be automated: fairness monitoring at scale. Coordinating across teams is a rare chance to spot bias patterns that no single team would see alone. Require teams to monitor and report, then aggregate the reports to catch organization-wide patterns. That is coordination earning its keep.

Practice and Reflection

Marcus started with a map, not a committee, and that order matters. Work through these five exercises in sequence, documenting each one, and you will end up with a coordination approach that fits the problems you actually have rather than the ones you imagine.

• Map AI use across your organization. List every team that is using AI or planning to. For each, write down what they are doing with it and which tools they use. Then look for the patterns Marcus found: where do capabilities overlap, where is effort being duplicated, where are there integration opportunities nobody has noticed, and what coordination problems already exist? The map is the deliverable, and it is usually uncomfortable reading.
• Design your coordination approach. Decide which level on the ladder is honestly appropriate for you right now: information sharing, alignment on standards, shared tools and platforms, or integrated strategy. Then specify which mechanisms would help, who needs to be involved, and what the governance process looks like. Write it down as a short document rather than carrying it in your head.
• Draft your shared standards. Pick the areas where consistency genuinely matters and write a first draft for each: what counts as acceptable AI output, how teams check for bias, when and how you disclose AI use to customers, and how decisions about AI use get made. Keep it short. A standard nobody can remember is not a standard.
• Plan a community of practice. Design the cross-team learning forum: who should be in the room, how often it meets, what it discusses, and how what gets learned there actually reaches people who were not present. Marcus's monthly sync worked because it had a narrow focus and a low ceremony, not because it was ambitious.
• Assess your coordination maturity. Place your organization honestly on the spectrum from no coordination at all, through information sharing, standards alignment, and shared platforms, to integrated strategy. Marcus put himself below the bottom rung. Then answer two more questions: where do you want to be, and what is the realistic path from here to there?

Related Lessons

Coordination work sits between the team you run and the organization you sit inside, so it connects in both directions.

• Stakeholder Communication About AI covers how you explain all of this to the people whose support you need. A coordination approach that nobody outside the working group understands will not survive its first budget cycle.
• Navigating Organizational AI Governance goes deeper on the governance layer this lesson only touched. When your coordination work runs into formal approval processes, risk assessment, and policy, that lesson is where the detail lives.
• Managing AI Tool Proliferation Across Teams takes the tool sprawl problem that started Marcus's story and treats it in its own right, including how to consolidate a stack that has already scattered.

Key Takeaways

• Independent adoption quietly costs you. Silos produce tool sprawl, inconsistent quality, duplicated effort, lost learning, and a governance blind spot. Coordination exists to stop those specific, predictable problems.
• Climb the coordination ladder one rung at a time. Information sharing, then shared standards, then shared tools, then integrated strategy. Most managers should aim for shared standards and only climb higher when a real problem demands it.
• Align standards, not necessarily tools. Different teams have genuinely different needs. Force a common quality, fairness, and disclosure floor while letting each team keep the tool and workflow that fits its work.
• Use RACI to make standards real. A standard with no single accountable owner per activity is just a document. Naming one Accountable person per row is what turns agreement into behavior.
• Buy once, not five times. A shared tool evaluation and a single enterprise agreement cut cost, improve integration, and give you the governance visibility that scattered subscriptions destroy.
• Pair every standard with support. Governance without training, templates, and a clear escalation path breeds resentment and quiet non-compliance.
• Coordination must enable speed, not consume it. If a mechanism stops solving a real problem, change it or kill it. Status theater is worse than no meeting at all.