Perry Reid, a senior coach and trainer, who worked with several others from Industrial Logic to help a telecommunications client, recently told the following story:

Even the simplest feature would take this company 6 months or longer to deliver. The organization was deeply siloed, both technically (across 19 components) and by role. To deliver better software sooner, we created cross-functional teams composed of an architect, a customer representative, developers and testers from each of the component areas. This eliminated knowledge silos, queues, slow handoffs, long integration steps and dramatically shortened feedback cycles with the customer. One feature implemented during this experiment was completed and presented to the customer for acceptance in under four weeks, shattering the company's previous time to market expectations.

Perry’s story is one of many stories that were recently told when I asked my colleagues at Industrial Logic, “What’s been your best experience of helping an organization deliver better software sooner?” Nearly all of the stories shared a common theme: more value got delivered sooner by restructuring into cross-functional teams. So what is a cross-functional team?

A cross-functional team includes everyone (either full- or part-time) necessary to efficiently discover and deliver value for customers, with few-to-no slow dependencies on other teams. Knowledge transfer (cross-pollination) is typically high on such teams, as team members with different specialties collaborate closely on important outcomes. Balanced teams and product teams are examples of cross-functional teams. Feature teams are cross-functional as well, though the name has an unfortunate association with “feature factory”, a team that churns out features rather than delivering what customers most need.

In Perry’s story, a major service from the telecommunications client was organized into 19 deeply siloed component teams. What is a component team? The term is actually ambiguous because there are three types of component teams: shared, unshared and mixed:

• Shared: A shared component team makes components (like objects, functions, libraries, utilities or services) that are intended to be shared by other teams. If the component didn’t exist, each team in the organization would have to create it or find a suitable outside solution. Shared component teams play a valuable economic role in organizations because they save other teams time and money. Smart organizations maintain a small number of shared component teams. Framework or platform teams are often composed of shared component teams.

  When I programmed risk calculators for a Wall Street bank, I relied heavily on a sophisticated, shared date library written by a component team in the bank’s London office. A few years later I was part of a “tools group” that made a collection of shared components and utilities for use by software teams throughout the bank.

• Unshared: An unshared component team makes a part of a solution that usually can’t be delivered to customers without first being integrated with other finished parts of the solution. A product or service may be divided into several unshared component teams, each of which performs a discrete function.
  
  Many unshared component teams behave like functional silos, divided from each other and integrating infrequently. Phil Ensor, a management consultant who invented the term functional silo syndrome in 1988, likened the grain silos he would pass on his drives through Illinois to the silos he found in organizations.

  At a recent client, an Industrial Logic coach found that a data acquisition component team worked independently of a data validation component team, which worked independently from a data science component team, which worked independently from a Spring Boot REST API component team. Prior to working with Wil, these teams only collaborated when they needed to integrate, rather than collaborating, integrating, deploying and releasing continuously.

  Unshared component teams are commonly found in the development of horizontal layers of software: a frontend UI component team completes work and then needs to integrate with middleware components, middleware business logic is produced and then must be integrated with frontend and backend components.

• Mixed: Most component teams are either shared or unshared, yet some aren’t quite sure. Adeel Ali, an Industrial Logic coach, explained, “I see unshared components created with a hope that one day they will turn into shared components. The team ends up creating complex and generic interfaces for such components that only serve to complicate integration.” The opposite also occurs, when a shared component begins to acquire unshared logic intended solely for use in a specific product or service. Mixed up may be a better name for these kinds of component teams.

So what kind of component teams did Perry and colleagues find at the telecommunications client? They were unshared component teams. He explained:

The issue I saw at this client was almost an expression of Conway's Law. Most of the 19 component teams existed because a 3rd party tool or technology had been selected to be integrated into their technical stack. It would be brought in house, and a team would be formed around it including analysts, developers, testers, and managers. That team would then try to coordinate with other related component teams they depend on much like the actual components would communicate in their actual system.

