Why not task based teams?

What I have learned about successful teams is the trust and the belief in the team’s mission. Trust in the mission, baring some issues like ill-fitting team members, etc. is the single most important factor for success of an individual, a team or a team of teams.

When the group of individuals that are part of the said team cannot see a mission they trust, going through the famous steps of Forming, Storming, Norming, and Performing will be harder. The mission is what the team usually communicate and collaborate on. And effectively going through FSNP stages is possible with communication and collaboration. The communication and understanding that forms between team members is what makes the team reaching the performing stage and becoming what is called a high performing team.

The concept of task oriented teams is floating around with different acronyms, one being the Quick Reaction Team, the miscellaneous teams, being project based team, fluid team, and so on. The whole concept behind it is a team that has no long history of having gone through the team formation and a long term strong mission to move toward to. It is usually working through a set of bugs and firefighting, or through disjoint projects that come into the pipeline.

Setting up successful development teams is hard! It is not only because people are different but also because organizations vastly differ from one another and thus one recipe won’t work for everyone and everywhere. I tried setting up teams with a similar approach with some teams focused on long-term work that required more research and prototyping and a team dedicated to quicker gains for the system’s customers. The quicker gains include bugfix or features with smaller scopes and higher demands.

The result was accumulated fatigue of never-ending context switching for the quick response team. Of course, there is always the gratifying feeling of what they have developed lands in so-called production but the feeling of accomplishment is not on par with the fatigue of the context switches. That was when I thought about rotating the team members between different teams with implications of time spent getting up to speed with the feature development and transfer of the knowledge context from the team member moving out of the feature development team and getting used to ways of working of the quick response team for the newly joined member.

It is possible to have a pool of engineers working together on different areas of the same bounded context, as long as the members that are coming together have already gone through knowing one another as team. But to pull seemingly random engineers between different knowledge/context in a project based manner may result in developing a feature but it will not result in positive outcomes long term.