Naomi Adeyemi manages customer support at a mid-size fintech, and her counterpart Raj runs the sales team. Both adopted AI independently and both succeeded inside their own walls. Then a customer got a chatbot answer from support that flatly contradicted what sales had promised in a deal, because the two teams' AI tools drew on different, unsynced knowledge sources. The customer escalated. Naomi and Raj each blamed the other's bot. The real failure was that two locally optimized AI deployments had never been coordinated, and the seam between them was where the customer fell through. Cross-functional coordination is the work of managing those seams.

What This Lesson Covers

Cross-functional AI coordination is the practice of aligning how multiple teams use AI so their tools, data, and outputs reinforce each other instead of colliding at the boundaries. This is a peer-to-peer coordination challenge between team-level managers, distinct from top-down enterprise governance. Nobody is forcing Naomi and Raj to align; they have to choose to, and they have to organize how.

This lesson covers why locally optimized AI creates global problems, where the seams between teams actually break, how to use a RACI chart to assign ownership of shared AI workflows, how to run a lightweight coordination rhythm, and how to align on shared data and definitions so the bots stop contradicting each other. We follow Naomi and Raj from a finger-pointing escalation to a coordinated handoff.

It then widens out from two teams to the whole organization, because the problem Naomi and Raj hit is the small version of a problem that gets much more expensive at scale. You will learn when coordination is worth the effort and when it is not, the coordination roles you might find yourself occupying, how to build an inventory of what AI work is actually happening, how to spot the coordination opportunities that inventory reveals, how to build governance that enables rather than blocks, how to navigate priorities that genuinely conflict, what forums to run, and how to get tool proliferation under control before it calcifies.

Why Local Wins Create Global Problems

Naomi's support bot was excellent at its job. Raj's sales assistant was excellent at its job. The contradiction the customer hit was not a failure of either tool. It was a failure of coordination between them. Each team optimized for its own metric, and the place where their workflows touched was owned by no one.

This is the central trap of cross-functional AI. AI tools amplify whatever a team is already doing, including its isolation. A support team that drafts answers from one knowledge base and a sales team that promises from another will, at AI speed and volume, produce contradictions faster and at larger scale than they ever did manually. The tool did not cause the misalignment. It industrialized it.

AI does not create silos. It pours speed and volume into the ones you already have, until the cracks between teams become the customer's problem.

Finding the Seams Where Teams Break

Coordination starts with mapping where teams actually hand work to each other, because those handoffs are where AI misalignment hurts. Naomi and Raj walked the customer journey together and found three seams. The sales-to-support handoff, where a closed deal's commitments needed to reach support. The shared knowledge problem, where both bots needed the same source of truth on product capabilities and pricing. And the escalation path, where a bot in either team needed to know when and to whom to hand a human a problem.

The contradiction the customer hit lived in seam two: two bots, two unsynced knowledge sources, one inevitable collision. Naming the seams turned a vague "our AI tools don't play well together" into three specific, fixable interfaces. You cannot coordinate everything between two busy teams, but you can coordinate the three places where the work crosses.

Assigning Ownership With RACI

The reason the escalation became a blame fight is that no one owned the shared workflow. Naomi and Raj fixed this with a RACI chart for each seam, naming who is Responsible (does the work), Accountable (owns the outcome), Consulted (gives input), and Informed (kept in the loop).

For the shared product-and-pricing knowledge base, they decided product marketing was Responsible for keeping it current, Raj was Accountable for its accuracy because sales commitments depended on it most, and both Naomi and Raj were Consulted on changes, with both teams Informed when it updated. For the sales-to-support handoff, Raj's team was Responsible for passing deal commitments into the support system in a standard format, Naomi was Accountable for support honoring them, and the customer's account manager was Consulted on edge cases.

The single most important line was the one that ended the original fight: the shared knowledge base now had one Accountable owner. Before, both bots read from sources nobody owned, so contradictions were nobody's fault. After, when the bots disagreed, there was a named person responsible for reconciling the source. RACI does not do the coordination work; it ensures the coordination work has an owner.

A Lightweight Coordination Rhythm

Ownership without a rhythm decays. But Naomi and Raj also could not afford a heavy new standing committee between two teams that already had full calendars. They settled on a deliberately small cadence.

