Coding alone restricts dynamic reteaming

Richard Sheridan, cofounder and chief storyteller at Menlo Innovations, and author of the best-selling book Joy, Inc.: How We Built a Workplace People Love, talked with me about his experience with what he calls the Tower of Knowledge problem. It’s a problem that he encountered quite viscerally as a vice president of R&D prior to founding Menlo Innovations.

Here’s how he described the Tower of Knowledge problem:

You know, the one guy, in this particular case in my team, who knew everything about a particular subsystem, and nobody else knew what he knew, and he couldn’t take vacations. […] He became very bitter, cantankerous, difficult to work with because he was always under pressure. He was always working lots of overtime. […] When he did schedule vacations, we would typically send him out the door with his laptop, with a pager, with the phone number we could reach him on, so these vacations could never truly be vacations because if something broke in his area of code, we needed him.¹

Can you imagine this situation? It’s like you’re chained to your work. Multiply that across your organization, and you have a workforce that’s destined for burnout.

You can’t scale your company if it’s comprised of a bunch of heroes, Richard told me, as they can only work 60–80 hours per week—and who would want to do that? It’s not sustainable nor livable. It just doesn’t work. We are not machines; we are humans and need better working conditions. Our goal is to cultivate a workplace where people are learning continually and are excited to come to work each day.

In addition to that, the more people you have working individually, the less connection exists. The people become islands of specialization. The complexity of coordinating their work increases, which is more costly. Heroes work independently on a greater goal. Maybe later, out of necessity, this is facilitated by project managers as the communication interfaces between the people. I lived this scenario when project-managing component teams building GoToMeeting. Just getting a shared list of work between all of the individuals was challenging. The shift to Scrum at least brings cross-functional specialists together onto one team, and ensures you get a shared list of work, according to the rules of the game in The Scrum Guide. However, if your specialists continue to work “alone” together in the Scrum team you still have the following problems of coding alone.

Coding alone gives engineers less opportunity for switching to work on other subject matter because they hold so much responsibility that’s not shared with others. After a while it can be like you’re chained to that feature set you own. It’s not the setup that I would recommend if you want to build a learning organization where people can reteam and expand their knowledge bases. It’s too rigid.

And, inheriting the code of someone who was working alone for an extended piece of time is no picnic, especially if it’s not equipped with tests or forethought for future developers.

Pair programming and mob programming add in redundancy, which makes it easier to switch teams when the time arises. Combine that with writing code with tests, and you enable greater agility and movement. Let’s take a look.

Pair programming with test-driven development enables greater fluidity in teams

When I was talking with the cofounder and CTO of AppFolio, Jon Walker, he told me that he felt strongly that pair programming and test-driven development have helped reteaming at AppFolio succeed. Both practices facilitate someone new starting on the team, whether they’re a new hire or switching teams, and they give developers freedom to work on different areas of the codebase without being trapped.

He said, “If you wanted to put in just one new person, they instantly get people up to speed quickly through pair programming. It’s a really quick way to do that. Test-driven development also is a great safety net where people can go in and change code in an area they don’t understand. Then they’ve got harnesses of tests. The test will fail if they’ve broken something. I think without those it would be a lot harder to reteam. I think that’s why people don’t do it frequently at other places.”² Pair programming helps to ease the transition of engineers joining any team.

This goes beyond mentoring. As Jon put it, “when someone’s mentoring you, they’ll talk to you every once in a while; that’s very different than having someone work with you every day doing pair programming.”

Combine the pairing with self-testing code, and you can be freed from the chains of being the “knowledge source” on one area of code, as we saw in the previous Tower of Knowledge section. Jon said, “I think one of the big benefits that we’ve found in how we work is that developers tend not to get pigeonholed. It’s largely because there are tests there, and anyone can work on any piece of code. So we resisted code ownership for a long time. We are starting to have little bits and parts of it, but even then it’s a super light version of code ownership.” If you’re not bound to a section of the codebase as an individual developer, you can have greater ease at switching later.

