Reteaming to Spread “High Performance”

If a team has great chemistry and high performance, the team members are engaged. They are delivering incredible value at a good cadence while delighting customers. Keep them together until the people are ready for a change. Then, when you do change the teams, you might just do it “at the edges of the teams.” Jon Walker, CTO and cofounder of AppFolio, learned this lesson in that company’s early days. He had the desire to spread out the high performance of one team across multiple teams.

He said, “I remember specifically a team that had a lot of really experienced people, and we got a bunch of new people in, and I broke up that team. I regretted it afterwards. It was a highly functional team. They were doing great work. They were excited about what they were doing. Then we split them up, and we ended up with three pretty good teams when we had one great team. Maybe we would have had pretty good teams anyways without doing that.”¹ Jon was trying to “load balance” the seniority across the teams. It made sense to him theoretically, but it came at the expense of team chemistry.

A story related to this idea of spreading out the high performance among teams came up in another interview with Damon Valenzona. Damon is an engineering director in a different location of the company, who told me about a “team shuffle” that they did with the intention to spread out best practices among five to six teams. The idea was to have a better balance of junior and senior team members across all teams, so juniors could witness what it was like to be a senior team member. It’s hard to explain on paper the difference between software engineer levels like these: software engineer, senior software engineer, staff software engineer, principal software engineer. Sometimes by being around people at these levels you can learn the behaviors that are valued as a way to understand how you can “level up.”

For this “shuffle,” which was really a reorg explained more lightly, they had kept about two team members the same across the different teams for continuity of work context. But, the rest of the team members changed, which included on average a product manager, QA engineer, UX designer, and three software engineers.

The result of this shuffle was similar to the case of Jon’s reorg mentioned previously, and the chemistry of the teams suffered. I spoke with Damon three months after the shuffle, and he said, “One of the goals that we didn’t even come close on was to make all the teams more efficient. Shuffling is a way to share best practices, but it takes a lot of storming on the team to get to norming, and those don’t kind of come to fruition pretty quickly. So, I think a lot about team efficiency is the chemistry in a team and not necessarily the best practices. I think it’s easier to share practices across teams. It’s harder to get good chemistry on a team.”²

He went on to share his learning from this situation: “I think our assumption was a little wrong that we take an engineer from our effective team that will share the best practices, because I don’t really think the 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 it goes about doing the work. In his words, “What I found is that really what you’re trying to do is create that good dynamic on the team and not necessarily the practices, because the practices can be different, and that’s okay. But when you shuffle, you basically mix up all the dynamics and then have to figure out a way to work well together again.”

The learning here is that when you reteam the dynamics “extensively” across multiple teams, it’s going to take time for the teams to get into a flow again, and you don’t know what the chemistry is going to be like for a while—especially if the people don’t choose their own teams. It’s less risky to make minor changes in team compositions.

Jon, who played college basketball at Westmont, a private college in Southern California, compared it to sports teams: “If you hear professional athletes, like if a team wins a championship, and they’ve got a bunch of players who can be together for a while, they’re like, We’re trying to win as many championships as possible and keep this team together.” Further, he talks about adding in people gradually: “If you’re almost winning a championship, try to add little new pieces. If they’re far away from winning a championship then totally break up the team and start over again.” We gradually added people to teams for years at AppFolio as a growth strategy. This reteaming at the edges brought in new perspectives and was less disruptive to teams as a whole.

When the chemistry is working, and the teams are delighting customers, you might think twice when attempting to reteam to spread the high performance.

The examples shared here involved busting up entire teams in order to spread out the high performance (or in one case the seniority). Trying more of a “reteaming at the edges” approach is something to experiment with. When one person comes in or out of a team it’s less disruptive than completely disbanding teams.

If you have a team that you consider to be doing very well, encourage the members to do a “tech talk” to share the ways that they are working with other teams in your context. Great companies I’ve worked at have encouraged engineers to do weekly tech talks that last no more than an hour. And if it’s during lunch, you can get food for everyone as a draw—but that’s not even necessary.

You could also encourage teams with practices you want to spread to write blog posts for the company. I pair with engineers at Procore more and more often to catalyze blog posts. Maybe hearing from peers will influence others to try things out.

