# Dynamic Reteaming - The Art and Wisdom of Changing Teams ## Pitch 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
## Infographic

Dynamic Reteaming book infographic by Yoan Thirion

{% file src="/files/3yQuult66vK4MlFlUprh" %} Dynamic Reteaming book infographic by Yoan Thirion {% endfile %} ## Book notes ### Introduction * 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." ### Part 1: What is Dynamic Reteaming? * 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 #### Basic Definitions 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
#### The Social Dynamic of a Team * 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 #### The Politics of Team Assignment and Change 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

The Politics of Team Assignment

#### Survey the People to See if They Want to Change Teams 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. #### The People Decide the Team Membership * 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. #### Reduce Risk and Encourage Sustainability * 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 #### Reteaming Reduces Team Member Attrition by Providing Career Growth Opportunities * 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.* #### Reteaming Decreases Inter-Team Competition Fostering a Whole Team Mentality * 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. #### Reteaming is Going to Happen The thing is, sometimes whether we like it or not, reteaming is just going to happen. ### Part 2: Dynamic Reteaming Patterns & Stories * "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 * 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 * 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 * 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 * 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 * 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. #### Reteaming for Company Growth * 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

Examples of mentoring check-list

* **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 1. Why are you splitting the team? Being able to articulate that is helpful for the people who are involved. 2. The membership on each of the resulting teams after the split should be made clear to everyone. 3. Try to avoid sharing team members between the two teams. 4. Let people choose which team they will move into. 5. The work of each of the split teams should be separate. 6. Don't let the team split drag on forever. Choose a date on the calendar for "doing the split? 7. Consider coming up with new team names for each of the teams or engage the "new" teams to serve up their new team names. 8. Make sure any of your tooling is updated in advance of your team split event. 9. Determine the facilities implications for your team split. 10. Consider having "Team Liftoffs" or "Startups." Discuss how you want to work together as a new team. 11. 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

Two-Step Team Formation around Features, Themes or Outcomes

* **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 ![](/files/HIGjcGkeCZ97bfoY8PoD) * 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 for the Code * 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 ![](/files/VUJllRMzd5EGFZeyPEFT) * Reteaming to **Refactor** * Reteaming to **Share Production Support** #### Reteaming to Liberate * **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 #### Antipatterns - What Gives Reteaming a Bad Reputation 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 #### Constraints and Enablers * 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 ### Part 3: Face Reality & Get Good at Dynamic Reteaming > "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. #### Team Kickoff and Reset Activities
--- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://yoan-thirion.gitbook.io/knowledge-base/xtrem-reading/resources/book-notes/dynamic-reteaming-the-art-and-wisdom-of-changing-teams.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.