Monthly, a 30-minute cross-team sync where the two managers and one representative each reviewed how the shared seams were performing: any contradictions customers hit, any handoffs that dropped, any knowledge that drifted out of date. Quarterly, a slightly longer review to decide whether the coordination model itself needed to change as either team's AI use evolved. And between meetings, a shared channel where either team could flag a seam problem the moment it appeared, rather than letting it fester until the monthly sync.

The rhythm worked because it was scoped to the seams, not to everything. They did not coordinate how each team used AI internally, which would have been micromanagement across a boundary neither controlled. They coordinated only the interfaces, which is the minimum that prevents the customer-facing contradiction.

Aligning Shared Data and Definitions

The deepest fix was the least glamorous. Many cross-team AI contradictions trace back to teams meaning different things by the same word. Naomi's bot and Raj's bot disagreed partly because "active customer" meant one thing in the support system and another in the sales system, so the same person could be eligible for one offer and not another depending on which bot answered.

They reconciled the handful of definitions that crossed the seam: what counts as an active customer, what a given pricing tier includes, what is in scope for support versus billed as professional services. Then they pointed both bots at the same reconciled source for those facts. This is unglamorous data hygiene, but it is what actually stops the bots from contradicting each other, because two AI tools reading the same agreed facts cannot disagree about those facts. Alignment on shared meaning is the foundation the RACI chart and the rhythm sit on.

The Same Problem, Multiplied Across an Organization

Two teams is the easy version. Naomi got a preview of the hard version a month later, when her director asked her to look at document handling across the company. What she found is what most organizations find.

Finance had implemented an AI tool for invoice processing. Two months later procurement, with no idea that finance had solved a nearly identical problem, implemented a different tool for purchase order processing. Later still, supply chain implemented a third for contract analysis. Three tools, three vendors, three training approaches, three data integration points. The outputs from each looked different. The three managers had three different ideas about what AI quality assurance meant.

This is tool proliferation, the accumulation of multiple AI tools solving similar problems in incompatible ways. It creates operational friction, fragments knowledge, duplicates effort, and makes it much harder to build any organizational learning about AI, because every team's learning stays trapped in the context of its own tool. Coordination does not prevent this by eliminating all difference. Teams genuinely do have different needs, and different tools are sometimes right. What coordination does is ensure the right people know about each other's AI initiatives, which prevents duplication and surfaces the opportunities where standardizing would actually help.

The upside is compounding knowledge. When one team discovers a prompting technique that lifts output quality, every other team can have it. When one team finds that a vendor's support is unreliable, the others avoid the same six months of frustration. Naomi's two-team fix protected one customer journey. The organization-wide version protects everyone's learning.

When Coordination Is Worth It

Not everything needs coordinating, and a coordinator who tries to align everything becomes the bureaucrat everyone routes around. A single team using an AI tool for its own internal productivity, with no shared data and no shared interface, is genuinely isolated. Leave it alone. Four conditions are the ones that make coordination pay.

Shared problems. Multiple teams are trying to solve the same or a similar problem with AI. Coordinating prevents duplication and surfaces the best approach. Finance and HR both need to process documents; the case for comparing their approaches is obvious once you can see both.

Shared data. Multiple teams need access to the same data to feed their AI systems. If one team has already built a pipeline for customer data, the others should know it exists and consider using it rather than building a parallel one that will inevitably drift out of sync with the first.

Shared tools. Multiple teams want the same tool. Coordinating training, governance, and implementation across them multiplies the tool's value: one team using an assistant develops a handful of good practices, while ten teams using it can share learning ten times as fast.

Organizational scale. As adoption grows, the organization develops enterprise policies and standards around AI use, and teams have to comply. Coordination is how compliance happens without generating team-level resentment, because the teams help shape what they are complying with.

The Roles You Might Be Playing

When you coordinate across functions, you are usually occupying one of several recognizable roles, and knowing which one you are in tells you what tools you actually have.

The coordinator manager is the most common and the least formal. You are a manager coordinating AI work across peer teams with no authority over any of them. What you have instead is credibility, visibility, and relationships. You convene people, facilitate alignment, and move information between groups that would not otherwise talk. This is Naomi's role with Raj, and it is a role most managers back into rather than being appointed to, because they can see the inefficiency and recognize that alignment would help everyone. If that is you, lean into it. Formalize it a little. Create a regular forum. Build the peer relationships deliberately rather than incidentally.

