Reteam like you mean it

Illustrated by Matt Peet

Heidi Helfand kept encountering one idea that never sounded right: The gold standards for effective team building are stability and continuity. It showed up in readings on agile and scrum. Leadership coaches talked about it.

Yet when she assembled a coaching group at a startup company to make teams more effective, she scrapped that philosophy.

“It would have run counter to helping our company thrive,” Helfand says. “As a company grows and adds people—especially really fast—things need to adjust and change. Leaning into that change is important. Fighting that change is counterproductive.”

She theorized that successful companies can morph as they grow, and that a philosophy of static teams would do injustice to a dynamic environment with a thriving culture of learning. Reteaming—any change in how teams are constructed or organized—happens in every organization, from each new hire up to a new executive who rethinks everything. Some organizations adapt to the changes. Others capitalize on them.

So she conducted industry interviews about how teams change. She discerned five distinct reteaming patterns, which she writes about in her book Dynamic Reteaming: The Art and Wisdom of Changing Teams.

In addition to authoring that book, Helfand coaches software development teams using people-centric techniques, with the goal of building resilient scalable organizations. She’s currently also the Director of R&D Excellence at Procore Technologies, after serving as Director of Agile Coaching at AppFolio and Manager of Technology Project Management at Citrix.

In this interview, Helfand explores how her five reteaming strategies manifest in tech teams, and how leaders can consciously implement them in their development teams and organizations while listening to (and trusting) the people on those teams. She then ventures into how to make humane reteaming work by creating feedback loops from a team’s people, workflows and customers.

The simplest way to create a new team is to add or remove just one person. A team is essentially a system of people—and even just that smallest of reteaming shifts creates a different team system.

“People bring things to the team, whether a skill or a hobby or just personality,” Helfand says. “You can feel that things are different with or without them.”

The one by one pattern predominates when a company is growing or shrinking—teams hire bunches of developers in what Helfand calls “batch addition,” or companies decide to let people go in uncertain times. It also happens when developers transition between teams in an organization.

The pattern becomes more drastically noticeable during larger scaling or reduction events, though in most cases at most any scale, the changes are more incremental. “It’s reteaming at the edges,” Helfand explains. “New employees arriving is normal. We might not realize the degree to which our team is changing until, at some point, your team has doubled in size.”

Rather than allowing gradual change to creep up on organizations, tech leaders can prepare for the inevitable, universal needs of scaling teams. “We can proactively plan for the growth by strategic organizational planning.” Helfand says.

• Define career ladders and hierarchy. Structure will emerge whether we plan it deliberately or not—so she recommends getting out in front of it. “People are going to ask when they are going to get promoted, and what’s their career trajectory,” she says. “These things are normal and they are going to come up, no matter what company you’re at.”

• Ease the transition for the plus-ones. The people arriving on a team change the team for everyone else, but the experience is completely fresh for them. They have everything to learn. “You can make it easier when you add people by having mentors, buddy-system pair programming, familiar ideas like that,” Helfand says. “Always have a focus on bringing the new person up to speed and including them. Belonging is key.”

• Invite new ideas from new team members. Oftentimes, new team members feel reserved about sharing their ideas. They may not want to speak up out of turn or seem wrong or under informed. “But if we can encourage them to share, especially at the beginning when they have fresh eyes, it can help them feel more included earlier on,” Helfand says. “You get diverse ideas and thoughts when new people join, and you don’t want to shut that down.”

• Consider the experiences of the people already on the team. “Rather than only paying attention to the new person, you have to pay attention to the people who are already there,” she says. That goes for shrinking teams too, whatever the reason—a downscaling organization, or a splitting team in a fast-scaling one. “When everything changes quickly, that can impact morale,” she says. 

“It’s all about belonging,” Helfand summarizes. “Your organization is changing, so how can people feel like they belong in this new place? And, how can the people who are already there still feel like they still belong.”

Scaling teams requires new developers to take on the growing list of responsibilities. Yet the typical ways that organizations structure teams tend to break down when the teams grow too large.

“Inevitably, you reach the point of a rigidity trap,” Helfand says. “Things are slower. Work is unrelated. Meetings take longer. Things are just harder.”

Thus, the Grow and Split pattern recognizes that teams that were once efficient can outgrow themselves, and breaking those teams into faster, sleeker, more specialized units can prove beneficial.

• Put the decision to split in the hands of the people. Autonomous teams tend to recognize their own need to divide by mitosis. They want to work fast and avoid bogging themselves down. Helfand recommends enabling teams to conduct retrospectives and reflect on their structure and efficacy as a team.
  
  “The team works a certain way,” Helfand says. “They know each other. If the team has some autonomy over their design, they will recognize when it makes sense to split into new teams.”

• Lead these split teams into their new mission. This kind of reteaming usually comes with a division of responsibilities among the splinter teams. It’s up to leadership to help these teams launch after their split. Helfand coaches teams with such questions as, “What’s our mission? What are we going to focus on? Why are we this team, why do we exist, and what are we tasked with building?”

