Lucia Ferreira runs supply chain operations for a food manufacturing company with about 1,400 employees across four facilities. For years, her team and the procurement team used separate systems, met quarterly, and treated each other with the polite wariness of neighboring countries that share a border but little else. Then Lucia's company launched an AI-powered demand forecasting project. It needed data from procurement's supplier contracts, warehouse management, logistics, and finance, all of which lived in different systems, owned by different teams, each with different ideas about who had permission to share what. "We spent the first three months not solving the AI problem," Lucia says. "We spent it solving the silo problem. And honestly, it was the most useful thing we'd done in years."

AI initiatives have an unusual property: they almost always require data and coordination that crosses organizational boundaries. That requirement either exposes existing silos as blockers, or, if you design deliberately, turns the AI project into the catalyst that finally breaks them down. This lesson is about making the second outcome happen on purpose, treating cross-functional integration as the substance of the work rather than an obstacle in front of it.

Why AI Exposes Silos

A silo, in organizational terms, is a unit that operates independently: its own budget, its own processes, its own data, and often its own definitions of shared concepts. Silos are not accidents and they are not evidence of bad management. They form because functional specialization is efficient. A procurement team focused entirely on supplier relationships performs better than one that spends half its time answering questions from other departments, and the boundary that produces that focus is the same boundary that becomes a problem later. Any attempt to break down silos that starts from the premise that they should never have existed will fail to persuade the people inside them.

But AI systems, specifically the ones that generate the most value, typically model complex processes that span functions. Demand forecasting requires sales, supply chain, marketing, and procurement data. Customer lifetime value models require sales, finance, and service data. AI hiring tools require talent acquisition and hiring manager input. The moment you try to build these systems, the silo becomes the constraint, and it becomes visible in a way that ordinary operations never make it visible. A process that works acceptably when each function optimizes its own part turns out to be impossible to model end to end, because nobody owns the end-to-end view and no shared representation of it exists.

This is why AI projects surface silo problems that surveys and reorganizations miss. The project has to actually assemble the data, which forces every latent disagreement about ownership, definition, accountability, and cost into the open on a schedule. Four barriers account for most of what surfaces.

Each of these is structural rather than attitudinal. That distinction matters because it determines what fixes them. A team that defaults to refusing data requests is usually not being obstructive; it is protecting itself against a risk it has been made responsible for and given no way to discharge. Give it a decision route and a named owner and the refusal usually disappears without anyone's attitude having changed.

Using the AI Project as a Catalyst

The key insight is to treat silo-breaking as an explicit objective of the AI initiative rather than a side effect, and certainly not as a barrier to be routed around. Design the project so that cross-functional collaboration is built into its structure from the start, which means the collaboration has a purpose, a schedule, and a decision it exists to make. Collaboration that is convened without a decision attached becomes a status meeting and then becomes optional.

Lucia's team did this by establishing a cross-functional data governance group at the project's inception. It included a representative from each team whose data the forecasting model would use: supply chain, procurement, finance, and the two facility operations managers. The group had three explicit mandates: agree on shared definitions, resolve data access questions, and sign off on the model's inputs before development proceeded. That third mandate is what gave the first two teeth, because the project genuinely could not advance until the group had done its work, and everyone in the room knew it.

This created something that had not existed before: a regular meeting where supply chain and procurement sat in the same room, working toward the same goal, with a named executive sponsor who could resolve disputes rather than escalate them into a longer queue. The AI project was the forcing function. The cross-functional collaboration became the habit. When the group's original mandate was complete, the relationships and the shared vocabulary it had produced remained available for the next problem, which is the durable return on a project that many organizations write off as three lost months.

Four Structural Moves That Work

1. Establish a cross-functional project team with real authority

