Cross-Functional Teams: How to Set Them Up to Succeed

A cross-functional team brings together people from different parts of an organization, such as sales, operations, finance and customer service, to deliver something none of those groups could deliver alone. In a small business, it might be four people launching a new service line. In a midsize organization, it might be a standing team that owns the customer onboarding experience from first contract to first invoice.

These teams are powerful because they put the people who understand each piece of a problem in the same conversation. They also struggle in predictable ways: members answer to different bosses, priorities collide, nobody is sure who decides, and the team's work quietly drops behind everyone's "real" job. This guide covers how to set one up so it works.

Decide whether you need a team at all

Not every cross-department problem needs a new team. Sometimes a clear handoff process, a shared checklist or a single accountable owner who consults others is enough, and it costs far less time.

The Team Topologies approach, developed by Matthew Skelton and Manuel Pais, offers a useful lens. It describes three ways teams can interact. Collaboration means "working together for a defined period of time to discover new things." X-as-a-Service means "one team provides and one team consumes something 'as a Service'." Facilitation means "one team helps and mentors another team." The framework also stresses that teams can only take on so much complexity before their effectiveness suffers.

The practical takeaway: close, cross-functional collaboration is most worth its cost when the work involves discovery, such as designing a new offering or fixing a problem nobody fully understands. For routine, well-understood work, a clean service relationship or handoff may serve better.

Start with the conditions research points to

Ruth Wageman and Richard Hackman's research on team effectiveness is summarized in a framework of six conditions. Three are described as essential:

• A real team: "Members experience themselves as a team, with shared accountabilities and a need to work together to accomplish them."
• A compelling purpose: the team's reason for existing is clear, challenging and meaningful.
• The right people: a team size that fits the workload "but not too large," with the range of perspectives and skills the purpose requires.

Three are described as enabling: well-designed work with clear ground rules, organizational support in which "structures and systems in the larger enterprise promote teamwork rather than place obstacles in the way," and access to skilled team coaching.

Most cross-functional failures trace back to one of these. A group that meets weekly but has no shared accountability is not a real team. A team whose members are measured only on their home department's goals lacks organizational support.

Make the team real

Give the team a name, a written purpose and a named membership list. Then make the time real:

• Agree in writing with each member's home manager how much of their time belongs to the team, for example two days a week for the next quarter.
• Give the team shared goals that appear in each member's own goals or reviews, so team work is not invisible extra effort.
• Keep it small enough that everyone knows what everyone else is doing.

Frequent contact matters more than occasional big meetings. The Agile Manifesto's principles put it bluntly for software projects: "Business people and developers must work together daily throughout the project." The UK government's Service Manual makes a similar point about its multidisciplinary service teams, saying team members "must work together to design, build and iterate a service based on the user needs." You do not need daily meetings, but you do need frequent, low-friction contact instead of handoffs by email.

Settle who decides what

Unclear decision rights are the fastest way to stall a cross-functional team. Before work starts, write down:

• Which decisions the team can make on its own.
• Which decisions need sign-off, and from whom.
• How disagreements between members are resolved, and who breaks a tie.
• Who the team's sponsor is, meaning the leader with authority across the departments involved who can clear roadblocks.

A simple responsibility chart that lists major decisions and marks who decides, who must be consulted and who just needs to be informed takes an hour to draft and saves weeks of confusion.

For example, imagine a regional distributor forming a team to cut order errors. If the team can change the order form but needs the finance director's approval to change credit terms, everyone should know that on day one, not after the team has spent a month designing a new credit process.

Build a shared language and visible work

Different functions use different vocabularies. "Closed" means something different to sales than to support. Spend a few minutes early on building a short glossary of terms the team will use, and add to it whenever a misunderstanding surfaces.

Make the work visible in one place. A shared board that shows what is being worked on, by whom and what is blocked lets members from different departments see progress without status meetings. Keep decisions and notes in one shared document area rather than scattered across departmental drives and inboxes.

Handle the friction openly

Competing priorities are normal. The member from operations will sometimes be pulled back to an urgent operations problem. Plan for it rather than treating it as betrayal:

• Agree on an escalation path for conflicts between team work and home-department work.
• Review the time agreements with home managers regularly, and adjust them openly.
• Use short retrospectives to ask what is helping and what is getting in the way, then change one thing at a time.

When a conflict keeps recurring, it usually signals a structural problem, such as conflicting goals or missing authority, that the sponsor needs to fix. It is rarely solved by asking people to try harder.

Plan how the team ends

Many cross-functional teams are meant to be temporary. Decide at the start what "done" looks like and what happens afterward. Who will own the new process or product once the team disbands? What documentation will they need? A clean handoff, plus a closing review of what the team learned, lets the organization keep the gains instead of watching them fade when members return to their departments.

If the team is meant to be permanent, revisit its purpose and membership at least once a year, because the problem it was formed to solve will change.

Key takeaways

• Use a cross-functional team when the work needs discovery; use a clear handoff or owner for routine work.
• Wageman and Hackman's framework stresses a real team, a compelling purpose and the right people as essential conditions.
• Put time commitments, shared goals and decision rights in writing before work starts.
• Keep frequent, informal contact and one shared place for work, notes and decisions.
• Treat recurring conflict as a structural signal for the sponsor, and plan the team's ending or handoff from the start.

Sources

• 6 Team Conditions (Ruth Wageman and Richard Hackman), The 6 Team Conditions framework
• 6 Team Conditions, Home page
• Team Topologies, Key Concepts
• Agile Manifesto authors, Principles behind the Agile Manifesto
• GOV.UK Service Manual, What each role does in a service team (updated November 6, 2023)