Team coaching is another avenue to explore. Teams need to own their improvement efforts so that they care about them. We may read that the best way to work is via pair programming, for example, but you can’t just force teams to do that or you will create other problems. Encourage teams to reflect on how they are working and to determine an experiment to run in order to become more effective. For example, when I coach teams to have greater workflow effectiveness, I first get them to visualize their workflow on a physical board. Then we discuss where the bottlenecks are in their workflow. Where does work get stuck and can’t move forward? Where are the delays? Then teams come up with experiments to try in order to unclog their workflow. We follow up on that in a future coaching session. This, in conjunction with a conversation of what excellence means to the team, is a start.

One of the classic anti-patterns I’ve seen is one that I lived through quite viscerally at Expertcity. There, we had component-based teams, and I was a technical project manager. Let’s explore the percentage anti-pattern.

The Percentage Anti-Pattern

For eight years I worked in a Waterfall environment. First, I was part of a web development team as an individual contributor, and then I became a technical project manager.

We were organized into component teams. People working within each component were assigned to projects. In many cases, we were assigned to a product line, and to multiple projects within the product line. People were assigned to focus a certain percentage of their time on each project. In practice, that can prove to be very difficult. How can a person really allocate 10% to project A, 20% to project B, 40% to project C, and so on? In this context, as a project manager, if I was not overseeing all of the projects assigned to this person, I could fall into the trap of trying to pressure this person to get the work done for me instead of for the other project manager. As new work would come up in this context, people might get assigned to new project teams. This is the type of change that is very overwhelming to individual contributors.

It’s hard for humans to program themselves for availability like that. It’s better for machines. This is an example of how, if we’re not careful with how we organize our teams, the people can get objectified.

This also challenges team effectiveness. Richard Hackman’s definition of effective teams includes the following components:³

Client satisfaction

The work meets the quality, quantity, and timeliness of the people who receive the work of the team

Team viability

The team works together in a way that increases their ability to work together interdependently again in the future

Member growth and fulfillment

The team experience contributes to the growth and personal well-being of team members.

Clearly when people are working simultaneously on multiple teams, they are spread thin, which threatens the quality of their work and their team’s viability.

So what can we do when we encounter the percentage anti-pattern? Just say no. It’s a skill to push back when people start to overload you. I think it takes courage to do this. If you are a leader in a context like this, you can demonstrate that the company values saying no. Let people see you do that. Socialize how you do that. That gives others permission to do it.

I value working at a sustainable pace and having a life outside of work. If you’re working in a context that is overloading you, and you can’t have any sort of balance, it’s worth some deep thought to explore whether this company is the right fit for you.

The other thought I have about this relates to your energy and passion to try to change things at your company. If you’re in a system where the percentage anti-pattern is present, maybe you have the energy to help catalyze a reteaming event to change how work is allocated. Maybe you do, since you are reading this book. If that is true, study and apply the material presented in Chapter 12.

Besides the percentage anti-pattern, I’ve also seen that it can be a bad idea to reteam to spread best practices or when there is the desire to “standardize” everything.

Disrupting a Productive Team to Conform to a Standard or Best Practice

With the best intent, managers and directors want to help teams succeed and become more productive. They might even get together and talk process and how to help their teams become better at what they do. They might judge teams and try to apply consistency metrics on them related to size. They might write down beliefs like, “We believe that the best team composition has four software engineers, one quality assurance engineer, a UX designer, and a product manager.”

It gets written in handbooks. It gets shared during team meetings as a cascading message. I was at a company once that decided to go look at all its teams and then investigate the larger teams to see if they should conform to the best practice of “team size.” Some of the teams split in half and viewed this exploration as an edict. One team, at the urging of its engineering director, came to me and discussed its particular situation and what to do.

This particular team had grown to be 16 members. Their manager, who preferred to remain anonymous, told me, “We were doing really well. And every week it seemed like we were shipping all these features, and that’s probably the main reason why we’ve been hesitant to split, since we don’t want to rock the boat. I think that we have resources in every area we need. It seems like we have good product direction. There is a sense of urgency that I think has been echoed from the top.”

I asked her why, then, would they consider splitting, and she said, “I think the number one reason is that the product management team noticed that we look big. And probably engineering noticed it too. And feeling like we’re violating a best practice.” She continued later, “There isn’t really a problem we’re trying to solve other than we look big. It’s the joke on the engineering floor that we have this massive standup every morning.”

I dug into how this team was operating, and she told me that one way they stay productive in standup is by talking about the work on a visual board kept in priority order, as opposed to defaulting to the standard Scrum questions of what I did yesterday toward the sprint goal, what I will do today toward the sprint goal, and what are the blocking issues toward our sprint goal.⁴ They had ways in which they navigated the communication and facilitation of being a large team. They owned multiple tools in their software. They found a rhythm of navigating their size and tool ownership. They were doing really well.