Jon said it well: “One engineer leaves, and you’re not lost with the only guy who knows how this light bulb works. But for programmers, there’s huge benefits to it in that it doesn’t become, Jon’s the only guy who can work on this light bulb, so every time we ever want to do anything to that light bulb it has to be Jon. And Jon’s like, I don’t want to work on that old light bulb that I wrote 20 years ago.”

Pair programming provides that cross-pollination of knowledge and a sense of shared memory of what is being worked on. And, when amped up with tests, it can really help raise the confidence of engineers who are making changes to the codebase due to the feedback they receive from the pass-or-fail tests. You can turn up the volume on the cross-pollination and shared memory or understanding of how the code works by mob programming.

Mob programming fosters even more fluid reteaming

Mob programming—programming in a group on one computer—is a movement that emerged in a team led by Woody Zuill at Hunter Industries in Southern California. It’s a “continuous conversation,” as described by Jason Kerney, a mob programming veteran from Hunter. He said, “Ideas are coming from a bunch of different points of view at a bunch of different times. It’s all just coming in.”³ He explained a situation that drove his learning about the approach home.

What actually happened to me is I left for a cup of coffee and got pinned down talking to this guy. It took, you know, 20 minutes to get out of that conversation. When I came back [to the mob] I realized that I could quickly pick up where I left off just because I could understand the different conversations and stuff that were going on. Because it’s a continuous conversation. You walk away for 20 minutes from a good conversation and come back. You’re not lost forever. It’s maybe 10 minutes to get back in step, and then you’re back in the conversation. It’s all very much like that, and that was the big eye-opener for me.

When all the people are together, with one keyboard and screen, and are coding “live” with each other, people can move in and out of teams with greater ease. There is simply more knowledge redundancy among team members.

When you work in a mob there are certain interaction patterns. You have the driver and navigator and the rest of the mob. People cycle in and out of these roles at a regular cadence, sometimes facilitated by a mob-programming timer.⁴ Because the communication pattern is known and relatively consistent across the mobs, switching from one team to another is easier to do, and it’s easier to integrate people into teams.

If you break up the majority of the team, that’s disruptive. If you follow the “trading places” practice, people can move in and out of mob programming teams without much disturbance to the team as a whole. See “Team Members Trade Places, Then Tell Managers”. Since all of the people are working on the same thing, there is a “group memory” and stream of thought. New people can join in. All of the details about what they are building do not leave inside the brain of the person who switched to another team. Hence, this collaboration structure is more redundant and fault tolerant.

If you work in a context with “towers of knowledge,” and there is not much collaboration, pairing, or mob programming, what can you do? How do you evolve your teams over to working more collaboratively?

One idea to consider is to apply the isolation pattern, described in Chapter 7. Start a team off to the side. Invite people to join that team who want to work differently, in this case, more collaboratively. Joining this new team means that we will pair program, for example. Hire in new engineers to that team and grow it bigger. Then split it, as described in Chapter 6. Now you have two teams that work like that. You can continue building from there by growing and splitting. Then, as time passes, have the teams that pair give lunch-and-learns sharing how they work. Who knows, maybe these practices will catch on in other teams.

There are other factors that impact the ease or difficulty of reteaming. We work in different contexts, with different people, different technologies, and so on. In the next section, we will go over several variables to explore this topic.

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? If switching to a new one, there is a potential learning curve, and they will need to acquire new equipment to work in the new platform. At a company I worked at, I was involved in an effort to spread out mobile development teams to integrate them with web development teams so that features for our customers can be cocreated in a more synchronous manner rather than separately. After moving our first two iOS developers out to web teams, we initially ran into constraints related to testing and deployment that slowed us down. The quality assurance engineers resident on those new teams either needed new testing equipment or had to work out ways to pair with existing iOS testers in order to complete their work. Moreover, spreading the ability to deploy onto the iOS platform was a new area of learning for the newly minted cross-platform teams.

Changing teams is a forcing function to learning. You can make the learning easier if you plan for it and have institutional support for it. We built an engineering academy of engineers teaching other engineers to support the learning needs that arose from this reteaming. Woody Zuill, one of the mob programming founders, held workshops on working collaboratively for any interested team members across our organization. This exposure to a more collaborative way of working had positive impacts on these new teams, some of which immediately began working collaboratively across their platforms by implementing mob programming. This accelerated the learning.

