Dynamic Reteaming - The Art and Wisdom of Changing Teams
by Heidi Helfand
Last updated
by Heidi Helfand
Last updated
Your team will change whether you like it or not. People will come and go. Your company might double in size or even be acquired. In this practical book, author Heidi Helfand shares techniques for reteaming effectively. Engineering leaders will learn how to catalyze team change to reduce the risk of attrition, learning and career stagnation, and the development of knowledge silos.
Based on research into well-known software companies, the patterns in this book help CTOs and team managers effectively integrate new hires into an existing team, manage a team that has lost members, or deal with unexpected change. You’ll learn how to isolate teams for focused innovation, rotate team members for knowledge sharing, break through organizational apathy, and more.
You’ll explore:
Real-world examples that demonstrate why and how organizations reteam
Five reteaming patterns: One by One, Grow and Split, Isolation, Merging, and Switching
Tactics to help you master dynamic reteaming in your company
Stories that demonstrate problems caused by reteaming anti-patterns
Dynamic Reteaming a.k.a. team change.
"Our teams are more like moving targets than unchanging entities. Its time that we acknowledge that team change is real and that we share stories and ideas for how to res good at it and dominate it - the essence of this book."
Whether you like it or not, your teams are going to change
People will join your team, and people will leave your team
Recognizing team change as a natural occurrence is a key point of this book
In essence, team change is inevitable, so we might as well get good at it
The essence of Dynamic Reteaming
It is defined as a myriad of changes catalyzed or occurring on multiple levels, for multiple reasons, and expressed in multiple patterns
Five underlying reteaming patterns
What is a Team?
A team is defined as at least two people working together
To build something valuable for their customers
What makes them a team : shared work and the joint ownership of the outcome
If they are both responsible for the outcome, then they are a team
If they take responsibility for their joint work, then they are a team
What is Dynamic Reteaming?
Dynamic Reteaming is when you change your team's composition
It creates a new team social dynamic / a new "team svstem" or "team entity"
The new people added to the team bring their interests and talents to the mix
Impacting the collective intelligence present on the team
They bring new learning potential to the team as a whole
Reteaming helps teams learn together and expand their skills
Reteaming done well takes great care and respect for people into consideration
What is a Group?
Groups are collections of people that work at the company
BUT they are assigned across different teams
Individuals might share a director or manager in common who gets them together regularly as a community of practice in order to spread similar ways of working across their impact spheres
Each team in your organization has its own unique social dynamic, or "feel?
This dynamic changes over time
High energy might suggest the team has chemistry and high performance
Low energy might suggest the team lacks chemistry and high performance
The bottom line to Dynamic Reteaming is kind of like some Kanban recommendations
Start where you are
Visualize your team structures
Observe and get to know them
Agree to pursue incremental reflection and adjustment to your teams
Experiment and learn
There are different ways that people arrive to their teams and later change teams.
Some companies are open to having the team members decide where they go
A humanistic approach to team assignment takes the interests and learning needs of the person into account
Sending out a survey to team members is one way to find out if people need a change in order to feel more engaged at work.
Dan Pink talks about autonomy, mastery, and purpose
Having autonomy means choice over :
When people do work
How they do it
Who they do it with
What they do
Being able to develop mastery in work might include the ability to get better at a subject area and the focus on continually learning.
Having choice over purpose of work includes the ability to contribute to a cause that is greater than themselves.
Every six months or so, they run a reteaming event via self selection.
Reteaming Decreases the Development of Knowledge Silos
The notion of "bus count" or "bus factor" is not new in the software industry,
If you increase your bus count, which is the number of people who know about something - like a specialized technology in your company - you are safer
If one of those people leaves, someone else knows enough about the technology to carry it on into the future, hopefully with not too much pain.
Building in redundancy of knowledge, which is better for your company - kind of like a group memory.
Within a team
Pair programming and test-driven development (TDD) are ways to facilitate a more effective "bus count" within a team
The quality of interactions on the bus matters !!!
On a team-to-team level
You can reduce the development of knowledge silos by reteaming
Spreading knowledge out from one team to another
Your organization can become "stickier" for people if you acknowedge their growth
And change by providing them opportunities to learn from other people through reteaming and re-roleing
At AppFolio, engineers had the opportunity to switch into other teams from time to time to provide anti-career stagnation.
You decrease the notion of "us" versus "them" with reteaming
Reteaming helps to reduce inter-team competition via its ability to help teams build empathy for each other.
The thing is, sometimes whether we like it or not, reteaming is just going to happen.
"WHY" of reteaming :
For company growth
For the work
For learning, fulfillment and sustainability
For the code
To liberate people from undesirable situations
Five structural transformations, or "base patterns" which are :
One by one
Grow and split
Isolation
Merging
Switching
One by one solves the problem of growth
How do we integrate in the "new people" when our company is growing fast, maybe doubling or tripling in size?
To "do" one by one reteaming, you
Add a new team member to an existing team
Or you remove a team member from a team
Grow and split solves the problem of teams growing "too big"
As it sounds, when there are "too many" people on a team it can become inefficient
Therefore it is common to see these teams split into two or more teams
You can also apply this pattern in an attempt to spread "best practices" across your organization by
Conservatively adding in people to a stellar team
Then splitting the team later
When you feel like all team members have mastered the techniques you want to spread
Isolation solves the problems that come up when you have emergency situations
Maybe your product is failing and you need to pivot in order to survive
Maybe vou have a performance crisis, or an outage
Isolation creates beneficial silos by design
You form a team "off to the side" and give them process freedom
Merging solves the problem of teams that are too small and they need more people to have collaboration opportunities like pair programming
Teams might merge as a strategy to combat dependencies across two or more teams
Switching solves the "tower of knowledge" problem or "low bus count" problem
When you have team members working a lot on their own
And you decide to incorporate reteaming to spread knowledge within or around your teams
"Nomading" is another variant of switching
It is when a member of one team joins another for a short period of time, and then returns to their original team
If you keep your teams together for "too long" the energy level might decay, and your team might fall into a rigidity trap using ecocycle terms described earlier in this book.
When our companies grow our teams change
New people are added to the mix
How this happens can be planned deliberately.
Several strategies for growing fast while still holding it all together : `
One by One Pattern
The addition of one person to a team or the removal of one person from a team
This "adjustment at the edges" can be a less risky team change pattern, especially when combined with well-organized mentoring
Ex : At AppFolio :
Assign a specific mentor within their team
A deliberate way to grow the skillsets of all the engineers working at the company
You learn by teaching and mentoring, and you learn from being taught and mentored
Writing self-testing code was an incredible accelerator of learning at this context
The mentor was essentially the new hire's personal learning guide to how the engineering environment worked at the company
Tactics for Onboarding New Team Members
When you add just one person to an existing team, you probably do not change the name of the tea
But you really have a new team system
This person brings with them their :
Personality
Skills
Character
And overall "presence" that wasn't there before
Make it Known That You are Hiring in New Team Members
If you plan to expand the team, you should have a deliberate conversation with the team about that topic
People need to know that you're looking for more people
They can play a part in helping to recruit this new person
This is one way to expand the ownership of the change
Plan and Communicate about the Arrival of the New Team Member
Feels awful if you start at a new job or a new team and you don't have a place to sit
It feels even worse if you start but people don't know you're supposed to be there
Get Things Together for the New Person Before They Arrive
Order key books that illustrate the philosophies you want to promote in your environment
Have them ready for the new person
It makes a great first impression when you arrive on your first day and people are over prepared for your arrival!
Assign the New Person a Mentor Who Will Exclusively Pair Program with Them for a Few Weeks
The new person should ideally be sitting next to their mentor
The mentor and the mentee should have a checklist of things to go over in order to get the mentee up to speed
Hiring & Onboarding to Reduce Surprises Later
Having parity or consistency with
interview practices
onboarding practices
actual development practices
is valued
The mindset of having psychological safety and driving out fear is also present in the onboarding process
At Menlo
Use of visuals like posters on the walls :
Anchor to the core values
Then act accordingly
It's okay to say I don't know?
And we expect that from you
"We are not going to let you fail. Our job is to help you succeed."
At Pivotal Cloud Foundry
Hire : RPI or Rob Pairing Interview
Rob = CEO
A fairly objectively-scored pairing session with the candidate
Looking for the ability to :
listen
learn
ask questions
be empathetic
show an aptitude to learn
Bootcamps and Network Formation
New Hires Are First Together and then are Dispersed to their Teams
Guidelines for When Teams Grow and Split
When teams grow too big, some guidelines
Why are you splitting the team? Being able to articulate that is helpful for the people who are involved.
The membership on each of the resulting teams after the split should be made clear to everyone.
Try to avoid sharing team members between the two teams.
Let people choose which team they will move into.
The work of each of the split teams should be separate.
Don't let the team split drag on forever. Choose a date on the calendar for "doing the split?
Consider coming up with new team names for each of the teams or engage the "new" teams to serve up their new team names.
Make sure any of your tooling is updated in advance of your team split event.
Determine the facilities implications for your team split.
Consider having "Team Liftoffs" or "Startups." Discuss how you want to work together as a new team.
Get the team itself to "own the split, if possible.
Reteaming for the Work
Another reason that companies reteam is due to the work.
The new work is the inspiration for the team change.
Isolation Pattern for Pivoting & Innovation
Form Teams and Reteam Around the Work
Two-Step Team Formation :
First, engineering and product leadership identified a "triad" of key team members
This triad consisted of :
A product manager
an engineering representative
A UX designer
Second phase, team members were added to the triad based on the needs present for developing out the particular feature
needs were identified when the triad created an opportunity canvas, which is an analysis tool
Reteam when "Overloaded" with Work
Sometimes new work is what spawns brand new teams or reteams of existing teams.
It can be a healthy expansion of your organization to spread out the new work to avoid overloading existing teams.
If prioritization of work is not clear, people can suffer.
In this scenario, people multitask.
Reteaming for Learning, Fulfillment, and Sustainability
Engagement at work can happen when you are intellectually stimulated and are able to continually learn in your job.
Finding a new team situation where you are with completely different people
working on completely different things in order to refresh your focus
Switching pattern
When you switch within a team or across teams
We switch to share knowledge with each other
The aim is to spread out the knowledge for learning and sustainability
We Want to be with other people and learn from them.
Switching Teams to Support a Feature
We made the deliberate decision to spread the knowledge of this business domain to another team.
Rotating Developers for Friendship & Pairing
Sad that they could no longer pair program with their friends who were now on "other teams
Regular rotation of one engineer from team to team in order to address that concern and to provide more fulfillment to these engineers.
Get a bigger team mentality
Switching for Personal Growth & Learning
It's nice when people aren't stuck in one team forever and we view people with a growth mindset as opposed to a fixed one
Empower People to Re-Role
If we are flexible in our organizations
We can enable people to work in different roles
It can make your organization stickier and help you retain people
This makes your organization more sustainable because there is less turnover.
When you switch pairs, or teams for that matter, you are exposed to new people and new ideas. You just learn more. That feels good to us as humans.
Reteaming for Short-Term Events
Short-term events is one way to build Camaraderie amongst your workforce in a larger sense
Daily Learning Sessions
one hour of mob-style learning each day
seven hours of learning for the team each week
Awesome way for people to build important relationships cross-team
If you encourage your employees to teach each other, it can really stimulate a culture of learning and help build respect between team members.
Developer Exchanges Between Companies
Reteaming to Solve Emergencies
Product wasn't fast enough to release to customers.
We decided to tackle that problem, and that is where the reteaming came in.
Isolation Pattern
A spike is a special research story that comes up from time to time in teams.
timebox a certain amount of days or hours to do this research
Scale the isolation pattern
Reteaming to Refactor
Reteaming to Share Production Support
Silenced People Could Be a Sign for a Reteam
It's not intentional, but when your teams get big, less people talk in meetings.
Unless you have some creative facilitation designed to draw people out
We hear that the best teams should be stable
That gets misinterpreted to mean "keep your teams the same" ?
When people are kind of like "prisoners in meetings"
it can feel very liberating to them to not have to attend the meeting anymore
People won't necessarily speak up and suggest a reteaming
Reteaming to Find a Better Fit
When People Leave You Have a New Team
Some stories that share the darker side of reteaming, or what makes some people fear reteaming.
Reteaming To Spread "High Performance"
"team shuffle" to spread out best practices amongst five to six teams
Best practices are the most important thing
Instead, to him, high performance is more closely related to having a good dynamic on a team as opposed to how they go about doing their work
Not Dealing with Toxic Behavior
Think of the behavior you have seen in the past
When you were working with someone, and their action or inaction caused severe obstacles to getting things done
Maybe they were :
Arrogant or verbally abusive
Insulting or abrasive
Passive aggressive and hoarded information
Toxic behaviors are a threat to the attention and focus of your team
Toxic people usually lack HRT : Humility, Respect, and Trust
Collaboration Dynamics
How team members tend to collaborate with each other impacts the ease or difficulty of their reteaming.
Coding Alone: The Tower of Knowledge Problem
"Heroes can't scale."
They can neither scale up nor down
You can't go to zero heroes or you lose all the knowledge
Pair and Mob Programming with Test Automation Makes Onboarding Easier
Mob Programming Enables the Continuous Integration of Ideas
Has also been described as a "continuous conversation" by Jason Kerney
"Ideas are coming from a bunch of different points of view at a bunch of different times."
Mob Programming Brings Technical Consistency and Facilitates Reteaming
Variables That Impact Dynamic Reteaming
Platform : when changing teams, will the person be working on the same platform (like iOS, Android, Web) or will they be switching to a new one?
Reteaming is a forcing function to learning.
Programming Language : when changing teams, does it require the person to learn a new programming language?
Choice in the Matter versus Being Forced to Change Teams : As individuals, some of us want less change and some of us are open to more of it.
Mindset about Growth and Learning : if we feel that we are people that have the ability to grow and change and learn on the job, versus having the fixed mindset of not having the ability or capacity to do that.
Single Specialist Roles on Teams versus Full Stack Roles/Generalists
Encouraging people to be T-shaped is part of this discussion.
Collective Code Ownership versus Strict Code Ownership
When the teams share ownership of the codebase, you have a lot more liquidity in the organizational design.
Age of the Code
Test Automation or Lack Thereof : feel safer in making changes to it because we will get feedback on whether we have broken any tests or not when we commit changes.
How the Team Collaborates - Soloing, Pair Programming, Mob Programming
Co-Located Teams versus Remote Teams, or Hybrids : not only co-located, but also co-seated.
Complexity of the Domain: complex business logic and you do not know that in advance
It will take longer to get up to speed when you reteam
Management : When changing teams, will the person keep the same manager or have a new manager?
Familiarity with the People on the Team Already
"Reteaming is inevitable, you might as well get good at it?"
Cultivate Community to Prime for Future Reteaming
When you know and care about the people you work with, everything else is easier
Give the people a shared social experience together
This increases positivity in their team relationship in advance
Design Events to Build Relationships Across the Organization
Taking epic trips together with your teams is something that you'll never forget
It brings people together in a strong way
Hold Educational Offsites to Sharpen Skills and Strategize
Give Teams Budgets to Create their Own Social Events
Have money budgeted to use for celebrating key milestones
Acknowledge successes
Bring Remote Workers into the Office and Send Team Members to Them
Create Opportunities for Teams to Get To Know Key Leaders in Different Departments
Events called "coffee chats" with key leaders in different parts of their organization
such as "the chief marketing officer, VP of the product group, or key product owners."
Reflect on Team Compositions and How to Shift
Reflecting on how things have gone in the past in order to derive the ways we want to change going forward is at the heart of being a learning organization.
Retrospectives
Team retrospectives : often
Retrospectives with Groups of Related Teams : When you have multiple teams that work in the same area of code
Systemic Retrospectives : having retrospectives with different groups of people in our organization that are working together on something for a designated time period either long or short.