In the end this team did not split. It stayed big and continued to work together as they were before. The team members spoke with the management, showed their results, and moved forward.

If you are faced with a situation like this one, where an outside force is judging your team based on a physical characteristic like your team size, without even investigating your team’s performance, take the time to educate them on why you’re badass and shift their perspective. Talk with the manager of your team for support if they are not involved already. You can first approach it with a question. You can lead with something like this: “I’m curious why you think shifting our team size would help us be more productive.” And then share the frequency of your delivery and feedback from your customers on how they love what you’ve built.

In my years of working, people would sometimes say, you need to pick your battles. I think there is a lot of truth to that. Pushing back on decisions that appear foolish or nonproductive is sometimes necessary. This is where stepping into your leadership comes in. Analyze the requests of your team. Consider the pros and cons. Make informed decisions about your team structure, just like you do when you’re building software.

Another anti-pattern is when people are suddenly gone from your team, due to some decision made by someone higher up on the food chain, with short notice. Welcome to the mysterious world of reteaming by abstraction.

Reteaming by Abstraction with Poor Communication

While getting onboarded at a large client, I worked with nearly 30 team members. As a consultant there, I decided to do an initial assessment of how the people were doing on the team by visiting with each team member individually.

After a week or so, I had made my way almost halfway through the list of people that I had gathered. The company was going through a lot of different changes. In fact, it was in the process of being acquired by one of its competitors. Some team members told me that people were “dropping like flies,” and there was a lot of attrition. People were afraid. They didn’t know if they were going to have a job in a month. Nevertheless, the company brought me on board to help a group of its engineering teams be more effective during this uncertain time.

In one standup I attended, we suddenly learned that our QA engineer was no more. He got reallocated to a “higher priority” project. He was just gone. Poof. And he didn’t even say goodbye. This person was on my get-to-know list, but suddenly my list had become shorter, due to whatever “resource allocation” procedure was happening from a distance at the cusp of a new quarter.

The abrupt exit struck a chord with me in terms of how impersonally it was handled. It was really just a matter of fact. It hurt the team. Team members struggled as time moved forward because they lost their quality assurance person. They now had to work differently to deal with this change, and it wasn’t easy or expected.

It was almost as if the company was a threat to its own teams. This was a very large company—its employees numbered in the thousands. Managers kept spreadsheets listing which “resources” were targeted to work on what each quarter. There was, at least at the management level, a keen awareness of the cost of team members for each project, and at some abstract level (at least to me), people could get “reallocated” to other projects that were a higher priority to the company, at any time. This is really a threat to relationship building. I mean, if, conceivably at any time, a team member could be suddenly reassigned to another project, how much time do you want to invest building a relationship with them? Would it matter? This is the darker side of dynamic reteaming.

In speaking with engineers at this company, I learned that this sort of reteaming was nothing new. They were used to a great deal of changes “happening to them” throughout the years, especially near the beginning of a new quarter, when things were reassessed and projects moved up and down a priority list. As the company had many different office locations throughout the world, people would hear of changes via remote meetings or announcements made by people they didn’t even know personally. Plaques showed up in the kitchen announcing upcoming “unfiltered” talks with leadership. It was eerie. Many of the old-timers at this company have endured and survived through multiple rounds of layoffs over the years. Why do they stay? The pay is really good, and the job has high flexibility. The products are compelling to them. They deal with the changes.

Reteaming by abstraction is when people are treated as, and are typically called, resources. They are moved around and manipulated on spreadsheets by management. In classic command-and-control fashion, someone changes a cell in the spreadsheet, and that initiates a change in real life that impacts actual people. It’s almost like the Wizard of Oz behind a curtain, deciding the fate of team members, but maybe with a committee of other managers. It’s unclear, though, because it is so far away. It’s obscured. No one really knows what’s happening or who initiated the reteaming—unless you’re at a people-management level, or unless you go out of your way to find out what happened. When management is in another office, there’s more mystery. This space, or distance, really disconnects the humans. The people in charge of the reteaming likely have good intentions for the company. But due to this disconnect, that message gets lost in the execution of the reteaming.