• Recognize that big teams are valid too. “Not all teams should split,” Helfand says. “That’s why I like to put the decision into the hands of the people, rather than have an external director saying they’re too big.”

She has worked with teams that everyone outside felt were too large. Yet these teams were still highly productive, delivering value to customers at an acceptable rate. Team members and customers enjoyed the experience. She believes that most functioning large teams work because they develop effective ways of facilitating their meetings. They’re generally well organized and have “glue people” who hold the team together. Some of them work with professional coaches, and many of them have highly effective managers.

When forces outside the team dictate when a team must split, Helfand likens their input to poorly done foreign aid. “You’re judging us from the outside,” she says. “You think we need this, but we’re good.”

Merging is the natural inverse of the Grow and Split pattern, where two or more teams combine into a single unit. When this takes place within an organization, it’s often intended to create greater flexibility and knowledge-sharing.

The Merging pattern also manifests in mergers and acquisitions, when teams must absorb one another, and people with duplicate roles often need to transition to other teams or companies.

• Combine teams when the org needs greater flexibility and less specialization. Helfand once worked with a company whose teams each took on strict ownership of a single tool. Yet at times, a particular tool would be lower priority—so the teams combined to form communities that each owned several tools and could adapt to shifting needs and priorities.

• Mentor developers through the natural difficulties of merging. The shifts resulting from acquisitions or mergers are drastic for team members from both companies. “Sometimes it really is horrible,” Helfand says. “People get laid off because their roles are duplicated or the organizational direction is changing. We need to talk about this stuff because it happens.”
  
  She turns to the book Transitions by William Bridges for guidance. “He talks about the neutral zone, that floating period where people aren’t sure if they do the same job anymore,” she says. “Where’s my place here? What am I supposed to be doing? You can get lost in this kind of space.”

• Help team members find their new beginnings. Even if the roles of the team members who stick remain the same, they are still reteaming to a new team system. Finding new beginnings is an extension of grappling with that neutral zone. “How can we, as leaders, make this time of floating and unease as small as possible, and get people to their new realities?” she asks. These transitions may have something to do with learning new hard skills—but these times call for strong support on an individual, human level. Even simple acknowledgment of the situation goes a long way toward creating a welcoming environment for the new team.

The first startup Helfand worked with, ExpertCity, aimed to create a marketplace for tech support delivered through screen-sharing. Sounded good—but nobody bought the product. So the company pivoted. They extracted a small team from the larger organization, including Helfand as a tech writer, and gave that team the freedom to work differently.

“We were told we didn’t have to do waterfall development,” she recalls. “We didn’t have to work with a pixel-perfect mockup. We just had to create functional mockups. Worry about the look and the feel later. It was hugely liberating.”

That isolated team created a product called GoToMyPC, which was acquired by Citrix and is still in use more than twenty years later.

“The Isolation pattern saved that company,” Helfand says. “Forming a team off to the side and giving them process freedom is good for emergencies, and it’s good for spurring new innovation. Processes grow so heavy as a company grows. It’s hard to innovate when you’re moving like a glacier. Taking a team off to the side and telling them they can do things differently leads to some amazing things.”

• Create isolated teams for both big projects and short-lived problems. Helfand’s encounter with the Isolation pattern at ExpertCity was tasked with creating a powerful, functioning product. The pattern is equally functional for fast-reaction solutions to problems like outages. Canonical processes may slow down that response; a hand-picked specialist team can move in, address the problem, and get customers using the product again—more efficiently, and often more creatively.

• Spread around the knowledge and maintenance to prevent messes. The bus factor is a measure of how many people would have to get hit by a bus (or leave the team for any other reason) to cause a significant gap in team knowledge. A pitfall of the Isolation pattern is that a small team off to the side, working outside the organization’s standard practices, may create specialized issues that no one else in the company knows how to work with.

Leaders need to foresee these potential issues and address them parallel to creating an isolated team. “You’ve got to do this with the people in mind,” Helfand says. “You’ve got to work out your contacts between teams, and you have to work out maintenance for the thing you’re building.”

Let’s say that a team is cruising along without any significant reteaming events. It meets its goals and produces value and everything seems great. Everything may well be great—yet it’s possible, even likely, that some developers will feel stagnant without enough challenges or change.

“Stagnation relates to the Switching pattern, where people feel like they are stuck,” Helfand explains.

Imagine feeling like you’re the only person who can maintain a team’s code base. You want to develop a new coding language or a new skill, but you can’t switch to another team to do it because you feel obligated to your current team.

“This leads to discussions about how we can have resilient teams,” she says—for which the Switching pattern is critical. It takes place any time developers move to other teams within the same company, extending their lifespans at the company and helping them grow, learn and find fulfillment in their careers.

• Learn what developers’ career goals and interests are—and locate opportunities to further them. Companies that create opportunities for technologists to switch teams improve retention of their most motivated employees. They also facilitate that motivation, the curiosity and hunger that drive so many creative professionals. “I love the idea of companies that give opportunities to change roles and do something different,” Helfand says.

• Facilitate deliberate switching to spread knowledge and build resiliency. During Helfand’s time at AppFolio, the organizational leaders realized that a single team was the only one handling several critical commerce features. That knowledge was siloed. They also recognized they should have more than one team capable of handling those features.