The AI center of excellence leader exists where an organization has established a formal structure for AI practice. A center of excellence leader has explicit responsibility for governance, standards, and knowledge sharing across the organization. The job is to build systems that coordinate adoption without becoming barriers to it, which means constantly balancing standardization against flexibility.

The enterprise architect role appears where an architect or IT leader coordinates around AI infrastructure, tooling, and policy. If you are here, you are coordinating not only business teams but also infrastructure realities that the business teams may not see.

The sponsor manager is a senior manager who sponsors coordination from above: convening teams, ensuring priorities line up with strategy, allocating resources, and resolving the conflicts the coordinator cannot.

Many organizations have no formal role for any of this. Someone still has to convene, facilitate, and align. If you have visibility across teams, credibility with peers, and the ability to see where effort is being wasted, you can step into a coordinator role without waiting to be given one.

Start With an Inventory

Naomi's first move at the organizational level was the same as her first move with Raj: get visibility. You cannot coordinate what you cannot see, so the first artifact is an AI inventory, a simple list of the AI initiatives across the organization.

For each initiative, capture the name and a short description; which team or function owns it; what business problem it solves; which AI tools or models it uses; its status, whether planning, piloting, or deployed; the owner or sponsor by name; and the key metrics being used to judge success.

This is not bureaucracy, and it is worth saying that out loud when you ask people to fill it in, because they will assume it is. It is intelligence. It lets you see patterns, spot overlaps, and connect teams that should already know about each other. Naomi's inventory was the thing that revealed finance, procurement, and supply chain were three variations on one problem. Start simple: a spreadsheet with those columns is enough, and you can build something more sophisticated later if the portfolio grows enough to justify it.

Reading the Inventory for Opportunities

Once you have visibility, five kinds of opportunity tend to surface.

Shared problems being solved with different tools. Bring those teams together. Understanding why each chose what it chose is usually illuminating: sometimes one team found a genuinely better answer, sometimes both chose poorly and would benefit from consolidating, and sometimes the tools really are different because the problems really are different. You will not know until you ask.

Emerging best practices. Has one team found a prompting technique that materially improves output? Built a review process that raises quality while cutting time? That learning is worth far more spread than hoarded. Create forums where teams present what they have discovered.

Infrastructure and data sharing. Multiple teams extracting the same data from the same sources for different AI systems is pure waste, and it guarantees the versions will diverge. Coordinate to build shared pipelines or shared repositories that teams can draw on.

Shared services. Some things should be built once and offered to everyone rather than rebuilt per team: a vendor management function, a data quality function, a training program. These are services, not mandates, and teams adopt them because using them is easier than building their own.

Policy and governance. As adoption grows, the organization develops positions on data handling, model governance, and acceptable use. Coordinating on those prevents teams from operating under quietly inconsistent expectations, which is how one team ends up doing something another team already knows is prohibited.

Governance That Enables Rather Than Blocks

The most common way coordination fails is that it turns into control. The coordinator builds governance, teams experience it as a tax on getting anything done, and they start routing around it. Then you have both the friction and the fragmentation.

The distinction worth holding onto is what the governance conversation is for. Governance that enables asks what you are trying to do, who this affects, and what could go wrong, and then uses your answers to help you navigate the decision. Governance that blocks asks whether you are in compliance and enforces rules without regard to context. The first makes people want to come to you early. The second makes them come to you late, or not at all.

Enablement-focused governance, meaning governance that supports innovation by providing guidance and frameworks while leaving teams flexibility in how they solve problems, has five recognizable characteristics.

It states clear principles rather than rules. Instead of a rule that all AI tools must come from an approved list, a principle that tools must meet stated criteria for data security, audit trails, and vendor viability. Teams apply the principles to choose their tools, and you provide guidance when they are unsure.

Its review processes are brief and collaborative. Instead of a lengthy approval workflow, a 30-minute conversation in which you understand the team's plan, help them think through the risks, and then let them proceed.

It is transparent. Teams know which governance applies to what, and they are not ambushed by a requirement halfway through a project. You publish the principles, the review criteria, and how decisions get made.

It has clear escalation. Most decisions are routine and should be fast. Genuinely novel or high-risk decisions escalate. Say plainly which is which, so nobody has to guess whether their case is the special one.

It integrates feedback. When teams tell you the governance is slowing them down, you listen and adjust rather than defending a process because it exists. A governance process that cannot be criticized is one that will be evaded.

Navigating Genuinely Competing Priorities

