Cross-Functional Teams vs. Teams of Functions: The Hidden Difference That Defines High-Performing Product Teams

Behind the scenes, each function reports to a different manager, follows distinct processes, maintains functional KPIs, and works in strict handover sequences. In reality, these are teams of functions, not cross-functional teams. The distinction is subtle but it explains why so many teams struggle to deliver value efficiently.

What Is a Team of Functions?

A team of functions is a group of specialists from different domains working together in name only. In practice:

• Each person reports into their functional silo (e.g., design to the Head of Design, devs to Engineering).

• Processes are inherited from the function, not tailored to the team.

• Work passes through sequential handovers - design to dev, dev to test, etc.

• Success is measured individually, through function-specific KPIs (e.g., test coverage, research depth, velocity).

• Roles are fixed - a developer doesn't "do" design, and a designer avoids writing copy or code.

This structure creates invisible barriers within what should be a cohesive unit. Team members may sit together, attend the same meetings, and work on the same project, but they're fundamentally operating as separate entities with different priorities, processes, and accountability structures. The result is often slower delivery, reduced innovation, and a lack of accountability for outcomes since each person can say “I did my job”.

What Is a Cross-Functional Team?

A true cross-functional team is a cohesive unit where all disciplines align around a single goal. The boundaries between roles blur, handovers disappear, and the team jointly owns the outcome. Key characteristics include:

• Shared ownership of both problem and solution.

• Team-level KPIs that transcend functional lines.

• Blended responsibilities - anyone can pick up tasks if they have the skills or can learn.

• Autonomy to define processes that suit the team, not the function.

• Continuous collaboration, not just checkpoints or sign-offs.

In cross-functional teams, roles become capabilities, not boundaries. When problems arise, the focus shifts from "whose responsibility is this?" to "how do we solve this together?" Outcomes matter more than sign-offs, and the team's success is measured by their collective impact rather than individual functional achievements.

Why Most Organisations Get It Wrong

The confusion comes from a superficial implementation of cross-functionality. Teams are formed and told to work together but none of the KPIs really change. Promotions are still based on functional skills rather than team goals. Unless the structural incentives, reporting lines, KPIs, and operating norms change, the team reverts to old behaviours. You can’t mandate cross-functionality through reorgs or ceremonies—it has to be designed and supported at a systemic level.

Spotify’s 2020 shift to a skills-first model is a good example of this. They moved away from rigid roles and levels, recognising that career growth should be about developing capabilities relevant to the team’s needs, not just climbing within a function. As they put it:

This evolution supports cross-functional ways of working because it encourages lateral thinking, collaboration, and team-based success, not function-based hierarchy.

The Key Steps to Build True Cross-Functional Teams

1. Align on Team-Level KPIs

KPIs drive culture. If every function in the team is judged on different success metrics, the team will always optimise locally. Designers will push for elegance, engineers for technical purity, product for timelines—and no one owns the business outcome.

Instead:

• Define team-level KPI’s (e.g., activation rate, retention, revenue per user).

• Ensure every team member sees how their work contributes to this.

• Remove function-specific KPIs that compete with the team goal.

Organisations have two primary structural alternatives to address this challenge. Matrix reporting creates dual reporting lines with a solid line to the team lead and a dotted line to the functional manager. This approach attempts to balance team accountability with functional expertise development. Alternatively, full team autonomy involves having all team members report directly into the team structure, with functional coaches, or Enabling Teams, available to support capability development rather than manage day-to-day performance.

2. Introduce and Enforce WIP Limits

Work-in-progress (WIP) limits aren’t just for kanban boards. They’re a lever for behavioural change. When one function hits its WIP limit and can’t start more tasks, other team members face a choice: sit idle or help. This approach forces team members to step outside their comfort zones and contribute where the team needs them most, rather than optimising their individual productivity. A developer whose coding tasks are blocked might help with user research, while a designer waiting for feedback might assist with testing or documentation. These seemingly small shifts in behavior gradually build cross-functional capabilities and strengthen team cohesion.

This mechanism encourages:

• Cross-training: Designers might support QA. Engineers might help with research. PMs might write support docs.

• Awareness of team bottlenecks, not just personal workload.

• T-shaped skills: team members develop depth in one area but breadth across others.

The key is not to push people beyond their comfort zone blindly but to create systems that make collaboration the default. Over time, new habits form because the system demands it.

3. Shift Training from Motivation to Enablement

Cross-functional collaboration requires different skills, mindsets, and behaviors than most professionals have developed in their functional careers. Simply motivating people to "be more collaborative" rarely produces lasting change.

Instead, organisations need to take a behavioral approach: help people act their way into new thinking patterns. This means providing concrete training on collaboration techniques, conflict resolution, shared decision-making, and cross-functional communication. It means creating safe spaces for people to experiment with new roles and responsibilities without fear of failure.

The aligned KPIs mentioned earlier play a crucial role here, as they provide clear signals about what behaviors and outcomes the organisation values. When people see that their career advancement and recognition depend on team success rather than functional excellence, they're naturally motivated to develop the skills and mindsets that support cross-functional collaboration.

4. Empower Teams to Define Their Own Processes

The final pillar of cross-functional transformation involves resisting the temptation to impose standardised process templates from above. Instead, organisations should empower each team to define how they work end-to-end. This includes decisions about how they conduct discovery and delivery, how they make decisions, how they involve customers in their work, and how they review and measure their success.

This process autonomy builds genuine accountability within the team. When team members collectively own their processes, they become naturally invested in continuously improving them.

Allowing teams to define their own processes doesn't mean abandoning all standards or coordination mechanisms. Instead, it means focusing organisational oversight on outcomes rather than activities, and providing teams with the freedom to experiment, iterate, and optimise their approaches based on what works best for their specific circumstances and objectives.

Conclusion

Moving from teams of functions to truly cross-functional teams isn't an overnight transformation. It requires patience, persistence, and a willingness to experiment and iterate. Organisations that successfully make this transition often find that the benefits extend far beyond improved team performance. They develop more innovative solutions, respond more quickly to market changes, and create more engaging work environments for their employees.