“They deliberately reteamed to spread that knowledge,” she says. “Later, when something would come up and we needed that knowledge present in multiple teams so we could act on it, we had that.”

Developing technologists and emergency-proofing companies are related approaches. “The Switching pattern is pretty cool, because people develop mastery, autonomy and purpose, which connects into ideas of becoming a learning organization,” Helfand says.

Based on these five patterns, Helfand’s research shows that the bulk of reteaming efforts spawn from an intrinsic motivation or need. Some reteaming events, though, are deliberate top-down affairs—and if they have very sound reasons for happening, they can work.

“They’re not about going in there, reorging these people and moving on without ever talking about how it went,” she says. “Reteaming education for leaders is important, because that’s how we develop a capacity to grow and change—and learn from it.”

Utilizing feedback loops is key to what she calls humane reteaming. Feedback loops help identify the reasons for change, and what problems teams need to solve. They also demonstrate results. Helfand looks for feedback loops in three places: the people, the workflow and the work itself.

“If you’re inclusive with the design of your reteaming and you get ideas from people on the ground, you have a greater chance of success,” Helfand says succinctly.

She tells a story about Spotify’s Director of Engineering needing to reorg a tribe. The missions were overlapping, and the engineering org needed to rethink its structure. So they visualized their reteaming plans on whiteboards—and then they brought in the contributors to collect their feedback and ask their help in figuring out a final structure.

Helfand reports that the leadership team learned this lesson: If you’re not involved in the technical work, you don’t have the clarity to make the best decisions. So it’s important to get the voices of the people who are doing the work.

She carries this inclusion a step further at Procore. A scaling company is going to experience multiple morphs, so she encourages retrospectives after each significant reteaming event to understand the experiences of the people and so leaders can apply what they learn for the future. This will look different at various companies, but she recommends ongoing engagement and pulse surveys at the very least to understand what it’s like for the technologists being reteamed.

“Individual contributors need their voice in the development of the organization,” Helfand says. “Their engagement, their excitement, their learning are key to the success of the company.”

The greatest organizational structure in the world will still be stunted by a poor workflow. Helfand stresses that tech leaders are in a position to help their teams’ workflows become more effective.

“Encourage your teams to visualize their work, and strive for stable cycle times. That is, the time between their work begins, and when it ships.” she recommends. “If you start there, you can leverage techniques like Monte Carlo simulations to make probabilistic forecasts for answering the question, ‘When will it be done?’. Every team has a responsibility to answer that question in order to set reasonable expectations on delivery with our internal customers as well as our external customers.”

Helfand and her colleague Tim Doherty give talks about managing workflows and scaling lean and agile metrics across companies to accomplish stable delivery cycles. She also advocates for managing workflows on a team level as well.

“Teams have to be able to collaborate,” she explains. “When their structure is changed from reteaming, they need to adapt how they operate. We need to coach them for effectiveness, for different workflow tactics. But none of that matters if we’re building the wrong thing.”

Perhaps the ultimate feedback loop for a team is the reception of the product. After all, no amount of efficiency matters if it ultimately produces nothing—and no contributors will feel intrinsically rewarded for their work if it never has the chance to make an impact.

“It comes down to, are people buying our software or service?” Helfand says. “Are we delighting our customers? Are we delivering continuously to them? You have to do your market validation and know that you’re building software that people want to buy.”

ExpertCity built GoToMyPC because nobody wanted to buy their original product. That pivot saved the company. It also saved the technologists, who got to contribute to something meaningful. And it obviously impacted more than two decades’ worth of customers.

“If you don’t build the thing that people want to buy, you’re going to fail,” she says. And building the thing has three components: “You need to have the customers. You need to deliver to them regularly. And you need people who are excited to come to work each day. You’ve got to focus on the people, or you have nothing.”

“You have to know how to plan and execute and learn from a large reteaming initiative,” Helfand says. “This stuff is not easy. So you develop a learning capacity to morph your organization continuously and develop resilience. And you have to put the people first. You have to include them. That’s the key. Be inclusive with your people.”

To that end, Helfand leans on conscientiously implementing five reteaming patterns that she gleaned from her industry research:

• The One by One pattern – adding or removing a single person changes the team system.

• The Grow and Split pattern – autonomous teams know when they need to split to run more efficiently, and when preserving a larger team makes sense.

• The Merging pattern – multiple teams coming together (either in-house or due to an acquisition) have to sort out their roles and positions, and leaders need to coach their people through the transitions.

• The Isolation pattern – splitting off teams to operate independently and differently can create quick, powerful and creative solutions.

• The Switching pattern – changing roles and teams can keep technologists learning and growing, and can spread knowledge and expertise throughout a tech organization.

A humane reteaming approach recognizes these patterns and responds to feedback loops in an organization’s people, workflow and work. The resulting environment develops both contributors and teams that can learn and adapt to suit whatever challenges lie ahead.

“Whether we like it or not, reteaming is inevitable,” Helfand says. “We might as well get good at it.”