This is not a steering committee that meets quarterly. It is a working team that meets weekly during active development and monthly during deployment and monitoring. Each member has authority to commit their team's data, time, and cooperation, not merely to report back and ask permission. Without decision-making authority in the room, every meeting ends with action items that die in someone's inbox, and the meeting's real output is a delay of one cycle per decision. The test for whether you have the right people is simple: ask whether anything in the last session had to be taken away for approval, and if the answer is usually yes, you have assembled a reporting layer rather than a working team.

2. Create a shared data dictionary before building anything

Before writing a single line of model code or running any data, require the cross-functional team to agree on the definition of every key term the model will use. Document it. Have people sign off on it. This sounds tedious, and it is. It is also the single most reliable predictor of whether a cross-functional AI project produces something useful or something that generates debate for two years, because a model built on terms that mean different things in different source systems produces outputs that every function can plausibly dispute. The disagreements are real and they do not become less real by being deferred; deferring them simply moves them from a definitions workshop, where they can be resolved cheaply, into a results review, where they arrive as an attack on the model.

3. Share the benefit accounting explicitly

Consider a case where the AI system generates $2 million in annual efficiency gains, 80% of the efficiency accrues to supply chain, and procurement absorbs 60% of the implementation cost. That is a problem, and it is a problem whether or not anyone has calculated it, because the team on the wrong side of the split will eventually feel the imbalance even if they cannot quantify it. Resolve it structurally before the project launches by negotiating a shared cost-and-benefit model that the respective team leaders sign. This conversation is uncomfortable, since it requires each side to state what it expects to gain and what it is willing to carry. It is far less uncomfortable than the alternative, which is discovering the imbalance mid-project when someone quietly pulls their cooperation and gives an unrelated reason.

4. Use the AI project to build durable infrastructure

The cross-functional team, the data dictionary, and the shared governance model should not dissolve when the AI project ships. They are organizational infrastructure, and they are the most valuable thing the project produced after the model itself. Formalize them: give the dictionary an owner and a review cadence, keep the governance group in existence with a reduced meeting rhythm, and extend the model to the next cross-functional AI project rather than convening a new group from scratch. The silo-breaking work done for one project should lower the cost of the next one significantly, and typically it does, provided someone takes explicit responsibility for preserving the structures rather than letting them lapse when attention moves on.

What to Do When a Team Will Not Cooperate

Not every team welcomes an AI project that requires their data and their time. Resistance in this setting is rarely irrational, and treating it as such guarantees you will misdiagnose it. Three patterns account for most of it, and each has a response that works better than persuasion.

"We're too busy." This is often simply true. Participation in an AI project is a tax on a team's existing workload, and the team has usually not been given relief anywhere else to pay it. The response is to minimize the ask rather than to argue about priorities. Define the minimum viable participation, for example three hours per month, one designated representative, and one data extract per quarter, and negotiate that specific commitment instead of asking for open-ended engagement. A bounded request can be planned around; an unbounded one has to be refused.

"This will hurt us." Sometimes a team resists because they correctly perceive that the AI system will reveal inefficiencies in their operation or reduce their headcount. This concern should be addressed directly rather than dismissed, and dismissing it is particularly damaging because the team knows whether it is true and will draw conclusions about your credibility from your answer. If the concern is legitimate, address it structurally: make explicit commitments about how findings will be used, and where possible involve the team in designing the system that will affect them, so that the analysis is something they participate in rather than something done to them.

"That data is sensitive." Data protection concerns are real and should be respected rather than overridden. Work with the resistant team and your data governance or legal function to establish the minimum data access the project actually requires and the protections that will be in place around it. Very often the request can be narrowed substantially without weakening the model, because the original ask was drafted expansively to avoid having to come back. Treating this as a legitimate concern, even when it slows the project, builds the trust that makes future cooperation easier and costs far less than the alternative of forcing access through a sponsor and being refused everything discretionary thereafter.

The silo problem is not a technology problem. It is a trust problem with a technology symptom. AI projects that succeed at cross-functional collaboration invest in the trust as much as in the tool.

Anti-Patterns