Sometimes coordination surfaces a conflict with no clean answer. One team wants everyone to standardize on a particular tool. Another has built real capability on a different tool and is getting real value from it. Both positions are reasonable.

Start with understanding rather than adjudication. Ask why each team wants what it wants, and what the underlying need is beneath the stated position. Often the needs are compatible even when the positions are not, and a creative option appears once both are on the table.

When no such option exists, make the decision at the level of authority that actually fits the issue. Some decisions are genuinely team-level, like which tool works best for one team's internal productivity. Others are genuinely organizational, like which tools may touch customer data. Being explicit about which kind of decision you are making prevents a team from feeling overruled on something that was always theirs, and prevents another from claiming autonomy over something that was never theirs alone.

When your decision disadvantages a team, explain the reasoning. Share the tradeoffs you weighed and show that you took their interests seriously. People can accept a decision that goes against them far more easily than they can accept one that appears to have been made without them in mind, and that acceptance is the currency a coordinator without authority runs on.

Forums for Learning and Alignment

Naomi's monthly sync with Raj scaled up into a set of forums when the coordination widened past two teams. Four cadences cover most needs.

A monthly standup of about 30 minutes with a representative from each major team doing AI work. Each answers three questions: what are you working on, what did you learn, and what do you need? That is enough to create visibility and connection without becoming a project meeting.

A quarterly business review, a deeper conversation about progress against AI goals. Are we tracking to expectations? Should priorities shift? What are the biggest blockers, and which of them can only be removed at this level?

Topic-specific working groups where several teams are working the same problem. If four teams are all doing document processing, convene them, let them meet regularly, and let them build the shared practice themselves rather than having it handed down.

An annual forum, a larger gathering to celebrate wins, share learning, and set direction for the coming year. Make it substantive rather than ceremonial: teams presenting real case studies, leaders discussing actual strategy, attendance that people would choose even if it were optional.

The point of the whole set is cultural rather than administrative. When learning and alignment are routine, teams stop seeing themselves as isolated initiatives and start seeing themselves as part of one organizational effort, which is precisely the shift that made Naomi and Raj's seams get fixed instead of relitigated.

Getting Tool Proliferation Under Control

Most organizations accumulate tools gradually, and each acquisition is individually rational. A team has a problem, evaluates options, picks the best fit, and moves on. Collectively the organization ends up with far more tools than it can support, teams that do not know what already exists, no integration between systems, and duplicated licensing. Nobody made a bad decision; the aggregate is still a bad outcome.

Managing it means being thoughtful about adoption without becoming so restrictive that teams cannot solve their problems. Five practices do most of the work.

Maintain an inventory of approved tools, meaning tools that have been evaluated and cleared for organizational use because they meet security standards, have acceptable vendor viability, and have known capabilities. This list is a service to teams, not a cage, because it saves them the evaluation work.

Set clear criteria for when to use an approved tool and when a team may pilot something new. A workable formulation: standard business problems use approved tools, while novel problems or genuine edge cases may pilot a new tool pending approval. Teams can live with a rule they can apply themselves.

Capture the learning from every pilot. If the new tool works, evaluate it for approval so the next team benefits. If it does not, document why, so nobody repeats the experiment in eighteen months having forgotten it was already run.

Audit the inventory periodically. Which tools have exactly one user? Is that tool providing genuinely unique value, or is it a relic of one team's old decision that nobody has revisited? Where can you consolidate without taking real capability away?

Sunset old tools deliberately. When a newer tool supersedes an older one, help teams migrate rather than simply withdrawing support. Teams need time and help to transition, and a badly handled sunset will cost you the goodwill you need for the next round of coordination.

Three Ways Coordination Fails

Governance theater. A coordinator establishes elaborate procedures: approval forms, review committees, compliance audits. The intent is good and the impact is friction. Teams resent the coordination and avoid it, and AI progress slows. The correction is to point governance at enabling rather than controlling, keep reviews brief and collaborative, and state principles rather than accumulating rules.

Coordination without influence. A coordinator identifies real opportunities but has no authority to act on them, makes recommendations that are politely ignored, and watches teams carry on exactly as before. The failure is not that the opportunities were wrong. It is that the coordinator had neither authority nor influence. If you are coordinating, invest in relationships, build influence deliberately, and engage leadership where a decision genuinely needs their weight. Do not try to coordinate on the strength of being right alone.