Programming language

When changing teams, does it require the person to learn a new programming language? This impacts the ease and speed of the reteaming. Things change fast in the technology world. For many of us, it’s obvious that we need to keep learning in order to stay relevant. If we’re used to coding in one language for our entire careers and then we need to learn a new language, there is an obvious learning curve. In the mobile reteaming mentioned previously, having iOS engineers work on teams with web developers spurred learning Swift on the part of the web developers on the existing teams, and the iOS engineers started to learn to code using Ruby on Rails. Pairing and mob programming supported this learning. This learning will most definitely slow down the work in progress in the short term; however, if successful, the teams will be more adaptive and able to deliver on customer needs in multiple platforms more easily in the future.

I was with another team at a different company that was creating software in web, iOS, Android, and Windows platforms. They decided to pause or stop working on the Windows platform for business reasons. The developers on that team switched into iOS development. Some of these engineers had been in the software industry more than 20 years and had been coding in C++ all that time. When I heard that this was happening, I was worried for them and thought that it would be a negative experience because it was not their choice. As it turned out, it was quite refreshing for one of the engineers in particular. Sometimes change thrust upon us is received positively; however, doing that, in my opinion, is still quite risky.

Single specialist roles on teams versus full stack roles

If we are making the switch into a new team that works in a completely different way than we do, it will challenge and add drag to our reteaming. For instance, if we are coming from a team in which we occupy a role like backend developer, and we are working with other people in siloed roles like frontend developer, iOS developer, QA engineer, and the like, and then we are moving to a team in which we will now be a full stack engineer coding the frontend, backend, and anything in between, then it could be a more cumbersome and challenging change for us (especially if we don’t like the idea). Moreover, if we now have to change our way of coding to ensure quality by writing more tests, for example, and not throw our code “over the wall” to a separate role who will quality check our work, that is another change that will make the reteaming more challenging.

Conversely, if we retain the single specialist roles on all of the teams, and we are just changing teams and retaining our single specialist role, it will be easier because there is that parity across both of the teams. It is the same if we have full stack generalists on our current team and we switch to another team that is comprised of full stack generalists.

There is definitely a balance needed in terms of having generalists and specialists. It’s up to the company to determine the right balance to fit its needs. It could be that an environment dominated by generalists could use a healthy sprinkling of specialists across the teams in a consulting or floating capacity to help level-up skills. I remember we had a highly specialized frontend engineer at AppFolio who would nomad from one team to the next, and he would hold open-learning sessions to level-up others’ frontend development skills.

Reteaming is a forcing function for learning. Encouraging people to be T-shaped is part of this discussion, and we can be deliberate about that. It is most likely the case that someone has deep knowledge of a particular area of expertise. That is the vertical part of the T. Next, they learn and expand their abilities to do even more in other areas, which is the horizontal part of the T. Changing teams encourages us to learn.

Age of the code

If we switch teams and now need to become familiar with a codebase that is quite old, and the people who wrote it are nowhere to be found, it will take some time to get up to speed and learn that environment. If you are instead switching to a team working on software created from scratch, without the need to connect to any existing code, it’s a different situation. You don’t need to spend that time as a “code archaeologist” trying to decipher how things work so that you can extend or transform it. When you are switching to a team that has legacy code, no matter how old it is, it will require taking some time to understand the code environment that you will be changing or extending. Teams that practice Scrum and are refining their backlogs might come up with the adaptation that you do technical refinement of work before giving estimates. The emergence of this is a nod to the fact that there is indeed ramp-up time needed to extend your legacy code.

Test automation, or lack thereof

If the existing codebase has tests in place, we can get to know the codebase faster. We might also feel safer in making changes to it because we will get feedback on whether we have broken any tests when we commit changes.

Jon Walker, CTO of AppFolio, cites the presence of test-driven development as well as pair programming as factors positively influencing the ability to reteam at that company. He said:

Pair programming and test-driven development have really helped reteaming, in that you can bring someone new into the team. If you wanted to put in just one new person, they instantly have people that can bring them up to speed quickly through pair programming. It’s a really quick way to do that. Test-driven development is also a great safety net where people can go in and change code in an area they don’t understand. They’ve got a harness of tests. The test will fail if they’ve broken something. I think both those things have really helped. I think without those it would be a lot harder to reteam.⁵

If you are a QA engineer used to working on a team that has a strong test-writing culture and you switch to one where that is nonexistent or lacking, then your workload will be impacted, and it will likely be more challenging.

How the team collaborates—soloing, pairing, mob programming

If your current team is soloing (coding alone as individuals), and you switch to a team that heavily pairs or practices mob programming, then depending on your viewpoint, it will be easier or harder for you to adjust. The same goes for a switch in the other direction: if you are on a team that heavily pairs or mob programs, and you switch to a soloing culture, it could be difficult. It could also be a relief, however, if you do not like pairing or mob programming.

If the people on the impacted teams pair or mob program, it is even easier to reteam or move people around those teams. There is less siloing of the work within the team, since two or more people understand the work. When someone leaves to go to a different team, there is still some domain knowledge that remains in the team. Jason Kerney, a full stack software engineer at Hunter Industries in California, talks about the group memory present on teams that mob program. When first getting into the practice of it, he would feel hesitant to take breaks, worrying that he would miss something in the mob programming session and would not be able to easily get back into it when returning from his break. To his surprise, after taking regular breaks, he learned that there is a group memory that enables the work to go on when people step away, and that it is entirely possible to reenter that work when coming back. He said, “It wasn’t until about two months in that I realized that breaking away from it and coming back didn’t actually cause me to lose context. The context was built from the communications that we’d been having all day.”⁶

In addition, bringing aboard a new team member is less disruptive, especially if the coding language remains constant. When people reteam and need to learn a new programming language from scratch, it is a setback for the integration of the person into the team. Pairing and mob programming help to ease that transition and raise the confidence of the engineers. If the coding language is constant, but the domain area of the work is new or different, there is still a learning curve. Again, it can be eased with pairing or mob programming.

When teams mob program or pair program, the organizations are more resilient to team change, which is an inevitable thing. People will come and go from companies. If you want to build a sustainable company, practice pair and mob programming. Build it in from the start or adapt your way over to it, as described earlier in this chapter. Hire people into that setup or way of working, so they know what to expect. Learn from the stories in this book from Menlo Innovations and Hunter Industries. They pair and mob program, and are highly adaptive and resilient organizations.

Colocated teams versus distributed teams, or hybrids

When the team is dispersed, and people from each of the groups are sitting in separate places in the building or are distributed across different offices or time zones, it’s a lot more challenging for the coordination of any coding effort. Reteaming will be more challenging unless you come up with some really good norms for relationship and team building. It can be done.

If you have the chance to start your organization from scratch like we did with AppFolio, you can make a concerted effort to have people not only colocated, but also coseated. It’s a tremendous advantage to the company. Things can get done faster. People will socialize with their teams on a daily basis. People will socialize by the kitchen. Friendships will form. Reteaming will be easier.

If everyone’s remote, you need to put in the effort to help the relationships build across the distance and rely on online communication to do so. Many of us had a crash course in this with COVID-19. It takes effort to foster the communication across distributed teams, but with some commitment it can happen. Video and asynchronous chat are the tools to rely on in order to create the spaces that make you feel like you are together in one place.

Hybrid situations where many team members are in one location with a couple of team members elsewhere can be particularly challenging. The people who are not located with the majority might feel excluded. Leveling the playing field by having everyone on individual video is recommended.

If you are going through a reteaming situation, and people for the first time are switching into a remote team or a hybrid team, there is a learning curve there for the new people. You need to reset on your team and communication norms.

If you are going through a reteaming, and the people are switching from one remote team to another, one hybrid team to another, or one colocated team to another—in essence, situations of parity—your reteaming will theoretically be easier.

Complexity of the domain

