- ZeroBlockers
- Posts
- Why We Need Cross-Functional Teams
Why We Need Cross-Functional Teams
Andy Grove, famed CEO of Intel, wrote in his book High Output Management: "Speed is the only benefit of cross-functional teams; in all other cases, functional organisations are superior." So if cross-functional teams only have one advantage why should we trade the superior efficiency of functional structures for the less efficient cross-functional structure? Because in a highly competitive and fast changing market, speed is the only advantage that matters.
In the early 20th century, Frederick Winslow Taylor revolutionised work with the principles of scientific management. The goal was simple: maximise efficiency by breaking down work into specialised functions, with each department focusing on its specific area of expertise. This approach made sense in an industrial era characterised by stability, long product cycles, and incremental improvements.
By organising companies functionally, businesses could achieve economies of scale, reduce costs, and optimise processes. The intentional trade-off was adaptability: because each function was tuned to perform in the current environment, change would always temporarily slow down functions. And because each function was governed based on efficiency, change was often resisted.
Today, every industry is operating in an environment of rapid change. Product lifecycles are shorter, competition is fierce, and customer expectations evolve quickly. In this landscape, the rigidity of functional teams can become a liability.
The Problem with Functional Organisations in High-Change Environments
One of the clearest examples of how functional silos struggle with change comes from the automotive industry. In the 1980s, General Motors (GM) visited Toyota’s factories in California to understand why their production quality and speed were superior. GM meticulously documented Toyota’s processes and implemented them in their own factories. But the results were disappointing; GM’s performance did not improve as expected.
Upon returning to Toyota’s factories, they noticed that one workstation on the assembly line had changed. Initially, a worker had trays containing parts for four different car models. Over time, Toyota had modified the process so that parts moved along the assembly line with the car, reducing the complexity at that workstation. However, making this change required an earlier workstation to take on the additional task of sourcing and placing parts on the assembly line. It would slow down the earlier workstation but speed up the assembly line as a whole.

This type of adaptation is difficult in a traditional functional organisation. In a functionally siloed company, asking one department to take on extra work to improve overall system performance is a tough sell. Each function is incentivised to optimise its own efficiency, the efficiency of other functions is their problem. In Toyota's case, the change was possible because they prioritised system-wide flow over functional efficiency.
The Theory of Constraints and Functional Bottlenecks
Another major challenge in functional organisations is the unintended consequences of local optimisations. The Theory of Constraints, introduced by Eliyahu Goldratt, highlights that any system is only as fast as its slowest bottleneck. Improvements in one area that do not address the constraint can actually worsen overall performance.
A common example comes from software design. Suppose a company invests in a new design system that allows designers to create high-fidelity prototypes twice as fast. This sounds like a great improvement, but if the developers are already overburdened with design work this is just going to make the problem worse. Development actually slows down even further because, in addition to their development work, now they have to manage and triage an ever-growing backlog. The local optimisation of the design team actually slowed down the whole development process.

In functional organisations, this type of issue is frequent. Each function independently seeks efficiency improvements without considering their impact on the broader workflow. Cross-functional teams, on the other hand, focus on end-to-end outcomes rather than localised efficiency gains.
“Our Teams are Already Cross-Functional”
A common objection that comes up is that companies already have cross-functional project teams. However, there is a critical distinction between a team of functions and a cross-functional team.
Many project teams are composed of representatives from multiple functions such as designers, engineers, marketers, and product managers, but each function still operates independently. Work is done in silos, with handoffs between departments. The designer completes a prototype, then hands it off to engineering. The engineers build the product, then pass it to marketing for a launch campaign. This structure does not foster the rapid feedback loops and collaboration necessary in a high-change environment.
In addition, functional organisations often struggle with innovation because breakthrough ideas typically emerge from the intersection of different disciplines. When functions operate in silos, with limited cross-pollination of ideas and perspectives, they miss opportunities for creative solutions that combine insights from multiple domains.
True cross-functional teams eliminate rigid handovers and instead work together iteratively. Engineers provide input during design, marketing shapes messaging alongside product development, and everyone shares accountability for the outcome. This level of collaboration allows teams to adapt quickly, pivoting when needed instead of following a predefined sequence of steps.
The Implementation Challenge
While the benefits of cross-functional teams in high-change environments are clear, implementing them effectively is a significant challenge. Companies struggle with questions like:
How do you balance cross-functional collaboration with functional expertise?
How do you align incentives so that teams prioritise overall success rather than functional efficiency?
How do you maintain long-term technical and domain knowledge when teams are constantly shifting priorities?
These are complex problems that require fundamental shifts in how organisations structure work, measure performance, and support teams. In the next article, we will explore practical strategies for making cross-functional teams work in practice, addressing issues of governance, funding, and alignment.
Conclusion
Functional organisations were designed for efficiency in stable environments. However, in industries characterised by rapid change, rigid silos create bottlenecks and hinder adaptability. Cross-functional teams offer a way to overcome these challenges, but implementing them effectively requires significant shifts in mindset and structure.
There is no one-size-fits-all approach. Even within companies that embrace cross-functional teams, the need varies. Amazon found that its “two-pizza teams” (small, autonomous cross-functional teams) worked well for software development but were ineffective in functions like finance and legal, where efficiency and consistency were more critical than adaptability. In Intel, the split was approximately 30% cross-functional and 70% functional.
While functional teams remain the best choice in predictable, stable domains, companies operating in fast-moving industries must rethink their structures to remain competitive. The challenge is not just adopting cross-functional teams but making them work in a way that drives real business outcomes.