• Routing around the silo. Building the model on whatever data you can get without cooperation. It produces a system that no other function trusts or feels responsible for, and it forecloses the collaboration the project could have created.
• The steering committee instead of a working team. A quarterly forum of people who must take decisions away for approval turns every decision into a cycle of delay and produces action items rather than commitments.
• Deferring the definitions argument. Starting development before terms are agreed does not avoid the disagreement; it relocates it from a cheap workshop to an expensive results review, where it arrives as an attack on the model.
• Leaving the cost and benefit split unexamined. An imbalance that nobody has calculated is still felt by the team carrying the cost, and it surfaces as unexplained withdrawal of cooperation partway through.
• Treating resistance as an attitude problem. Labelling a team obstructive when they are protecting themselves against an undischarged risk guarantees you will apply persuasion to a structural problem.
• Overriding a data protection objection through the sponsor. It usually works once, and it converts a team that was negotiating into a team that refuses everything discretionary from then on.
• Asking for open-ended engagement. A request with no defined limit cannot be planned around and therefore has to be refused, even by teams that would happily have agreed to a bounded commitment.
• Letting the infrastructure lapse at go-live. Dissolving the cross-functional group and orphaning the data dictionary when the project ships means the next initiative pays the same three months again.

Practice Prompts

• Take an AI use case your organization is considering and list every function whose data it would require. For each one, write down who has the authority to approve sharing that data. Note how many of those names you had to guess at.
• Pick three terms your proposed model would rely on, such as customer, revenue, or on-time delivery, and ask two different functions to define each one independently. Compare the answers before anyone builds anything.
• Write the outcome accountability statement for a cross-functional AI system in one sentence: when this system produces a bad result, whose job is it to fix it? If the sentence needs an "and", you have an accountability gap.
• Sketch the cost and benefit split for a cross-functional initiative you know. Identify which team carries cost disproportionate to benefit, and draft the structural adjustment you would propose to their leader.
• Define the minimum viable participation you would ask of a reluctant team: hours per month, named representative, and data cadence. Check that you could commit to it yourself if the roles were reversed.
• For a team you expect to resist, write out which of the three patterns you think applies, then test it in conversation. Note whether you were right, because misdiagnosis here is common and expensive.
• List what would need to survive your current project's go-live in order to make the next cross-functional initiative cheaper, and name who will own each item afterwards.

Reflection

Think about the last time your organization tried to build something that crossed functional boundaries. Where did it actually slow down? In most cases the delay is not attributed to the silo at the time; it is attributed to data quality, or to a vendor, or to competing priorities. Look back and ask whether the underlying cause was that two teams had never agreed who owned a decision, or had never agreed what a term meant. That reattribution is uncomfortable and it is the most useful diagnostic available, because it tells you which structural fix would have changed the outcome.

Then consider Lucia's framing of her first three months. She lost a quarter of the project timeline to work that was not on the plan, and she describes it as the most useful thing her organization had done in years. Would your organization be able to describe it that way, or would that quarter have been reported as a slip? The answer tells you whether cross-functional integration is something your organization values or something it tolerates, and that in turn determines whether you should make silo-breaking an explicit objective of the initiative or let it remain an unbudgeted cost.

Glossary

• Silo. An organizational unit that operates independently, with its own budget, processes, data, and often its own definitions of shared concepts. A product of functional specialization rather than a management failure.
• Cross-functional data governance group. A working body with a representative from each function whose data a system will use, mandated to agree definitions, resolve access questions, and sign off on inputs before development proceeds.
• Shared data dictionary. An agreed, documented, and signed-off definition of every key term a model will use, produced before any code is written.
• Data ownership dispute. The situation in which no team can say who has authority to share a given dataset, causing each to refuse by default in order to protect itself.
• Accountability gap. The condition where an AI system spans several teams and no individual's remit covers its outcome, so problems have no owner.
• Shared cost and benefit model. A negotiated agreement, signed by the relevant leaders before launch, describing how the costs and gains of a cross-functional initiative will be attributed between teams.
• Minimum viable participation. A bounded, explicitly negotiated commitment of time, representation, and data from a function, offered in place of an open-ended request for engagement.
• Forcing function. A project requirement that cannot be met without cooperation across boundaries, used deliberately to create collaboration that would not otherwise be convened.

