Cross-functional teams are a cornerstone of agile methods. But work groups and departments organized functionally are more prevalent organizational forms. Trying out cross-functional teams is usually straightforward enough: you recruit a talented group of individuals who are willing to try new things and you run a pilot project. But when your pilot shows promising results and obtains buy-in to organize cross-functional teams at a larger scale, things may become much more challenging!
The primary challenge in scaling the use of cross-functional teams is that a functional organization with a small fraction of cross-functional teams is a stable form, and an organization of cross-functional teams with a small fraction of functional teams is a stable form, but gradual transition between the two states is fraught with frustration and counter-productive side effects. This article describes a step-by-step method for forming cross-functional teams that is rapid, relatively painless, and balances self-organization with managerial decision making.
I have used the “casting call” process to design up to fifteen cross-functional teams in a matter of weeks. Formation of those teams has gone smoothly and the teams have performed well once formed. The following five steps describe the process.
- Begin with the work you have. Describe and organize the work your set of teams must accomplish. What this work looks like may differ a great deal from organization to organization and within an organization over time. For example: a product development organization may be focused on one large release or initiative, but once that project completes, the work may split into multiple streams for customer enhancements, technical support, and research and development for the next big initiative. In any case, start with what you know and your best set of assumptions about what you don’t know. If you can’t see very far into the future use the work of the recent past as a guide.
- Define the teams that you need in terms of knowledge, skills, and experience. This step is probably the most difficult one since it encapsulates most of the hard decisions related to forming cross-functional teams. Fundamentally, you need to decide what kind of teams you want to have (component or feature teams for example) and how you define the products or business processes to which you will align your teams. The key to this second step is keeping definitions at the team level in terms of skills, knowledge, and experience. For example: a team might require strong expertise in a particular business domain or specific technology, user-interface design skills, and Java performance-tuning skills. My experience has been that things will go much faster at this step if you keep specific team-member names out of the discussion and avoid succumbing to the temptation to divide up the existing teams and team members.
- Describe team attributes. Having described the work streams you expect to have and the ideal knowledge, skills, and experiences of teams that can deliver those work streams, you can now describe the attributes of the teams you need. Examples may include business domain, primary technologies, location, and whether the team provides reactive support and maintenance or works on new development projects. Team attributes should cover the aspects of the teams that are relevant to their prospective members.
- Take your show on the road! The next step is to obtain feedback on the work streams, team definitions, and team attributes – before aligning individuals to any specific teams. Depending on the size and geographic spread of your organization, some form of road show presentation usually does the trick. Be sure to visibly capture all the various ideas and criticisms. Then get your design team back together and see how you can make things better based on the feedback you’ve collected. Where you reject or don’t use specific suggestions, be sure to document the reasons.
- Match individuals to teams based on individual preferences and team attributes. Note that you aren’t asking people which team they want to join right now. You are asking them to rank their preferences for the kind of team they want to be on based on attributes of those teams. If you simply ask individuals to choose their favorite team you are running a popularity contest that collapses everything into one dimension and deriving no information that will allow you to tune things now or in the future. Not only will some number of people obviously get their second or third choice, you won’t learn very much about what people value – and neither will they since they haven’t been forced to reflect on it. But if you ask people whether it is more important to work as a Java developer or as part of a business intelligence team, now you’ve got two variables to assess and the individual has expressed a preference.
Exposing preferences provides the power of the casting call process. Being part of a team isn’t about every individual doing everything she wants to do all the time it is about a group of people achieving more than the sum of their individual parts. Designing multiple teams is hard because you must make trade-off decisions along multiple dimensions. Asking prospective team members to make the same type of choices puts everybody in the same difficult decision space. Though it may seem paradoxical, it can then be easier to satisfy a plurality of individual preferences on multiple dimensions than when you have fewer dimensions and less data to work with.
Exactly how you implement the above steps depends on the size of your organization and its culture. A survey may work best in a larger or more formal organization that values objective data. In a smaller organization you may be able to move more nimbly by organizing a series of workshops or even accomplishing all the steps in a single workshop. Whatever the approach, keep in mind that the participation of many individuals from different roles is what creates buy-in.
Even if you are very successful in designing stable, productive cross-functional teams, things will eventually change and you may want to re-run the casting call process. People will come and go, your business may change, or you may get better ideas for how to structure your teams relative to the work that needs doing. But even if none of these things happens to any great degree, people will change – both as a function of the work they do and what they learn, and as a consequence of life events outside work. This is where the flexibility of a people-centric approach to team design really shines. Consider the example of a highly skilled and highly-motivated developer. When that developer also becomes the father of young children, working long hours with late-night conference calls to India in the name of shipping the latest product may become relatively less attractive, but when the children enter junior high school and saving for college becomes an imperative, priorities may align differently again. Agile methods embrace business change. The casting call works will because it also embraces the changes that happen in the lives of team members and the personal and business changes that they want to make for themselves and the organization.
Encouraging reorganization based on the collective choices of workers may seem radical to some managers, but it doesn’t have to be. With a step-by-step approach managers can control as much of the casting call process as they wish to. For example, in matching individuals to teams, managers may choose to override the expressed preference of an individual whose self-assessed readiness for a new role differs from their own judgement. Even when this does happen though, the nature of the decision-making conversation changes from one based on power (who gets to decide?) to one based on facts and information (why should we decide that way?; what are the trade-offs?; have we considered all the evidence?). When the process is working effectively, managers will find that they have finer-grained control than in the past about how to match individuals to teams but that they don’t need to exercise control all that often.
