Are there any studies of cross-functional teams vs. domain-based teams (e.g. project-based vs. software/mechanics/etc)?

Question

I work in an organization which creates many integrated systems products - i.e. it is complete products with mechanical/system/electronics/software being designed and manufactured. At the moment most teams are organized around projects in a cross functional way. The advantage of an organization like this is that people who are working closely together for a common goal are close.

The disadvantages come from the isolation of engineers from their peers. Typically a project is assigned only one software engineer. This means that the projects have a high truck factor, minimal knowledge sharing and best practices, and technical development is limited.

So my question is: are there any studies comparing the cost/benefits of these two approaches?

Answer 1

The best type of team structure to use isn't necessarily one of cost-benefit, but instead on the organizational culture currently in place, the characteristics of the employees, and the type of project being conducted. Because of these variables, there's no way to say that a particular strategy or approach is best, but there are some general indicators as to how you can best structure a team to complete the task at hand.

There are many types of teams and ways to organize teams and organizations. Some of the more common forms are functional, lightweight, heavyweight, and autonomous. Below, I'm summarizing a portion of a book on managing technological innovation - Melissa A. Schilling's Strategic Management of Technological Innovation.

A functional team is entirely non-cross-functional. Every employee remains within their own department. Total isolation between science, engineering, human resources, and so on. An employee will report to a functional manager. Under this structure, people working on a project tend to be more committed to their functional department rather than to the project. This structure is appropriate for what is known as a derivative project - leveraging existing work with only minor modifications or improvements and projects that only (or mostly) require a single type of expertise.

Lightweight teams occur when members reside in their functional departments and report to functional managers. However, a project manager is introduced. The project manager will oversee the people that are needed to carry out the project, but not manage them directly. The role of the project manager is to facilitate communication and ensure that each member on the project is appropriately contributing. This structure is best for derivative projects that don't require a large amount of coordination and communication between members.

Heavyweight teams remove required individuals from their functional departments, however they still report to a functional manager. A project manager oversees the project activities, but doesn't directly supervise or manager the individual team members. Project managers typically outrank the functional managers in this environment and are responsible for evaluating, rewarding, and leading the project members. These teams have a high degree of communication and collaboration among those assigned to the project and the members are also committed to the success of the project. This format is used on platform projects, which are used to improve cost, quality, and performance from a previous generation (but might not have significant new innovation).

Autonomous teams remove members from functional departments entirely, and having them work directly under a project manager. Project managers here are senior staff members and leaders of the organization. Sometimes, these teams are given immense freedom to "get the job done" by developing their own policies and procedures. At the same time, they would be held entirely accountable for the successes or failures of the project. These types of teams are often deployed on breakthrough projects, which introduce new innovation into the organization's products, or to produce new business units.

However, just because a particular team type might be generally good for a particular type of project, it also matters what the culture of the organization is. Some organizations can't (or won't) support autonomous teams for cultural reasons. Others "have always done it" a certain way and simply won't change. It also matters what kind of people are on the team - some people function better if they are colocated and have a high degree of communication and ability to collaborate, while others prefer their space to solve the problem and throw it back out.

The following papers/books/documents are cited by the section of the book I'm reading:

• S.C. Wheelwright and K.B. Clark, Revolutionizing Product Development: Quantum Leaps in Speed, Efficiency, and Quality (New York: Free Press, 1992).
• F. Damanpour, "Organizational Innovation: A Meta-Analysis of Effects of Determinants and Moderators," Academy of Management Journal 34, no. 3 (1991).
• E.F. McDonough, "Investigation of Factors Contributing to the Success of Cross-Functional Teams." Journal of Product Innovation Management 17 (2000).

Answer 2

While you can have cross functional teams it also doesn't hurt to staff those teams with multiple part-time engineers. You could for example put Bob on project a and project b and also put Jane on project a and project b. This way they are distributed, however, if you have projects that are small enough to build out with just one software engineer, even this approach may have limitations.

Another option might be to keep the team structure the same but organize the work environment around function. Put all the software engineers together where they can collaborate in an open environment. This does go counter to some thinking and sometimes people get defensive when you take down the walls, but it might help to work in a bull-pen type arrangement.

The concept of co-working is based on this as well. Independent consultants and designers that would otherwise work in a home based office, move into a shared facility where they can feed off each others strengths.

There might not be much out there on these ideas, maybe you can pitch it to the teams involved as an experiment to get better productivity and satisfaction in the jobs. Then write up a white paper on the outcomes.