Related Lessons

This lesson focuses on using an AI initiative to create collaboration that did not previously exist. Cross-Functional Collaboration & Knowledge Sharing covers sustaining that collaboration once the forcing function has gone. Decision Rights & Accountability goes considerably deeper on the ownership and escalation structures that resolve the accountability gap described here. Data Quality & Master Data Management and Enterprise Data Architecture & Governance address the shared definitions problem at an enterprise scale rather than a project one, and Data Access & Security Governance covers the access and protection questions that surface when a reluctant team raises a legitimate data sensitivity objection.

Closing

Lucia's project shipped a demand forecasting model, and that model is not the reason her organization changed. The reason is that a group of people who had met quarterly and shared nothing spent a quarter agreeing what their words meant, who owned what, and how the costs and benefits would fall, and then kept meeting. The AI project supplied the deadline and the reason; it did not supply the trust, which had to be built by conceding things and honoring commitments. If you take one design decision from this lesson, make it the decision to write cross-functional integration into the project's objectives, so that the three months spent on it are the work rather than the delay.

Key Takeaways

• High-value AI systems almost always span functional boundaries. The silo problem is not a blocker to route around but a problem to solve, and the AI project is the catalyst that makes solving it possible.
• Four barriers account for most of what surfaces: data ownership disputes, inconsistent definitions, accountability gaps, and budget conflicts. All four are structural and all four should be addressed before development begins.
• Establish a cross-functional team with real decision-making authority, not a reporting committee. Every member must be able to commit their team's cooperation without going back for permission.
• Build a shared data dictionary before building anything. Deferring the definitions argument moves it from a cheap workshop into an expensive results review, where it arrives as an attack on the model.
• Negotiate shared cost and benefit accounting before launch. Imbalances discovered mid-project destroy cooperation; imbalances resolved upfront preserve it.
• Diagnose resistance before responding to it. Too busy, this will hurt us, and that data is sensitive are three different problems with three different responses, and none of them is persuasion.
• Bound what you ask for. A defined minimum participation can be planned around and agreed; an open-ended request for engagement has to be refused.
• Preserve cross-functional infrastructure after the project ships. The governance group and data dictionary are organizational assets that reduce the cost of every subsequent cross-functional initiative, but only if someone owns them.

Frequently Asked Questions

Is it really worth spending months on definitions before building anything? It is worth spending as long as it takes to agree the terms the model actually depends on, which is usually a much shorter list than a full enterprise glossary. The cost of skipping it is not a delay, it is a model whose outputs each function can plausibly dispute, and disputes at that stage are resolved by rebuilding rather than by discussion. Scope the dictionary to the model's inputs and the work stays proportionate.

What if we cannot get people with real authority into the working team? That is itself the finding, and it should be escalated as one. A cross-functional project staffed with people who must seek approval for every commitment will run at the speed of the slowest approval chain, and it is better to make that visible to the sponsor at the outset than to discover it in the third month. Sometimes the honest response is to narrow the project's scope to functions that can commit.

Should the executive sponsor overrule a function that refuses to share data? Only where the refusal has no substantive basis, and rarely even then. Overruling works once and converts a negotiating partner into a team that grants nothing discretionary afterwards. The better route is to establish the minimum access the project genuinely needs, which is often far less than was originally requested, and to bring data governance or legal in as a joint problem-solver rather than as an authority to be invoked against the team.

How do we keep the governance group alive once the model is live? Give it a smaller standing mandate rather than disbanding it: ownership of the data dictionary, a review cadence, and first refusal on the next cross-functional initiative. A group with a reduced but real remit survives; a group that is thanked and dissolved has to be rebuilt from nothing, and the next project pays the same start-up cost that this one did.