Chapter 3. The Power of Team Assignment
There are different ways in which people arrive to their teams and later change teams. Some companies are open to having the team members decide where they go. For others it’s more of a controlled management decision. Things vary and depend on the context. A humanistic approach to team assignment takes the interests and learning needs of the individual into account when they arrive to teams, as opposed to yanking people out of teams without their input and placing them into situations that they do not want to be in. Sometimes we have a say in when we change teams, but other times we do not. There is an inherent notion of power in team assignment—ranging from very command-and-control, “from the top” decision making, to bottom-up, self-organized decision making that is made by team members. I think about this as a continuum, as shown in Figure 3-1.
Figure 3-1. Continuum of team assignment and change
Let’s start at the top of Figure 3-1. I think that when we are put into teams, or removed from teams by decisions made by people we don’t know, there is a sense of abstraction. I’ve seen this happen in my career during acquisitions. I’ve been on both sides—I’ve been at companies that got acquired, and I’ve been at companies that have acquired other companies. I’ve witnessed teams get combined, and code ownership moved from one location to another. I’ve watched managers get reassigned, and people lose their jobs after others explored around to “find synergies” across both companies. You might feel like a cog in a wheel during these times if you are far from the decisions being made. This is the abstraction part. “Someone” has decided which changes are happening. It’s out of your control. That’s what I mean by less freedom.
Moving down the continuum of team assignment and change, more power is in the hands of the people to determine their team destinies. Managers can form close relationships with their people and thoughtfully put them on teams. They can help them learn and grow, and give individuals more freedom to choose their team and work assignment. At the furthest end of the freedom spectrum, the people act as responsible agents of their own team change and formation. They just go and form teams. No one is holding them back, and I would imagine that there is a lot of freedom and safety in this context. Let’s explore the politics of team assignment in closer detail, from less freedom to more freedom.
Someone “At the Top” Put Them on the Team
As a consultant, I was at a client site that was taken over by one of its competitors. We were told that 5% of the company would be laid off globally. We had to wait a couple of weeks to have our meetings in engineering to find out who would be losing their jobs. How the decisions were made, and how they trickled down to the people, was very opaque. The average individual contributor was not privy to this information. People just waited to see if they were getting the email inviting them to a meeting that would seal their fate.
At one point, someone decided to shut down the San Francisco office. Part of my team was up there. Two of my team members were laid off, but were given a month to transfer knowledge and find another job. Why was it them and not the other team members? It was unclear and unspoken. No one talked about it openly—this was reteaming by abstraction.
The San Francisco office had been bustling at one time. People were happy, and there was a sense of community in that small office of about 45 people. With this turn of events, when I visited during the layoff time, there were just about five people left, surrounded by empty desks. The mood was somber, and the dynamic felt so heavy. The remaining people wound up moving to a separate office in another part of the city that had better access to public transportation and better restaurants. At least they had that to look forward to. A change of location sounded like the best thing for the remaining people, in my opinion.
Layoffs like this kill communities. They just do. I know there are business reasons why these things happen, but the human aspect of it can just be really, really difficult to deal with. It takes a while to heal from this, especially if it is your first time experiencing a layoff. It relates to the concept of transition. There’s a structural change in the team composition, but there is a human lag to process and integrate the change, and that takes time. Not all humans respond the same. See Chapter 13 for ideas on how to deal with unexpected dynamic reteaming like this, and how to move on from it in your company.
The Managers Decide the Team Membership
One way that teams were formed and reteamed at AppFolio was by managers getting to know people’s needs and interests on a one-on-one basis and putting them into a team where they could have a great mentor who was willing to help them learn the basics.
I spoke with Andrew Mutz, chief scientist at AppFolio, about reteaming, and he shared several stories with me. AppFolio has a very solid, learning-focused approach. Managers learn what engineers are excited to work on and pair them with people who are willing to be their mentors across their feature teams. Andrew called this a “fit operation.”1 Every new hire gets a mentor who helps them get up to speed with the current work and the environment as a whole. They pair program together as a strategy for sharing information and growing the new person into their role.
All along the way, the manager and the engineer have a continuous conversation about how the engineer is doing and what they are passionate about. As time goes on, that conversation helps to determine if the engineer should stay on the same team or switch to another one. This process is very fulfillment focused. It acknowledges that, as people, we grow and change with time. It’s about having engineers who are excited to come to work each day, are energized by what they are doing, and have the opportunity to learn and grow without being stuck on the same team forever.
The People Take a Survey 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 to feel more engaged at work. Rachel Davies told me about how for the past four years at Unruly in London, for example, team members had the opportunity to submit an electronic survey indicating how much they would like to switch into another team, and on what timescale. Unruly sent out a survey roughly every three months, and it was up to the managers or team leads to make the final team-switching decisions.
The survey idea came about at Unruly after its first team split into two, and in less than a year, one of those teams split in two again. The split of the first team enabled the development of a brand-new analytics product that could be built while maintaining the core product set used across its business. The next split was the core product team, which enabled an expansion of the existing product set. Each time they split, the teams found that a smaller team led to a better work experience for both teams because they had shorter standups and the feeling that they were all more productive.2
Following this experience of team splitting, Unruly’s team leads decided to encourage regular reteaming in order to share knowledge and create more resilient teams. This approach also provided an opportunity for developers to learn about new system areas, and to gain experience developing different products. At that point there were three teams, and people were able to, in Rachel’s words, “work their way around all of the teams.”3 A couple of team members did just that.
When an engineer wanted to expand their experience in another coding language or develop a new part of the product, they could request to change teams via conversations with the coach or team lead, or via the team rotation survey. People were drawn to a team by both the technology and the culture. Some people avoided teams when they didn’t like the dynamic—such as a team with a loud, opinionated person who dominated the conversation.
The survey helped managers to avoid typecasting people into one team forever. As Rachel said, “People that joined the company as Java developers ended up in the JavaScript team, and other people gravitated away from it. There were people who didn’t want to learn about frontend work and preferred the familiarity of Java code.” It’s nice to provide people with the ability to grow and learn at their workplace. Giving the opportunity to change teams can help retain people.
Besides surveying people to find out if they want to switch teams, you can just announce an opportunity and see who reaches out in response; that’s what Kristian Lindwall and team did at Spotify when reteaming around a cross-team challenge, which is described in the following section.
Managers Encourage People to Volunteer for a Team
Kristian Lindwall, engineering site lead at Spotify San Francisco, told me how some of its teams came to be. Spotify had different platform teams dedicated to developing on different clients, such as iOS, Android, and so on. At Spotify, groups of squads are referred to as tribes. In one of its tribes related to app development productivity, there were some performance issues that came about across all of these platforms. It was not surfacing as a priority to solve these issues from within the individual client teams, so a new team came together with a mission to improve cross-platform performance challenges. The members of this group, which included a product owner, fleshed out what the initial mission would be, and then—using existing channels in the company like email and chat—advertised that there was a new team forming with the mission they had prepared, and that they were looking for team members who would be interested in working on those challenges. Those who were interested could volunteer to join, and leave the teams that they were currently on.4
Beyond surveying and inviting volunteers, another structure that companies use to get people onto new teams is by having an event—sometimes called a self-selection event. Let’s dig in.
Managers Arrange Team Self-Selection Events
Sandy Mamoli, coauthor of the book Creating Great Teams: How Self-Selection Lets People Excel, told me about a few different ways that she has seen teams form and reform. These include managers just putting people onto teams at random, and managers forming teams of people based on the skills they have without consideration for the people’s interests, needs, or relationships with others. She has also seen managers work with their people to understand their interests and needs, similar to the stories Andrew shared earlier in this chapter. She does think that manager-formed reteaming breaks down when you reach a larger scale.
In her book she writes that “managers might still know their direct reports’ skills and personalities, but it becomes increasingly difficult to understand the intricacies of relationships among people as the number of relationships increases almost exponentially. In our experience the breaking point is around ten people.”5 Imagine having to do that with 150 people! It was this situation in particular that led her and her colleagues to try something different—the people would be asked to place themselves on teams, which she calls self-selection, as the next story illustrates.
How A Company Reorged with Self-Selection
In the case of the example with the 150 people, Sandy was at Trade Me, New Zealand’s biggest e-commerce provider and online auction marketplace. This was in 2013, at a time when the company did not have a team-based structure. In her words: “People were resourced on a project-by-project basis, but we had this one group of people, a tribe of four teams that were stable and they were doing incredibly well and they loved it. And we had the rest of the company be really, really envious.” So she and others talked about making that transition happen—a reorg. To get started, they gathered the managers into a room and attempted to start the switch to teams like they had done with other “resource assignments” in the past—manager selection. Sandy said, “We wasted an incredible amount of time. And we said, why are we actually talking about this? We are not the people affected. We are not the people who know who wants to do what, and we are not the people who know who gets along with whom, so we decided why not ask the people who actually know this…so we did.”6
There was excitement, but also fear and concern about asking people to put themselves into teams. Questions came up: “What if it’s like the school yard where some people are not going be picked? What do we do if people can’t figure it out? What if no one chooses to work in a particular work area?” Sandy and her coauthor and business partner at Nomad8, David Mole, worked together on this challenge. They decided to have a self-selection event—one that would really plant the seed for many events like this—that they still use in their consulting work at Nomad8 to this day.
After a lot of thinking and planning, they created a comprehensive facilitation plan and decided that they really had nothing to lose. If the self-selection event failed, at least they would have gathered a lot more information than they had before, which they could then feed into a management selection of teams. But then they thought, what if? What if they take this risk? Wouldn’t it be amazing? It would be incredible if all of these 150 people were able to self-select into their own teams. After all, as they described in their book, the idea of self-selected teams matched the research they had read and believed in from Daniel H. Pink’s book Drive and from research done by management consultant Margaret J. Wheatley.7 Furthermore, they had experiences at Trade Me as part of their 24-hour hack days in which they self-selected teams across 80 people. That served as a test case for this larger self-selection event. So because of all this, they went for it!
When you organize any event with 150 people, you need to be really, really organized—you need a solid plan. At a very high level, Sandy and David facilitated an event where there were posters all over the walls displaying externally focused work purposes or missions like “Make the experience better for the top sellers in the marketplace” or “Make the internal legal team’s work as easy as possible.” Focusing on purposes or missions is thought to be “longer living than just a project because you get domain knowledge, you start to love what you are building,” according to Sandy.8 The people arrived at the event and were given a photo of themselves to use for the self-selection. They got an overview of the event process, and then product owners described the purpose of their work. The attendees then worked in iterations to figure out which team they wanted to select, and which type of roles each team needed to fulfill its purpose—like engineer, user experience designer, and quality assurance engineer. Sandy and the event organizers put a constraint on team size, insisting that there should be seven or fewer people on each squad.
Every six months or so, this team at Trade Me ran a reteaming event via self-selection. At that point, all the names were removed from existing teams, and people had the opportunity to decide again where they wanted to focus their time for the subsequent six months. They could choose the same mission they were on, or a different one. In Sandy’s words: “It’s a good way of keeping teams from getting stale.”9 Some of the missions might have been completed, and some were still in progress. The people were given the freedom to move around as they saw fit.
Other companies give this ability to reteam even more directly to the people involved. It might not be at the scale of an entire department, but at the team level, as we will see next.
Teams Strategize and Form Their Own Team Structures
At the closer end of the freedom spectrum, some companies let their teams figure out how they might morph on their own, in order to be more effective. There is a high level of trust, as the following two stories demonstrate, and there is also a lot of respect for the professionals involved. First, we hear Elaine’s story about her team at Fitbit and how they reteamed after open conversations about it. Following that, we hear a story from Hunter Industries, where the company enabled team switching at the discretion of the engineers doing the work.
Reteaming as the Team’s Problem to Solve
Getting people to participate and decide how to scale out a team from roughly 10 to 50 people who are able to work on multiple concurrent projects is what Elaine Bulloch and her Device Cornerstone team at Fitbit accomplished in 2016. According to Elaine, Fitbit designs products and experiences that fit seamlessly into your life so you can achieve your health and fitness goals. When I talked with Elaine, she said that in 2015 the original team had about 9 to 12 people and it was comprised of cross-functional, full stack engineers working on embedded devices that deploy to multiple platforms, including iOS, Android, and web clients. As demand for its wearable devices grew, this leadership committee needed to find a way to reorganize so it could meet the consumer demand and ship devices more frequently to its customers.
So first, in Elaine’s words: “We put a lot of thought into how we would reteam, and we heard from our engineers and got ideas from them. We created a leadership committee that included myself as a ScrumMaster, our product owner, our technical leads, engineering managers, and our QA leads and managers and really just talked, and talked, and talked about really what would make sense moving forward.”10 It was clear from the start that the committee wanted to have a separate team, what Elaine called a “vanguard” team, to create and envision the future architecture for Fitbit’s devices. After several months, this isolated team had a viable plan, and the existing team had gotten a lot bigger, and accordingly, the committee needed to figure out its new structure.
Figuring out this new structure was like a puzzle to solve, and Elaine’s leadership committee took the challenge directly to the team. Elaine told me, “We really wanted to hear from the actual team members themselves, all of the developers, the design folks, all of the QA folks—every person involved in the engineering stack.” In order to attain the outcome of having a new team structure that people would be happy with, Elaine facilitated a workshop that she called the Reteaming Exercise.
It worked like this: she invited all of the team members into a large room for a couple of hours. During this reteaming exercise, Elaine had all of the team members write on whiteboards everything that each person and team owned. She said to the group, “Let’s write down what we do from areas of code that we own and are responsible for.” The mobile and client teams worked on one whiteboard, and the backend team worked on another.
After all of the work and ownership was revealed by the teams, Elaine asked questions like, “How are these groupings going to inform us around how we should group ourselves? What would an optimal team size be, and what would that look like? What would a team of today look like knowing what it is that we are working on today versus the team of tomorrow, three months, six months, nine months, a year from now down the line? What would that look like, knowing what’s coming up on our product roadmap?”
Using this approach, Elaine posed the reteaming puzzle to all the members of the current team. It was a problem for them to solve together. In the end, they concluded that a series of smaller “pods” with ownership over naturally occurring areas of work that they had identified and laid out made the most sense, and whenever possible, the “pods” would have their own leads that could keep aligned on architectural design and implementation decisions on initiatives moving forward. They also crafted mission statements for each of the “pod” teams. At the time of our interview, these same teams had been in place for more than six months, and they continue to be built upon today.
What I really like about the approach described here is that Elaine and others brought the challenge of restructuring for the future to the people who best understood the work of those teams. There is a great deal of respect in reteaming this way. That kind of respect is also present in the next story from Hunter Industries, where the people are able to initiate their own reteaming in concert with the input of their team members.
Team Members Trade Places, Then Tell Managers
Hunter Industries, a sprinkler manufacturer located near Carlsbad, California, practices mob programming, which is programming that is done by a group of people using one computer. Mob programming is a movement in the software industry that actually originated at Hunter Industries, catalyzed by Woody Zuill and his team. Hunter was going through a growth spurt and had been hiring about two people per month for a period of eight months when I interviewed Chris Lucian, the director of software development, back in summer of 2016. He told me about the flexibility that existed in the different mobs, or groups of people, coding at the same place in the office—complete with large screen, chairs on wheels, shared computer, and keyboard.
They had the idea that “anybody can go and work on whatever they want, and then eventually we realized that some things are way more interesting than others at times so we needed, at least, to have kind of a minimum headcount in place for certain projects.” He went on to say that for each identified project they would determine the number of people to work on that project. For example, “we essentially say eight people in this project, eight people in this project, and five people in this project and then you can form the mobs…”
From that start, people were able to move from mob to mob in an open and fluid way. After retrospecting on how things were going in the teams, Hunter discovered that “it’s kind of going too fast, and people aren’t retaining some information between them.” They needed a change. And from there, what Chris called a “negotiation-based reforming” started. It worked like this, according to Chris:
If you feel like you want to go on to another team, you just have to find somebody else on another team that wants to switch with you, and then you can switch […] so the idea is that you could switch once every three months, or less frequently, or more frequently. And then as long as the people that are switching on and off those teams are okay with the exchange, then we won’t really be going too fast for others because the nature of mob programming is that you kind of have that support and you have that group knowledge, the group memory that’s there when you switch.11
Notice that this shift in how the team is organized is driven by a retrospective. That is a key idea in team-based change, as discussed in Chapter 14.
Furthermore, negotiating with other team members to switch teams has been a pretty regular occurrence at Hunter Industries. It really depends on the person. As Chris told me, “There are a few people that like to switch every three months, and there are a few people that like to just stay on the same project for a long time. And that’s another thing; we get feedback from some people that they do not want to switch teams, but inevitably, because new people will be coming on and off their team, that’s essentially a new team. So regardless, they maybe don’t want to switch the technical and business logic material that they’re working on, but their team will be different.”12 The nature of dynamic reteaming, as we saw in Chapter 1, is that it really is inevitable. It will happen to you. It’s not just about catalyzing your team change.
When you do want to catalyze your own team change at Hunter Industries, however, there is help to do that. Full stack software engineer Jason Kerney told me that help is available for people who want to trade places, but need assistance to get the trade to happen.
They look at whichever team they’d like to move on, and then if they feel comfortable with it, they go over and negotiate it. If they don’t, they talk to one of the senior developers who will negotiate for them. Then we will take it upon ourselves to go to the other team and say, “Hey look, there is someone who would like to try this out, is there anybody willing to trade with them to go to this other place?” And almost always it’s a yes. I don’t think we’ve had anyone say “Absolutely not.” I think we’ve had a couple say, “Well, not right now, but can you come back in a couple of weeks? We’re in the middle of something…”13
Hunter Industries is committed to fostering an environment of continual retrospectives and learning. In fact, on a daily basis teams have an hour of mob-style learning, and two hours of it on Fridays. During these learning sessions, people get together from across their teams to solve programming exercises together and to learn new skills. When I visited them eight months prior to our interview, they were doing more rapid reteaming. Through retrospectives, they learned that they should reteam at a different rate and in a completely different way. Hunter is a great example of how you can build an adaptive organization powered by retrospectives. You can tune and adjust your reteaming based on this reflection. It’s how you become a generative, learning organization.
This chapter detailed different ways that people get on teams. There are different degrees of freedom, from a more controlled, top-down reteaming, to more of an open, bottom-up reteaming. There is not really a one-size-fits-all reteaming process. I think that in general it feels a lot better to people when they have a say in their reteaming. It doesn’t feel good to be moved around without any input. It’s a competitive advantage to be able to reteam well, with the people in mind. In fact, you can reduce a wide variety of risks to your business as a whole if you get good at reteaming. So let’s explore how reteaming, when done well, can reduce risk and encourage the sustainability of companies.
1 Andrew Mutz, in an interview with the author, April 2016.
2 A standup is a 15-minute daily huddle meeting for teams.
3 Rachel Davies, in an interview with the author, December 2016.
4 Kristian Lindwall, in an interview with the author, September 2016.
5 Mamoli and Mole, Creating Great Teams, 5.
6 Sandy Mamoli, in an interview with the author, October 2016.
7 Mamoli and Mole, Creating Great Teams, 7.
8 Sandy Mamoli, in an interview with the author, October 2016.
9 Sandy Mamoli, in an interview with the author, October 2016.
10 Elaine Bulloch, in an interview with the author, July 2017.
11 Chris Lucian, in an interview with the author, August 2016.
12 Ibid.
13 Jason Kerney, in an interview with the author, January 2017.