So what do we do organizationally when faced with reteaming by abstraction? It could be about the distance to decision making, and to the people making the decisions. I like this advice from Simon Sinek in his book, Leaders Eat Last. Sinek talks about abstraction and comes to the conclusion that working in smaller groups, such as those below Dunbar’s number of 150, is the place to start.⁵ When you work in smaller units within the company, the people are closer together—they know each other. Maybe it’s easier to spread information when team changes are happening. In the software world, this could match up with working in tribe-like structures.

I think it’s important to have feedback loops set up at different company levels. Not just between individual contributors and managers, but well beyond that. There are commercial tools like Peakon and Culture Amp that can be leveraged to tap into how the people are feeling on an ongoing basis. With Peakon you can set it up so people can share anonymous feedback, and leaders in turn can respond to it, while still holding the confidentiality.

Beyond people being yanked out of your team without an ounce of notice or advanced warning, there is another anti-pattern that is related to what we might perceive as toxic team members.

The Impact of Toxic Team Members

Keeping people on teams, and in your company for that matter, whom no one wants to work with and are a distraction from getting things done, is a situation to take very seriously. These are the human impediments in our workplaces that we need to pay attention to as managers and coworkers.

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. Maybe they were insulting or abrasive. Maybe they were passive-aggressive and hoarded information. These types of behaviors threaten the safety of others on the team and in the workplace in general. Feeling safe is tied to high performance.⁶ We need to address threats to safety as a priority.

This isn’t a new concept. In 2012, Fitzpatrick and Collins-Sussman wrote an excellent chapter on this topic in their book Team Geek. Their discussion included separating the person from the toxic behavior at hand. Toxic behaviors are a threat to the attention and focus of your team. Toxic people usually lack HRT: humility, respect, and trust.⁷ Toxic behaviors might include the following: not respecting other people’s time, not having the ability to compromise or achieve consensus, being demanding or over-entitled, exuding hostile behavior, trolling, and having a high degree of perfectionism that gets in the way.⁸ People can be misunderstood and really have good intentions. They might be acting in a way that is distressing to others; however, as my friend Chris Smith reminded me, “Few people are actually evil.” It could be that something else is going on in their lives, and they are acting out at work because of that. We can apply ideas from Kim Scott’s book Radical Candor here, and get curious. She suggests that we “Challenge directly, but care personally.”⁹ I think there is a lot of wisdom in that approach. We need to take the time to dig in and explore what is going on interpersonally and care about the people. People do get reputations, however, and that is something for all of us to keep in mind in our world of work.

Rachel Davies told me a story about people who didn’t want to switch onto a particular team because the team had a loud person who was easily annoyed on it. She said, “They had this dominant character in that team. […] He was quite loud and complaining, and then they had these introverted characters on their team as well. And people didn’t want to rotate into that team because of that person.” She went on, “Some people who preferred a more peaceful life, they said, Well, I would quite like to work on the new product but I do not want to work with this guy, so I don’t want to change teams.”¹⁰  

Later in our discussion she connected the concept of reteaming to the ability to “choose the culture you want” on a team. Rachel said, “It goes beyond, Who do I want to work with? What area of the code do I want to work on? What coding language do I want to use? and over to, What kind of “mini culture” do I want for my day-to-day life?” It’s nice when we get to choose what we want. As Rachel described it, “some people didn’t want to join the frontend team because it was too laid-back and they wanted to get more work done. And then other people wanted to join that team because it was laid-back.” People, when given the choice of which team they work in, get to weigh all those types of things.

If you are not aware of the social dynamics present on your teams, like if you had no idea that this person was disruptive to team change, you could wind up with unhappy people. When companies reteam from afar (what I call reteaming by abstraction), the risk of having incompatible teams may be higher as a result. Allowing people to self-select their teams, or having enlightened managers who value considering social dynamics for team assignment, can help reduce your risk of getting teams with poor chemistry that threaten performance.  

When there is someone on a team and the other people don’t want to work with that person, especially if you pair program, it becomes quite noticeable. If the collaboration pattern is farther away, and there is more individual work and isolation, maybe it’s less obvious. When we learn about things like this, we can get curious and try to understand what is going on.  

Giving the “toxic” team member feedback is key so that they have an opportunity to try and make a change. Maybe they are not aware that their behavior is creating such problems. People can be given the benefit of the doubt; with feedback, I believe they can have the opportunity to change and learn from mistakes. If this doesn’t work, discussing how to deal with the situation with other managers or your human resources team is worth a try.

It can be really hard especially for new managers who encounter challenging team members. Coaching for managers is highly recommended. Manager communities can also support each other by sharing challenges and giving each other advice for how to face the challenges.¹¹

