Five approaches to team design
At TeamFit, we are deep into the design and development of our TeamBuilder module. TeamBuilder is used to find the best people for a team and will be released later in June. So we have been talking to a lot of people about how they go about building teams. No doubt, there are as many approaches as there are situations and that doesn’t help us make design decisions. We have boiled things down to five basic patterns. Are these patterns that you see in your organization? When do you think each pattern is most likely to be used? What are the best practices?
We started our work with a deep dive into how project teams are built at organizations. We reported early results in this blog post “How does your firm manage allocations?” Basically, we found some clear patterns in who was responsible for building teams:
Senior leaders (Vice President of Professional Services, Practice Leaders or their direct reports);
Specialists often known as allocators or resource managers (there are big differences between companies where this is basically an administrative function and other companies where it is a leadership track position);
Project Managers (a common pattern in smaller firms)
Scramble (or if you prefer, ‘self organization’)
We continue this work in this survey (open until the end of June).
These are important insights into the organizational structure but they did not give us the information we need on the processes that people actually use to perform the work of defining team requirements, finding people for the team, and then making the selections and building a bench.
We have found four basic patterns in how people get assigned to teams, plus a fifth in which the other patterns are applied in a parallel, organic process: people-based; role-based, skill-based, goal-based. The fifth pattern is a more organic process in which the design of the team emerges from conversations. This is most often seen in company cultures where people scramble to get on teams.
People-Based Team Building
This is most common in small companies. One looks at the people available, their skills and experience, and figures out who needs to do what. In fact, this is what we do at TeamFit and what I have seen most early-stage or small companies do. When people know each other well and have rich networks and experience, this can work well. But it is almost impossible to optimize, is dependent on the people involved, and it does not scale beyond 7-12 people.
Role-Based Team Building
One starts with the roles that will be needed on the team. Then one assigns skills and experience requirements to these roles. Some people start with experience and go to skills as is shown below, others start with skills and then look to experience to validate those skills). The time and effort needed for each role are also estimated and a rough schedule worked out. The scheduling and dependencies are generally done in some form of project management software. The search and selection process are handled off line.
This appears to be the most common pattern in mature organizations. It seems as though many of us are more comfortable slotting people into roles than in seeing them as having a collection of skills. And we often have strong pre-conceptions of the skill sets and experiences associated with specific roles.
Skill-Based Team Building
In this approach the team builder begins with a loose set of skills and experiences. Based on the skills required for the project the roles are designed to match the unique requirements of projects. Roles are designed based on the skills requirements and one often gets new or hybrid roles. As the skills requirements for a role become overly complex we often see one role divide into two. One can see this happening today, as it is becoming clear that User Experience Design (UX) is a fundamentally different role from User Interface Design (UI) and in fact there is relatively little overlap between the two skill sets. See “The Difference Between UX and UI Design – A Layman’s Guide.”
Goal-Based Team Building
One starts by listing the goals and then the skills needed to actually deliver on these goals. In companies with a strong project management culture, the goals are often framed as a set of deliverables, and when the project is being done for a client this is often the best way to map from the statement of work (which normally spells out the deliverables) to the requirements for the project team. Some advanced practitioners actually map these to their project management process, be this agile, waterfall or something in between.
Open Team Building
This pattern is seen most often in teams pursuing open-ended projects, where there are goals but the deliverables that will emerge from the project itself. The best design thinking projects take this approach. As to other innovation driven projects. When innovation is the goal, the deliverables are one of the things that gets design.
We have decided to begin by supporting role-based team building and see what we learn from you, our customers. Here is a sketch of what we are thinking. Let us know how you think this will work in your world.
We are doing ongoing research on the real way people design teams. Let us know if you are interested in contributing this, or if you have thoughts to share. We are interested in better understanding
How teams set goals and map these to deliverables
How teams are designed
How people get chosen for teams
What team building processes and team designs work best in different cultures and situations