If your new team works on an area of the codebase with complex business logic and you do not know that in advance, it will take longer to get up to speed when you reteam. For instance, if you switch to a team that is responsible for accounting features and you do not know accounting, there is an inherent learning curve there. There was for us when we created the initial AppFolio Property Manager software. We brought in outside educators to teach us the ins and outs of accounting. We also had a standard set of books to read to level up our knowledge. It took time. People working on features other than accounting who would switch over to an accounting-focused team would have additional onboarding to get a decent mastery of the domain. This is a good learning challenge for those who seek it. I think managers who allocate people to different teams need to keep this in mind and build the learning into the reteaming plans.

Same or different manager?

When changing teams, will you keep the same manager or have a new manager? If changing teams means that you get away from a “bad” manager, it could be a net gain. If leaving an awesome manager with whom you are in sync and have great synergy and positivity, it could be a negative unless the benefits of the change outweigh the cost. When people are going through this, I usually coach them to see the situation as a learning opportunity. And it’s not like they can never talk with their former manager ever again, especially if they are at the same company. Having an open mind and giving the new manager a chance can prove to be fruitful. In some companies there is less coupling between the team you are on and who your manager is. It might not matter what team you are on—you have the same manager regardless.

Familiarity with the people on the team already

If you want a flexible organization in which people can switch teams, it pays to encourage deliberate relationship building across teams. If you buy Tuckman’s model for team development (which you might remember from “Larger-Scale Splits”)—forming, storming, norming, performing⁠⁷—then conceivably some of that can already take place if you foster people knowing each other across teams. There could already be a sense of respect and trust present that enables the reteaming to be more successful. Conversely, if you know the people beyond the team and you don’t like or have respect for them, the reteaming will be more challenging. I suggest that you prime people for future reteaming and build that into your culture, since it really is inevitable that your teams will change as your company exists through time. See the community-building tactics later in this chapter.

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. If we are on a team now that is jamming and we love the experience, we might not want to change teams. I don’t see a problem with that. If the team is delivering value continuously, is building the right things for the customers, and is an engaging and enjoyable experience overall, then by all means keep the team together.

But sometimes we are forced to change teams when we don’t want to. That makes the reteaming harder for us. When it’s our own idea, it can be easier. If we volunteer to change, if it is our idea, and if we know what we are getting into, it will be easier because we are opting in. We have control and choice in the matter. Most likely we think it is a good idea and a positive thing. When companies decide on the change for the people without their input, it could go either way.

Managers can advocate for matching the people with mutual interests. Recently I was with some directors who wanted to start a new team to do some future-oriented research. Initially we tried to figure out who from our teams would be assigned to be part of this short-lived team. Instead, we wound up sending a chat message to all of our engineers describing the opportunity and inviting people who were interested in it to volunteer in. With that input, the managers then created the final team.

Mindset about growth and learning

In the Carol Dweck “mindset” sense, if we feel that we are people who have the ability to grow and change and learn on the job, versus having the fixed mindset of feeling that we do not have the ability or capacity to do that, then we will probably have an easier time reteaming.⁸ If the people around us also share that outlook, then we will have a sense of parity on the team that can help the reteaming be more successful. Promoting an environment of learning and the idea that “we are never done learning” can help. Leaders can model the philosophy and speak about it. This can be part of the learning and development strategy at your company.

In this chapter, we first explored the ecocycle tool to get a shared mental model of our company’s placement on it. This can help start discussions about whether the context is ripe for reteaming, like when we sense stagnation, and it can show us that we can shift out of it by catalyzing some reteaming in creative destruction.

Next we looked at a host of variables, which may or may not be present in our companies, that make it easier or more difficult to reteam, starting with a deep dive into collaboration dynamics, which I feel is one of the more critical areas to consider if reteaming and fluidity is your goal.

There are some social hacks that you can employ to foster a readiness for dynamic reteaming in your company so that when you want to reteam later, the people are more prepared for it or even primed for it. This brings us to community building and role alignment.

Design events to build relationships across the organization

I’ve whitewater rafted, camped on islands, and have even gone to Disneyland with teams. I remember going on the Tower of Terror ride with an assortment of team members and having the shared experience of screaming at the top of our lungs as the ride dropped us vertically—it is something I’ll never forget, and neither will those teammates. Talk about an ice breaker. I was instantly connected to a site reliability engineer who was sitting next to me on that ride; I had met him that day for the first time. We would reminisce about this shared experience for years after. Taking epic trips together with your teams is something that you’ll never forget, and it brings people together in a strong way. It is completely worth the investment. It’s the secret sauce.