One-size-fits-all standards. A coordinator mandates that every team use the same tool even where needs genuinely diverge. Finance needs document processing; marketing needs content generation. Those are different problems and may well need different tools, and a mandate that ignores this produces resistance and resentment that spills onto every other coordination effort. Allow flexibility within a framework: different tools for different problems, standardization only where it adds genuine value.

Practice and Reflection

Work through these with your own organization in mind rather than in the abstract.

Build a first inventory. Imagine your organization has seven teams and your preliminary interviews found this: two teams using a general-purpose assistant for internal productivity, one using a coding assistant for code generation, one piloting a document-analysis assistant for legal work, and two not yet using AI at all. Build the simple inventory. What coordination opportunities do you see in it? What would you do first, and why that rather than the others?

Navigate a real conflict. One team wants a tool that requires sharing customer data with a third-party vendor. Another team objects on data security grounds. How would you navigate this? What questions would you ask each side? Who else would you involve in the decision, and at what level should it be made? How would you communicate the outcome to the team that loses?

Design a quarterly business review. What would you cover, who would attend, and what would you expect to accomplish? Structure it specifically so that learning surfaces and coordination opportunities become visible, rather than so that each team reports status and nobody listens.

Decide a consolidation. Suppose three tools are approved for document processing and, over time, four more have been piloted by individual teams. You are evaluating consolidation. What criteria would you use to decide which tools to keep and which to retire? How would you communicate a sunset decision to a team currently depending on a tool you are deprecating?

Then reflect on three questions about your own situation. What is your current visibility into AI adoption across your organization, and are there teams doing AI work you do not know about? If you took on a coordination role, what would your first priority be, whose relationships would you need to build, and what would success look like at three months? And is your organization's current governance enabling or constraining, and what would change if you reframed it as enabling?

Where Coordination Leads

Cross-functional coordination is the bridge between team-level AI management and enterprise-scale AI capability. It is the layer where individual team successes combine into something the organization owns rather than something a few teams happen to have.

The organizations that do well with AI are not necessarily the ones with the most inventive teams. They are the ones where teams learn from each other, where redundant effort is minimized, and where standards exist precisely where they reduce complexity while flexibility survives precisely where it enables creativity. Getting there is skilled work: it requires holding multiple perspectives at once, building relationships across boundaries you do not control, and balancing standardization against flexibility case by case.

Start where Naomi started. Build visibility into what is happening. Connect with peer managers and understand their challenges and goals before proposing anything. Find the places where alignment serves everyone's interests, and build from there. Over time the coordination becomes cultural rather than personal: learning flows across boundaries, best practices spread, duplication falls, and value compounds. That is how organizations build durable advantage with AI, not through one exceptional team but through systemic coordination that lets many teams amplify each other.

Key Takeaways

• Local AI wins can be global problems. Two teams each optimizing their own AI will industrialize the misalignment at the seam between them, and the customer pays for it.
• Coordinate the seams, not everything. Map where teams hand work to each other and focus on those few interfaces rather than trying to align entire workflows.
• Give every shared workflow one Accountable owner. A RACI chart ends blame fights by naming who owns each seam, especially the shared knowledge source the bots read from.
• Keep the rhythm light and seam-scoped. A monthly 30-minute sync plus a shared channel beats a heavy committee and respects that neither manager controls the other's team.
• Reconcile shared definitions and data. Bots contradict each other when the same word means different things in each system; align the crossing definitions and point both tools at one source.
• Coordination is a choice peers make. No one mandates it across two teams, so the managers have to opt in and organize it deliberately.
• Start with visibility. An AI inventory of initiatives, owners, tools, status, and metrics is what turns a vague sense of duplication into a specific list of coordination opportunities.
• Coordinate when problems, data, tools, or policy are shared. Genuinely isolated team productivity use does not need coordinating, and trying to coordinate it makes you the bureaucrat teams route around.
• Build governance that enables. Clear principles rather than rules, brief collaborative reviews, published criteria, explicit escalation, and a willingness to change the process when teams say it is slowing them down.
• Handle tool proliferation deliberately. Keep an approved list, state when piloting is allowed, capture what every pilot taught you, audit periodically, and help teams migrate rather than just withdrawing support.
• Explain the tradeoffs when you decide against someone. A coordinator without authority runs on trust, and trust survives an unwelcome decision far better than it survives an unexplained one.