Perry’s story, and the majority of “better software sooner” stories from my colleagues, describe how moving to cross-functional teams led to breakthroughs in performance, enabling organizations to be far more responsive to customer needs.

Performance from unshared component teams pales in comparison. Years of experience across numerous industries has revealed the same, tired problems:

• Unshared component teams become functional silos.
• Inter-team collaboration is inhibited.
• Delays result from teams waiting on other teams to complete work.
• Integration pain increases because it happens so infrequently.
• Knowledge sharing is diminished or stifled.
• Learning quickly by releasing early rarely happens.
• Schedules slip.

And when products or services that are organized into unshared component teams hit major scheduling delays, management applies pressure, stress increases, quality decreases and unhappy staff multiply. This is why I believe that:

Unshared component teams are a root cause of mediocre performance.

Meanwhile, year after year, across numerous industries, my colleagues and I find that cross-functional teams produce better outcomes sooner by:

• greatly reducing delays in communication and collaboration;
• eliminating or reducing slow hand-offs;
• easing the work of integrating code;
• enabling evolutionary design; and
• increasing the speed of both delivery and learning.

In short, cross-functional teams enable agility in software development.

And for decades, people have known this. So I wanted to explore why unshared component teams continue to thrive, despite all of the benefits of cross-functional teams. What is it about them that leads so many organizations to continue to rely on them?

Here are my theories:

• Too Entrenched? Perhaps the organization was structured into unshared component teams years ago and changing it now feels like too much work? No one wants to re-think reporting structures, department boundaries or bonus plans. Maybe a few cross-functional team pilots even showed amazing results but it still felt like too much work to make them the dominant team structure? At a recent client, a cross-functional team was assembled out of volunteers and two Industrial Logic coaches. The team did outstanding work. When the initiative ended, each team member went back to their original unshared component team and their managers were apparently happy to have them back.

• Risk Aversion? Perhaps the organization is simply too comfortable with unshared component teams and afraid to take the risks necessary to switch to cross-functional teams? This is closely related to being Too Entrenched, as described above.

• Good Enough Performance? Perhaps the organization functions well enough or makes enough profit such that switching to cross-functional teams is perceived to not be worth the effort and cost?

• Easier Management? Perhaps unshared component teams offer managers an easier way to appear competent and less afraid because a component team is easier to manage than a cross-functional team? Does it let them prove that they got their piece of the puzzle completed, regardless of whether it can ship or deliver value to a customer? We certainly see that such teams are popular in organizational structures that are optimized for planning and completing parts of solutions rather than quickly delivering solutions.

• More Management Jobs? Are unshared component teams popular because they tend to require more traditional management jobs, whereas cross-functional teams tend to decrease the number of such jobs? Do people not want to face the unpleasant task of letting some managers go when switching to cross-functional teams?

• Specialization? Are products and services organized into unshared component teams because management believes that high performance results from specialization? For example, web-based front end developers specialize in the complexities of CSS and responsive design and don’t have time to waste learning about middleware or backend work. Do they believe that the cohabitation and cross-pollination that comes with cross-functional teams is waste?

• Complexity? Or has technology gotten so complicated these days that unshared component teams seem like the only way to go? In other words, your middleware or backend programmer shouldn’t learn any front-end technology because frankly, it’s all so complicated that each team is better off staying in its lane?

• Community? Stefan Tikkov points out that “People in tech want to be close to others who share their tech preferences, and tech differences are great candidates for creating we/they situations.”

• Efficiency? Wouter Lagerweij describes the “misconception that everyone should be busy all the time, and different specialties can keep on working on the next thing if you’ve split the work up in all those separate streams. Of course, everything gets stuck in ‘blocked’ at some point.”

• Ignorance? Perhaps unshared component teams remain the default within organizations because leaders and managers are simply ignorant of the benefits of cross-functional teams?

This is a complex subject and I’m sure I have more to learn. What’s your opinion? Have you had success with shared component teams Do you work in an organization that consists mostly of unshared component teams and has that been a problem? If so, why does it remain like that in your organization? I welcome your feedback and insights about this perplexing topic!