Building a team – it’s an ongoing conversation
Putting a team together is the first challenge to any project. But the challenge does not end there. We all know how difficult it is to get something right the first time, and building a team is no different.
What can go wrong? And how do you adapt?
Wrong project description
Not all projects are well defined when they first begin. All too often a team is put together before the requirements are actually understood. But the team forms a bond, the organization is busy, and the team that scopes the project has to deliver it.
This can be a good thing. If the people who come up with the requirements are responsible for delivery then there should be a better chance of their delivering.
But it is just as likely that the team will reinterpret the project in lines with their own skills and interests leading to a misalignment between the project goals as seen by the client and the goals as seen by the team.
The best practice to avoid this is to separate the project into two phases. An exploratory phase that digs deep into the project goals and how they can be achieved followed by a separate delivery project. Ideally, the two projects should be given to different teams.
Of course this approach can add to upfront costs, and in most cases people just want to get to work. In some cases, the project goals are known, the requirements are clear and the process is mature. In such cases, the investigation phase can be skipped.
Wrong skills
Sometimes the team just does not have the skills needed. This happens for several reasons.
The requirements are so high level that it is difficult to tie them back to specific skills.
People on the team have exaggerated their actual skills.
There is a mismatch between two skill-sets (somehow a .NET and a Ruby on Rails developer have been put together to build the infrastructure)
The wrong skills failure point is not fatal if it is identified early and steps are taken to address it. For technical teams one of the advantages of the Agile approach is that skill gaps become apparent early and steps can be taken to address them. Sometimes this means learning, and sometimes a new person needs to be brought in. In any case, early action is the key. Business and creative teams can learn a lot from Agile software development.
Wrong chemistry
Great teams have ‘chemistry.’ They become more than the sum of their parts. And it is part of the work of the team to develop this chemistry. It comes from shared values, empathy, and an understanding of each other’s communication, learning and emotional styles.
Chemistry can go the other way as well. A team of really good individuals can fail to come together and be less than the sum of its parts.
It is very hard to understand this from inside the team. One can usually feel it, but it is hard to take action (that is part of the problem). The roots of team failure are complex and include clashing communication and decision making styles, incompatible emotional styles (and generally low EQ on the team) and divergent goals for the team.
The best solution for this is to make sure that every team has a coach, someone outside the team looking in, who is accountable for performance. For a management team it is the board of directors, or more realistically one or two people on the board. For project teams this can be unclear. There is usually a manager or client in the mix, but they are seldom positioned to act as a coach. The lack of an effective coach is one of the main reasons that dysfunctional teams are allowed to continue to spin on until they fail.
There is a great discussion of this in Patrick Lecioni’s classic book The Five Dysfunctions of a Team.
As the team matures
As people work together, often over a series of projects, the team matures. Maturity can be a good thing.
People adapt to each other’s communication styles.
People know each other’s strengths and weaknesses and adapt to cover for each other.
The team’s internal goals get internalized.
The team finds ways to survive.
But there are some bad things that come with maturity. (An adult is a person who has stopped growing up and started to grow out.)
Conversations with people outside the team decrease.
There is a loss of alignment with larger goals organizational goals.
Team becomes stale (loses touch with best practices, current technologies).
Team becomes focused on survival as its top priority.
How can we prevent a team going stale as it matures?
The best way is to change membership from time to time. A change is as good as a rest. And teams have to make sure they have strong connections outside of the team and outside interests. Diversity can help to slow down the deadening creep of groupthink.
The team that started the project is not always the best team to implement, and the team that does the bulk of the implementation work is not always the same people to drive to completion. In a future post, we will look at how teams need to change over the course of the project.
