A team I have been working with recently had a crisis. The customer of their project had put everything on hold. In other words, the project was cancelled. The company had plenty of other work to be done so they were not worried about losing their jobs. The biggest worry for the team was breaking up.
Projects need teams?
It is a very common practice for companies to manage work into projects. Customers understand this and portfolio management, even management of larger projects, tends to naturally fall into divisions of projects. The difficulty is that companies naturally extend this into creating a project centric view of all process. What equipment does the project need? Which lab facilities are available for the project? Who are the resources with the right skills?
That last question is about people. When we think of people as “resources” and “skill sets” we start to see them as interchangeable parts of a machine that will work on a project. So we take a group of people, many who have never worked together, and assign them to a project and call them a team. Because, if you are on the same project, you must be a team, right?
Preventing a team
Teams need time to learn how to work together, to figure out likes, dislikes and strengths of each member and time to develop an identity and trust. These things don’t happen by declaration and don’t happen in one week or even one month. When these deep interaction attributes solidify, the group of individuals becomes a team. Great teams can take on whatever you throw at them!
The habit of swapping people in and out of teams is destructive to building these connections and high-bandwidth communication channels. Ester Derby points out some of these bad effects:
Plucking people off the team or poking people into the team causes a re-set in the team forming process. Mess with the membership often enough, and people will stop trying. When team membership feels like a revolving door, individuals won’t put in the effort to form team bonds. You may get a group that functions reasonably well, but you’ll miss out on the team effect.
It is surprising to me that we fail to see the cost of breaking apart a team. In the project-centric managing view, a project ends so the team gets split apart on new projects. And we throw away the investment we made over months of work, choosing instead to pay the cost of re-building a high-performing team.
Teams need projects!
If creating teams around projects is the bad for true teamwork, what do we do with teams and projects? The Agile Manifesto has an answer in it’s fifth principle:
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
Once you have a high-performing team, define projects that they can do. Work with your customers to create a project that your teams have already proven that they can build and impress people doing. The costs of dividing people and rebuilding trust, communication and capabilities is very high. And your teams who have learned how to act as one will be happier to know their joint contribution is valued.
By the way, that team who was afraid of breaking up had a happy ending. We figured out with management and company needs how they could stay together and continue impressing customers. It was a nice beginning to that ending!
No comments yet.