Teams Evolutions

Every company out there works with teams. There are all sorts of teams such as teams specialized in technology stack like Hadoop or teams which are domain-driven and have cross disciplines(Cross-Functional Team) inside such as backend, frontend, QA, UX, Architecture, and more. People don't leave companies they leave teams, also it would be accurate to say that people don't join companies and they join teams. So should we have dynamic or static teams? Should teams self-assemble or should we have PMO doing that? Should the teams be stable or should we allow dynamic reteaming? Is work always fitting well in our team's structure? What about Platform vs product teams, which one is best? Should we just pick one model or should we use different models? Should engineers organize around managers or managers organized around engineers? Teams affect Architecture and our perception of ownership. Teams should be a people organization but often is just a grouping of people where everybody is doing a different task, so why have a team for that?  How are we optimizing teams: Per Management, Per Domain/Product, Per Stack/Skill, or a mix? Why a team exists? Because there is a business need? Technical problem? Migration needs to happen? Because there is a line on the project management tool? How often do we reflect on the teams we are on? These questions are questions that we often don't think about and we should reflect on them on regular basis, maybe on a retrospective :-) 

PMO vs Swarming

Some people believe one of the reasons why we need PMO is to managed cross-team initiatives and also manage the lifecycle of the teams, meaning: when to create teams, when to split teams and when to add or remove resources. Others believe in Swarming where people can self-organize around work and actually choose where they want to be. 

Platform vs Regular Teams

Domain teams tend to be more generic and be able to deal with a higher range of technology. Domain teams do not mean you don't have specialists. IMHO people confuse Full Stack engineering with the team scope. It's perfectly fine to have specialists into Domain teams. You actually should consider specialists as an accelerator to make the team learn faster and also as a hiring strategy instead of just hiring for roles. 

Platform teams do not mean tech-only teams. It's also possible to have platform teams as part of the business, which is a normal and valid strategy. If you have a high demand for specific technologies like IoS or Cassandra for instance, it might justify why to have a big pool on specific technical stacks, however, stability and team demand tends to shift to different areas and stacks. 

As work needs and demand evolve, because the business is changing or because we are fixing problems and therefore we need to focus on new and different problems that force tension into platform teams. Actually, this tension happens for all teams. 

Stable Teams

One of the classical team models is Tuckman's: Forming, Storming, Norming, and Performing.

However what Tuckman's is missing is the fact that change happens and teams need to change, either because the work changed by nature or we fixed all the problems or because people dont want to do the same work anymore, they want to perform in a different role or they want to play with different techniques. It could be for several reasons, personal, relationship, career focus, but people will change. So how much are we optimized for people switching teams? Heidi Helfand was this amazing and interesting book called: Dynamic Reteaming which covers the fall of the teams and the alternatives to deal with reteaming in a natural way.

Dynamic Reteaming

Heidi's Dynamic Reteaming theory and practical work challenge the traditional Tuckman's notion of stable teams and take a different route by basically accepting that change is normal and maybe we should optimize for reteaming. There are 2 interesting side-effects of that, the first is retention. With reteaming you might be able to retain people longer, the second one is about knowledge sharing. Having regular rotations and team switches make knowledge exchange more often. 

Most teams have onboarding issues, sometimes is very painful for new team members to join a team. That pain could be for many reasons like lack of business understanding, motion issues(how to find information to perform work), lack of understanding of internal rules and rites. By having more dynamism it forces teams to be better at taking new members since it might happen often. 

Heidi has an interesting point of view on teams which is called the Rigidity trap where you want to about that because is just downhill and really moving people or letting people could actually is the best outcome. So you really dont want to force people to be married to teams beyond some point otherwise that could be bad for everyboddy.

Heidi also talks about patterns for reteaming such as One by One, Grow and Split, Switching, Merging, and isolation. In one of her presentations, she proposes using Open Spaces to make people found causes and form teams from that. 

Team Charter

Aaron Dignan from the amazing Brave New Work. Proposes a Team Charter in order to address the purpose of teams and also figure out how the team should work. On the team Charter Aron purpose, we think about, questions like:

Why does this team exist?

How do we contribute to the organization’s success? What are we accountable for?

What is our essential intent for the next few days? How will we know if we’ve succeeded?

What principles will guide us?

What will we prioritize for the next few days? What are the roles required to do this work?

What roles will we each play?

Are there any roles not yet claimed?

What do we expect of one another?

Who are our users or customers?

What decision rights do we have?

What can we do without asking permission?

Within what guardrails do we have autonomy?

Are we responsible for anything that we don’t control?

How will we make decisions?

What resources do we control?

What is our meeting rhythm?

How often will we conduct retrospectives?

What tools will we use to communicate and coordinate?

How will we share our work with one another and the organization? What are the learning metrics that will help us steer?

How will we know if we’re making progress?

Wrapping up

IMHO having a charter is great but one of the big problems I see in teams is the lack of retrospectives. So if you dont talk about the problems how do you suppose to fix them? This leads me to a previous post I wrote some time ago about management, are we managing people or the work? If the teams are optimized just to control and manage people that would explain so many problems and issues. 

As we switching gears to manage work not people(Kanban principle - manage the system) we might see reteaming as a natural thing to do since people are not your resources and they should move as work moves. However, we tend to couple careers and work together so the same BOSS who is a career boss is the work boss. IMHO have the same boss for everything works very well. Maybe we need to switch bosses more often or have promotion committees like google does to neutralize politics? One way or another is time for us to evolve, treat people like groups and see the team's evolutions as normal and optimize for different dimensions than management.

cheers,

Diego Pacheco