We had an annual tradition at AppFolio to have a tech retreat. It was a way to bond as a team, to have fun together, and get to know each other. We’d take these trips across our whole R&D organization. So you would get to know people across many teams, and then later when we changed teams for whatever reason, more people knew each other and had a shared experience, so things were easier. We would also deliberately invite our product team members to our engineering retreats. Keeping both teams together and healthy gives your company a strategic advantage. We closely collaborate across both groups in R&D, so why not spend the extra money and time to build and strengthen these relationships?

Once you get to a scale in your company where you can’t easily take your entire R&D organization on a trip, you subdivide into smaller experiences, like encouraging tribes to bond in this way.

Give teams funding to create their own social events

At AppFolio, tribes would have money budgeted to use for celebrating key milestones. Each engineering director who was in charge of the tribe would have these funds ready to use to acknowledge successes. Teams would decide what they would want to do in the local area together. Some teams rode Segway scooters in Santa Barbara. Others went wine tasting. Others went to cooking school together. Some went to sporting events in Los Angeles. The key here was that the money went to celebrating a real work accomplishment, and the team chose how to spend it.

What if you can’t get the funding? You can get creative. Teams can go for walks, hikes, have potlucks, or anything else in their local area that is free. I was with one team that chose to go to a local monarch butterfly preserve to observe some natural wonder, while also taking goofy photos of the team. The key here is taking the time to stop, choose an activity to do together, celebrate, and be with each other as a team. This builds camaraderie and shared experience.

And, empower the team to determine the social event. You can do it using the “1,2,4, all” pattern from Liberating Structures: Have each person think independently and write down some notes about what the team could do. Next, have them discuss their ideas in pairs and choose one idea to next discuss in groups of four. The groups of four can narrow down the ideas to one idea to serve up to the entire group. Then, each group shares out their top idea. Finally, the entire group can “dot vote” to determine the top idea. To dot vote, sum up the total number of items you’re voting on, divide by three, and round up. That is the number of dots to use per person. Then, place the dots next to the items and see if you’ve come to an agreement.⁹

Many of us have teams that are distributed across different locations and time zones. It might require travel to have a shared social event. We got around this at AppFolio in the early days when the whole team was in Santa Barbara, and two engineers were in Portland. We would often fly the Portland people to our home office. But sometimes we would do a social event in Santa Barbara like a boat ride, and we would arrange for them to do a boat ride on the same day up in Portland. And we would make it a point to do bidirectional in-person visits with our distributed team members, as discussed next.

You can also set up virtual lunch gatherings by using videoconferencing software if it’s not possible to get together in person.

Bring remote workers into the office and send team members to them

As companies grow, they might get spread out geographically. The people might not be colocated. This is really an obstacle for communication; however, it’s a reality that many of us face in our companies. So how do we make the best of it?

In the case of an organization that is largely colocated, but has a variety of remote workers, it helps to bring those remote workers into the context on a quarterly or more frequent basis. When you’re remote and it seems like everyone else is not, it can feel pretty isolating. You just don’t have the casual encounters with people in the kitchen or other common areas of your office. This is a threat to team gel.

I worked with some engineers at AppFolio who lived in Portland. Jim, a very senior engineer, would visit our Santa Barbara office on a regular cadence. And when he did, he would visit for a while and spend time with different teams at each visit, pair programming with different engineers not only to share his systemic knowledge of our codebase, but also to get to know people. Jim was our first engineer after our founders.

It also helps to go the other way and send key people out to work with remote workers in their context. We would regularly send people to Portland from Santa Barbara when I worked at AppFolio. It feels more inclusive to have “two-way visits” to connect the team members that are working in different locations. Early on at AppFolio, the tradition of eating chicken feet at a Chinese restaurant emerged out of sending people to visit these engineers in Portland. When team members would do that, photos would be shared with everyone, and the whole experience was memorable and fun. Traditions like this build a sense of culture.

Other things you can do is get all of your people to travel together to a different location in order to build the community in person, and then go back to your home countries, like in the next example.

