Why Cross-Functional Teams Should Be The Norm

Another week of travel behind me while working with great teams at really wonderful European companies. As I typically get involved to work with organizations to introduce new platforms or new businesses or to realize fundamental transformations, I work with cross-functional teams where individuals from different parts of the organization are put together in order to accomplish our goal.

As in these teams, we work on changing some part of the organization, the discussions almost always start with sharing war stories describing things that went horribly wrong due to systemic issues in the current organization. Many of these issues are due to a functional setup of the organization where teams are organized according to their respective functional skills or responsibilities and communicate through documents and periodic meetings.

When reflecting on these systemic issues, I realized that I see three syndromes of functionally organized companies: symptoms caused by the development life cycle, the product hierarchy and business/R&D dichotomy.

To start with the development life cycle, many organizations (still) have separate requirements engineering, development and testing teams. In these organizations, it is very typical to experience high degrees of rework, i.e. late changes to the system under development. This rework is often caused by different interpretations of the same requirement by these three different groups and it’s quite typical to see testers, developers and requirements engineers arguing about the right interpretation of the written requirement. The root problem is, of course, that written requirements only capture the 10% that are easy to write down and conveniently ignore the 90% that is hard to document.

The product hierarchy issues that I have experienced are typically concerned with lack of alignment between systems engineering and software engineering. As many companies that I work with are traditionally metal bending companies, the systems engineers often have a mechanical background and have difficulties understanding software. For instance, in one company, the system requirements were written in such a way that it was impossible for the software of the system to specify its own requirements and perform its own tests. Failing to recognize that software is on par or even more important than mechanics and electronics is highly detrimental. Software allows for continuous deployment of new functionality, real-time collection of performance data from systems in the field and enables fundamentally new business models.

Finally, the dichotomy between the business side and the R&D side of companies is still quite prevalent in many organizations. The idea is that the business side knows what customers want and can order functionality from the R&D organization. The problem is of course that these customer needs are communicated through documents that have the same concerns as the requirement specifications described above.

The root of the issue is that people just need to get in the same room and wrestle an issue to the ground. To discuss until everyone in the room has the same understanding of what we’re looking to accomplish. And rather than going back to the respective functions once done with the meeting, the team should stay together and work to accomplish the desired outcome. This is of course the recipe for cross functional teams.

Functional organizations became the norm in the 20th century because they allow for easy scalability, efficiency of the functional tasks and, as a consequence, lower cost for delivering a defined system or product. The problem is that this only works in an extremely stable, predictable contexts, such as manufacturing lines where the same product is churned out year after year. In these contexts, the product is a commodity and the only differentiator is cost. Consequently, squeezing the last drop of blood from the stone is the only viable path.

The problem is of course that everything that is stable and predictable is or will soon be automated. The vast amount of work in organizations performed by humans is that which is not predictable, highly dynamic and requires coordination across many disciplines in the organization. When humans are involved, the focus is on innovation and delivering (and measuring) customer value. And this is not a question of local optimization inside a single function, but rather requires contributions across all functions.

The final issue is of course one of scale: how does a large company move away from a functional structure. To be honest, I think we can already see the first answers to this question: many companies are moving towards network structures where different nodes, inside and outside the organization, provide specific systems and solutions and operate in a market place. The nodes themselves are not overly large and can work with sets of cross-functional teams.

Concluding, the syndromes associated with functional organizations are widely spread and complicated. Many accept the symptoms as unavoidable and as facts of life, just like gravity and aging. However, this is too easy and a cop-out. We need innovation in the way we organize work as much as we need it in the products and services we deliver to our customers. Don’t accept the frustrating and inefficient ways of work. Don’t just complain and whine about to to your colleagues. Analyze the symptoms, brainstorm solutions, try out these solutions and iterate. Remember that the only constant is change and that the only static companies are dead ones.

(For those of you reading my weekly blog posts: I will be on vacation and return to writing these posts in August)