Besides having a toxic team member, you might also encounter what you, or others, perceive to be a highly toxic team that no one wants to work with. Keeping that team together brings a host of challenges.

Keeping the Toxic Team Together

Like people, teams get reputations. I remember working with a particular team that was comprised of some rather quiet characters. They steadily did their work, heads down. They went trail running together, and they built incredible things. There was a major problem, however. The product managers were afraid of this team. It became such a problem that it started to create a rift between the engineering group and the product management group. Things had to change.

It was hard to get “in” with this group of engineers. The best way “in” was to do sports with them. The QA engineer who worked with this team was easily accepted because he did this. It was impressive how he got “in there” and built the relationship with the engineers. For a time, this QA engineer was essentially the interface between the team and “the outside world.” This QA engineer was the translator between the quiet-yet-mighty team and the other personalities around the team—such as the product owner, the user experience person, and any other person who needed to interact with the team.

A product manager was in tears one day after a particularly brutal meeting with this team. The team members really didn’t respect her because she didn’t appear to know what she was doing, and she was unclear on what they were building. The features they worked on were highly technical. They didn’t really need her to build the system they were working on. She didn’t have any control or influence. But, as custom had it, each team was assigned a product owner. She didn’t feel successful. It wasn’t working out very well for anyone.

So an agile coach was assigned to work with the teams to try to help out the situation. Activities were facilitated, and things got a bit better—or at least more out in the open. They had dialogue. They retrospected. They tried to improve the relationships and to repair the situation. It was the usual drill—almost like an organizational hack—a bandage or a softening of an abrasive situation without really addressing the root cause. The combination of the people on the team was toxic to the environment as a whole. It wasn’t what was best for the organization or the people.

If you look at your teams and think, “Do I want the rest of my engineering organization to be like this team?” and your answer is clearly no, you might consider “reteaming the dynamic” of the team. In other words, you might choose changing up the team, or, if you’re bold, you might choose to destroy the team. Split up the chemistry. Abolish the vibe. This can be culturally very difficult to do. It takes courage and care.

Just because a team came together and is producing value, doesn’t mean it’s in the company’s best interest to perpetuate the vibe that the team emits. That’s part of the problem with insisting that all teams remain stable or having the same team members as a default rule. Sometimes the chemistry can be off. We need to have the concept of reteaming “on the table” for consideration as a valid organizational pivot.

Sometimes the dynamic is such that if you let it become contagious, you can have worse problems. You can perpetuate toxicity. Instead, we need the polar opposite.

We want the “multiplier effect” when we have teams in which people are highly collaborative and cooperative with each other, and when the energy is high. It’s fine to be a quiet team. That’s not the issue. It’s not that we need a team of extroverts. Rather, we want a collection of people who together are creating incredible things that delight customers continuously, and it’s a very enjoyable experience for the humans present. The people are excited to come to work each day. People are excited to work with the teams. They feel safe expressing their ideas without fear of shaming or bullying.

A leader’s job is to drive fear out of the workplace, according to Point 8 of “Deming’s Lessons for Management.”¹² That applies here. We need to get bold, step up, and have the courage to destroy teams that spread or represent fear in our environments.

This chapter has explored a variety of anti-patterns for dynamic reteaming. One thing in common across most of these anti-patterns is the mechanistic approach that has been employed. Sometimes, with managers off to the side, deciding on the team setup and change, the results can become not what we were going for. Maybe we are too far away from the work of the teams and the problems that we are trying to solve. We think we know best. We have the rank and paycheck as the manager, but it could be that we are “too far away.”

This is where inclusion comes in—actually involving individual contributors in reteaming planning. Doing so can likely reduce our risk that a reteaming will go wrong. The people on the ground have the knowledge about the relationship systems that could be impacted. They might know who gets along with whom. If you are a manager or are higher up than that, you might have no awareness of the social dynamic, and hence you could place a couple of people on a team who are like oil and water. Nonetheless, there are ways to get better at reteaming.

We can learn a lot from looking at anti-patterns. They really illustrate the dark side of reteaming. On the flip side, the patterns are also instructive. I’m not trying to pretend here that reteaming is easy. You will learn a lot as your career progresses and reteaming happens to you. You will also learn a lot when you are in the position to catalyze reteaming. You can get better at this entire concept of dynamic reteaming. Let’s go further into that; in the next part of the book we will go over a variety of tactics for how to get better at reteaming in your company.