Bring distributed employees together for a shared event

A global company that creates software to track PR campaigns and more had an annual retreat for its Agile coaches. I had the privilege of hosting a day-long coaching-skills workshop for this group. The coaches flew into Berlin from across more than four countries. Many of the people met for the first time, whereas others caught up with each other in person after a while. The three days they spent together focused on coaching strategy, skill building, and forming stronger relationships with each other. There was even a bowling event at a local establishment. Doing all of this gives you a greater sense of “teamness.”

We can extend our community building outside of our department, to bring an even closer-knit feel to our companies, and here’s how one company did just that.

Create opportunities for teams to get to know key leaders in different departments

Mark Kilby, Agile coach at a DevOps tooling company, told me how at his company, they started to have 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.” Having these types of events set up helps the teams build connections within the organization in order to strengthen it. In his words, “It also makes the reteaming a little bit easier. They know some of those senior people.”¹⁰ This almost primes the reteaming, in my opinion, because when you move to the different part of the organization, you’ve already started building the relationships needed to succeed.

At AppFolio, VP of Engineering Jerry Zheng created an event to encourage open Q&A between him and any team member. Every other Friday he hosted an informal meeting where anyone could come and bring any questions to the room. The meeting had a casual tone, as they had refreshments there, and the event had a “happy hour” vibe. Other department heads would come to this event over the years, providing opportunities for connection.

These are just some ways to build community across your teams. If people are comfortable with each other and have had a shared experience of some sort, then later when they reteam there is just one less obstacle. Besides deliberate community building like this, another way to set the stage for reteaming at your company is to develop greater role clarity across your teams.

Get vertical alignment within the role hierarchy and among managers

If you are working in a cross-functional software development team that is beyond the startup phase, and there are multiple people in each role, they are probably reporting to someone who is experienced in that role. In other words, the software engineers usually report to software engineers, and the tech writers report to tech writers, and testers report to testers. As companies grow, hiring expands, and you could have sizable amounts of each role. Beyond startup, job descriptions emerge, as do career ladders that detail the progression from entry level in a role, to senior, to principal, and so on. So starting within the role hierarchy, there should be some alignment about the meaning and success criteria for the role. And, in the case when these departments of people are so large that you have a community of managers for each role, getting clarity and alignment on the meaning of each role with the managers is important, especially considering the pressures that managers will have to deal with regarding promotions and pay.

Get horizontal alignment at the tribe level

If you are working in an organization where you have clusters of teams grouped into a community akin to a tribe in the Spotify sense, or even in a product or platform area of work, you can get horizontal alignment across these communities.

For example, if you have a tribe with four cross-functional teams, you can do the Tribe Role Alignment activity.

In addition to role alignment at the tribe level, I encourage you to focus at the team level.

Get alignment at the team level

The activities described previously can also be done at the team level and can be very useful when a team is getting together to recalibrate how it works—especially in the case when a team might have split into halves or thirds from the grow-and-split pattern in Chapter 6. I’ve even simplified it in some cases where I facilitate a discussion in which people share only this: “I’m in X role, here’s what I need from others.” We then go role by role, and answer back how we can help the person in that role. Often in the team-level context one or more managers who are not active contributors to the team are present. I integrate them into this activity because it provides them the opportunity to state publicly how they want to help the team as the person in the manager role, and it gives the team the opportunity to request help from the managers in a public way.

Getting alignment on roles and what to expect as you switch teams is not that hard to do if you devote some time to exploring it. Each of these activities can take two hours or less, in my experience.

This chapter has covered a wide terrain in order to get your organization to analyze its context using the ecocycle tool and to analyze the constraints and enablers to reteaming, including a discussion of a myriad of variables that might come into play. We’ve also gone over how you might cultivate or prime your company for reteaming, before we finished with a discussion of role clarity.

As I have said throughout this book, sometimes dynamic reteaming is going to happen to you, and it can be unexpected. You are essentially forced to change if you want to remain at the company. Other times you take the effort and energy to catalyze your own reteaming and make it happen. What follows next is a discussion about deliberate dynamic reteaming, starting with some specific planning tools.