Chapter 8. Merging Pattern
Another pattern often driven by the work at hand is the merging pattern. The merging pattern is just like it sounds: it’s when two or more teams or entities combine together, as shown in Figure 8-1.
Figure 8-1. Merging pattern
So why merge teams, especially considering the benefits that smaller teams yield, which we went over in Chapter 6?
Well, maybe you want to combine teams in order to harvest their collective intelligence to tackle a specific challenge. Or, maybe you feel that having one team per work area is confining, and you desire more fluidity in your work allocation by reteaming within a larger team. Even beyond that, maybe your company wants to acquire another company so that you combine forces and can more quickly offer a feature set that could save your company years of development time. These are some of the scenarios in which the merging pattern comes into play.
This section has stories from the team level, the tribe level, and the company level to explore this pattern, starting with a story from New Zealand. Pitfalls from this pattern are also discussed, related to some very challenging mergers.
Merging Teams to Enable Pair Programming Variety
At the division of Trade Me where delivery manager William Them worked, they experimented with self-selected teams when working on a project to make their web frontend responsive, or able to be viewed on multiple devices and screen sizes.1
Here is how the experiment came about. In his tribe, William had roughly eight squads. In his part of the almost 250-person product development organization, it was conventional that squads would remain relatively static and, accordingly, work would be assigned to them. When a squad finished its work, the management would look at the next highest priority work to be done, and it would be assigned to that “freed up” squad. This left the managers wondering if the most highly motivated engineers were able to work on the epics that were most interesting and suitable to them. Matching people up with work was really just the luck of the draw, or a timing issue. So, as a manager of some of these squads, William decided to do an experiment and merge together three squads of about 15 people total—engineers, analysts, QA, UX—and try out a new way of working, via regular dynamic reteaming, as shown in Figure 8-2.
Figure 8-2. Merge squads, then engage in self-selected pairing
They chose to experiment like this because the work is relatively known. They are basically porting their existing frontend feature set to Angular to make it responsive in various screen sizes. This is the merging pattern in action.
To get started, they put the names of the features or epics that the team would be making responsive up on a wall. Each team member put their name on a sticky note, and put it on the feature that they wanted to work on in the coming weeks. William didn’t set rules in terms of how many developers, UX designers, QA engineers, and so on, for each team, and instead he trusted the team members to work it out themselves. This repeated self-selected team exercise took about 20 minutes each time. When a team was about one to two weeks away from finishing its particular epic, that was the signal to kick off a new reteaming event. Each of the “in progress” and new epics were put on the wall. Each person was able to put their name on a sticky note and then place their note on the epic that they wanted to work on for the next few weeks. This was a continual process that had been going on for about six months at the time I interviewed William.
The power of this self-selected reteaming is that whenever new work entered the picture, there was the opportunity to best match up the people with the work. Putting the decision of “what work goes to which engineers” into the hands of the engineers minimizes the command-and-control nature of the work assignment. This, in theory, brings more potential fulfillment to the people. In addition, people can self-select into the work that they were doing already, which should meet the needs of the people who want to stay with a certain work topic or with certain team members for a longer time frame.
Notice that due to the merging of the teams, the company now had a much larger team than before. With this, Trade Me had a deliberate reteaming pattern—in this case pairing and switching pairs. In other words, the company put in a structure to help the people organize and reorganize when work was completed. This appears to have mitigated the challenges that teams face when dealing with larger team sizes, as described in Chapter 6. Remember this: when you have larger teams, you need facilitation structures to keep the teams from degrading in how they organize and how they communicate.
Not all merging happens at the team level. Let’s explore an example at the team-of-teams, or tribe level.
Merging Tribes Together to Form Alliances
Kristian Lindwall told me that at Spotify, at one point in their development, they were starting to see mission pollution. What that meant was that the company had too many missions—in other words, too many work focuses in play at the same time. Some were overlapping. Some squads had the same overarching missions. It was clear that the squads needed to “reset” the missions to make them clearer across the large group of people. Furthermore, he said that on a higher level, they had outgrown the organizational structure that they had. The size of the tribes was getting too big. They were also getting too many tribes. Each tribe lead was reporting to the CTO. That was also becoming a problem. And there were tribes that had adjacent missions or similar missions that did talk to each other a lot, so it would be better for them to sit more closely together in the organization. So the squads decided that they needed to reteam and cluster the tribes together.
In Kristian’s words: “So we did reform on a higher level. Tribes got merged, and we formed the concept of alliances, which is a grouping of tribes. This was also an approach to solve the issue of scaling…that we had probably grown too big for the structure we had.”2 A tribe is a kind of incubator for squads and the grouping of squads. An alliance is the same for tribes. So tribes that had similar missions ended up being grouped into an alliance.
Kristian described to me how Spotify went about reorganizing the people involved in this situation. At the time, there were probably around two hundred people working in his part of the org, which consisted of the client infrastructure teams and some closely related tribes. They decided to “do a bit of a reboot to see What missions make sense? What teams make sense? What doesn’t? Where should we merge? Where shouldn’t we? So I gave a lot of thought to how we could do this in a way that’s fully transparent and inclusive. It was crucial to us that people would be able to heavily influence or control where they end up, including who they work with, what teams we have, what missions we have, and so on…which is a bit of a tricky thing to do with two hundred people.”
How they went about this “reboot” is interesting because the intention comes from a very humanistic stance that strives to give choice to the people involved, instead of just placing them onto teams and letting the people know about it later. Lindwall said they initiated the conversation with people who were close to the mission, such as product owners, leads, and some engineers. Early on, it was mostly people in more formal leadership positions (although he would involve more engineers earlier if doing this again). This group was about 40 people. They did a series of facilitated exercises to discover what the high-level missions were, and how they could break them down into a new tribe structure. In other words, to “take the overall mission of all of these groups of people and the work that they were doing and make it a bit crisper.” They did a couple of ideation workshops and came out with a few suggestions for a tribe structure that was brought to the wider group of two hundred people for facilitated input sessions.
Next, they did the same exercise with squads and squad missions. And, in between those sessions, they had a lot of conversations within the bigger squads and via one-on-ones with people.
How did the people ultimately get on the teams? According to Kristian, it happened like this: “We ended up with 4 tribes and something like 15 squads. We had a massive whiteboard where we drew up all these four tribes with a suggestion for squads along with some constraints on sizes of the squads and with the missions for everything. We then talked to everyone and said, ‘Okay, so this is what we want to do now… This board will be up for a week. We want to organize ourselves into these tribes and squads, and this is for all of us to solve.’” They had daily standups by this board. Each afternoon they also had a fika—a Swedish term that means “coffee break”—where they staffed the whiteboard with people that could talk about the proposed structure. People had avatars representing themselves, which they could move around the tribe and squad structure to represent where they would like to go. The people were supported by one-on-ones with their existing tribe leads and manager so they could talk privately about their concerns.
As it turned out, some of the existing squads and missions remained, and they were present on the boards with avatars for current team members there already. Kristian recounted, “So a lot of the teams remained fairly intact, but maybe one or two people seized the opportunity to go after something new and interesting to them.”
Before this reorg happened, and they were discussing the approach, Kristian told me that there were some concerns about the approach. People were wondering if it was going to work. But Kristian and some others who were supporting this approach thought like this: “Hey, you know these people are solving hard problems every day, and they are all very smart people. So figuring out how to reorganize themselves is just another problem to solve. They will figure it out and we’ll be there to help out. We might run into some problems along the way, but that’s what we do every day. We’ll solve those as well.”
After two or three days they did have one squad in particular that was blank—no one wanted to be there. And so they started talking to some people about it and learned that this mission itself “was not interesting or compelling for people.” So they said, “Okay, let’s just wipe that team.”
Kristian said:
We also had teams that felt a little bit too big and some that felt a little bit too small. And there were some chats with people like, you know, bit of selling maybe, but largely…I would say no one was forced to go somewhere they didn’t want to go. Some teams ended up being a little bit smaller than we hoped for, and some a little bit bigger. But looking at the big picture, we said that was probably fine. And as we hire and grow, things are going to change anyway. People will quit or join, and, well, that will sort itself out.
I really like how the people are included in this reteaming, and that the organizers of the reteaming allowed time for people to stew over the future structure and have the needed conversations with their managers about where they might wind up. There is a lot of trust, care, and respect for people in this reteaming story.
Beyond the tribe level, as this story described, merging is most often heard of when it relates to one company acquiring another company, the subject of the next section.
Merging at the Company Level
Back in 1999, I joined Expertcity as the 15th employee. I really felt like we were changing the world with the screen-sharing software that our team had invented. It was exciting to be a part of a company that was revolutionizing global communication technology. There was a special energy to our first team. The excitement for what we were building was contagious. We worked hard. I remember working well into the night on many days, and many of us also worked Sundays. I remember feeling that I would be left out if I wasn’t around. The work was really fun and highly engaging.
After four years, in 2003, we got notification that we had been acquired by Citrix. At my level—I think I was a technical project manager at the time—I remember finding out about this merger along with everyone else during a company announcement. This announcement was disappointing to many of us because we had the hope of becoming a public company and riding that “going public” wave that many of us had never experienced before. And, let’s be honest, we wanted the cash from such an event. Although our stock wound up being worth a nice sum of money, it was disappointing for many people who had worked so hard for not such a huge payout that was notorious in this dot-com era.
How the merger went down must have been different depending on the vantage point of people’s positions within the company. I was in engineering. I remember that we were left alone to continue our work, and we were not disrupted or asked to reteam, at least in my sphere. We continued to focus on and invent GoToMeeting. It was almost like the isolation pattern. Our leadership knew how to buffer us from whatever was going on. I believe it was different for other departments like human resources and accounting, and there was a period of finding synergies, as they called it. The duplicate roles between the companies were worked out, and some people wound up reporting over to the new “mother ship,” which many of us called “Big C.” If people were asked to leave at this time, it was not advertised.
I don’t really remember meeting many people from the “new” company besides the CEO, who paid us a visit and gave an all-hands talk. I felt like we were a separate division, and we were. We were given the name Citrix Online, which cemented this new identity. I think that worked out well for a while, at least for me.
Besides the financial disappointment, I didn’t feel that bad until after more than a year, when one of our key founders left, and then other key technical leaders started leaving as well. That was the beginning of the end for me there, especially after the engineers I loved working with from early days went to another local startup, Appflio, which I later joined.
I’ve been on both sides of mergers. In this Expertcity story, I was part of the company being acquired. In the subsequent experiences in my career, I was part of the companies on the acquiring side. I’ll share a story about that next.
When I was at the second startup that I joined, AppFolio, after some time we acquired a company called MyCase. This was a company that created software for law firms. AppFolio’s mission, as articulated at the time, was to create workflow software for a variety of vertical industries using a shared platform. We started out by creating software for property management companies, and then through this acquisition of MyCase, we were able to say that we were in two verticals, this new one being law. So this was a reteaming for the work-type situation. Our portfolio was expanded, and we were able to say that we were a multivertical company sooner than we would have if we had built this vertical ourselves. The culture of the company meshed very well with ours, too, and I remember how our teams combined.
Through this merging of our companies, we acquired a presence in San Diego, as that’s where the MyCase office was. We had new team members and new leaders from MyCase who joined us. I remember that we decided to first keep all of the law software down in San Diego. Gradually over the years AppFolio built out that office to also contain teams from the property management vertical. But we socialized together and even had tech retreats together, such as a trip to Big Sur, California. This helped to blend our cultures and encourage us to become one team.
Some of the founders and other leaders of the startup that we acquired left the company after more than a year as well. I think that’s a common pattern after merging happens. Key leaders from the company being acquired inevitably leave and move on to something else. Maybe that’s not always the case, but I’ve seen it firsthand at least five times in my career.
I’ve been through some mergers that felt positive to me, and other ones that felt like my heart was being ripped out. Mergers, like some other examples of dynamic reteaming, aren’t always the bright and cheerful organizational changes they might appear to be. Sometimes they hurt like hell.
That brings us to the pitfalls of the merging pattern. You can experience pitfalls on the team-merge level as well as the company-merge level. Both levels will be explored in the following section.
Pitfalls of the Merging Pattern at the Team Level
When teams merge, they combine together, so you’re naturally left with a larger team. This can pose some challenges if you are not familiar with managing large team dynamics. The first pitfall relates to a lack of calibration.
When You Don’t Calibrate the New, Larger Team
The first pitfall of merged teams is when you do not calibrate the new, larger team. It’s critical to calibrate so people will understand how their new team system will function. You need to calibrate on the people and roles, the work and the workflow. Use some of the activities described in “Team Calibration Sessions” to come up with your plan.
Furthermore, if you don’t talk about the new, combined team structure, there is likely a greater transition time over to the “new team.” There could be fear around the teams combining. People might wonder how they will work together with people in the same role that they have. What will the overlap look like? Will there be duplication of efforts? Or will their roles actually be reduced? I find that when teams merge—for example, when three teams merge—the merged team is usually left with only one product manager, rather than including all three. This is an important change to discuss. If you don’t talk about it but instead leave it to chance, it’s just messy and can lead to upset and frustrated feelings. I go into the concept of transition more deeply in Chapter 13.
Again, what you need to do when teams merge is to proactively run a calibration session with the new, larger team. Moreover, you can deliberately discuss how you will collaborate together as the larger team system. Will you pair program and switch pairs, as described earlier in this chapter with our Trade Me story? Will you form subteams that expand and contract around opportunities? Will you work in a solo fashion and pass the baton to other team members? You can experiment and try things in order to pursue effectiveness. The point here is to talk about how you’re going to collaborate and get started. Then reflect on your team structure during a retrospective from there on out.
Meetings are another topic to revisit when teams merge, which brings us to the next pitfall.
When You Don’t Reset or Facilitate Your New, Larger Meetings
When your teams merge together, they each bring with them a collection of “legacy” meetings that would take place within the precombined teams. Another pitfall of the merging pattern is when you don’t take a look at your meetings and adjust them for your new team system.
You need to get together and decide what to start doing, stop doing, and keep doing, in terms of the meetings that you have. Maybe you delete all the legacy meetings and start over with what makes sense for this new team system. Talk about it and see what is needed with your new, larger team.
Moreover, since your meetings may now be larger, you need to have a plan so you don’t devolve into the default structure in which a large percentage of the people in the meeting are passive, and only a few people are talking or engaged. This is where facilitation techniques for having effective meetings come into play. It’s more than having a meeting agenda and sticking to it. That’s not enough. And it’s not enough to just agree on an outcome for a meeting. I would challenge you to figure out how to bring some aliveness into your meetings so that they are inclusive and encourage all voices to be heard.
Throughout this book I’ve mentioned Liberating Structures as my go-to set of facilitation techniques. The beauty of these techniques is that they scale, and they are open source. You can apply these techniques in any of your meetings to include people in the conversation. They can be used virtually or in person.3 Create a facilitation plan that is interactive to serve as the default for each of your meetings, or prepare for them to be awkward.
On a related note, when your teams merge, you will also want to reset on your communication channels, such as the team’s chat channels and email distribution, or whatever communication mechanisms exist. Figure out these logistics head-on, and then when you have an official date to “combine,” you’re ready to go.
Another pitfall when your teams merge is not aligning on decision making.
When You Don’t Figure Out How You Will Make Decisions as a Larger Team
If everyone in your larger team defaults to consensus as the decision-making style, and you’re in a meeting where only two people talk and everyone else is silent, it’s incredibly awkward and frustrating. When a decision point comes up, some people try to get around this by saying that if you don’t speak your decision, then “silence is consent.” But to me that doesn’t feel right. It feels forced. It doesn’t have to be that way.
Instead, what you want to do is to get really clear on how you will make decisions. Get clear on which decisions are made by any specific roles. You can make a list of each role, and the types of decisions they make. You can make a list of the decisions that you want to make by consensus in your squad. You can also determine what to do if you can’t make a decision, or when you need to escalate to someone outside of the team for a decision.
One technique that I like to teach squads is the fist of five technique for polling for consensus. The following is how I teach this technique to teams, and I think it really helps, especially when you’re dealing with larger, merged teams. This technique is referenced with a more extended description in Jean Tabaka’s book, Collaboration Explained, and she credits the method to her colleague Janet Danforth.4
The importance of doing a fist of five is that it shows you the sentiment about an idea you are deciding on. If everyone gives the idea a three, for example, maybe you don’t want to pursue that idea.
Typically, if the decision is not obvious after polling for consensus like this, I will then do a majority rules vote in the team. The actual voting on ideas is separate from polling for consensus if you dig deeper into this stuff. Majority rules, or when the majority of people vote in favor of an idea, is how you can close on decisions. This is a nuance. I find that in practice, just polling for consensus helps teams make decisions that are good enough to enable them to move on.
Besides these team-level pitfalls, I also find that there are pitfalls when companies merge together. It can get quite complicated when companies merge because it usually impacts a lot of people, most of the decision making is abstracted, and it’s not clear who is actually making all of the decisions that are forced upon you. These are mostly top-down decisions. I really believe that people have positive intentions and want to do the best for their companies. The pitfalls with company mergers are the fallout of human emotion and unclear communication, as the following heart-wrenching stories illustrate.
Pitfalls of the Merging Pattern at the Company Level
When companies come together and merge, at times people are asked to leave. It can be really heartbreaking when this happens, and it can feel like decisions are obscured. It’s unclear who is making the decisions, everything can go down quite dramatically, and it all feels rather heartless.
The cascade of information from the top of a company downward, especially in the charged time of a company merger, can fall into failure traps. We think we are clear and getting our points across, but we are not. This failure of communication can spread fear and chaos, as these stories illustrate. First is a story about drawing out the layoffs, next is a story about ambiguity and layoffs, and last is a story about chaotic takeovers. These are indeed scenarios that we don’t want to duplicate; however, I think we can draw lessons from them, as I’ve annotated throughout the rest of this chapter.
Drawing Out the Layoffs
“They should just rip off the Band-Aid! Why do we have to wait until next week to see what happens to our department?” A friend and coworker at a client assignment said this to me as the company went through a takeover by one of its competitors. She added, “I haven’t been able to do any real work for the last two weeks.”
While posters appeared in the kitchen welcoming us to the “new company,” there was still signage of the old company all over the office and outside multiple buildings. A change of identity was forced upon us, and, as a consultant with engineering teams “on the ground,” I was right in the middle of this tectonic shift with everyone else.
We watched the webinars, we received the emails with video messaging in them, and we integrated our email and IT programs into those of the new company. On our desks, we found swag branded with the logo of the company taking us over, welcoming us into our new company. The new leadership regime was announced via email with glossy headshots; only one was from “our company,” and that person was labeled interim.
Next came the process of finding synergies. Who has duplicate roles? Who is going to report to whom? Are we going to be reorganized by products? By components? We were in limbo. When two companies come together to form one “new” company, the whole organizational structure needs to be thought through and redesigned. This is a key part of the merging pattern. As a result of this particular merger, the company became three times the size of the acquiring company. So we were waiting to find out the fate of our coworkers and wondering whether particular office locations were going to close or remain open.
So what’s a team to do? We tried to press forward and focus on finishing our current sprint and planning our next one. The mood was tense and brooding, amplified by the dimly lit facility we were in. It was a good time to take some days off or work from home as a coping mechanism. Many team members did just that. Others altogether avoided discussing the topic at hand, and forged ahead on the old plans that could have changed dramatically in the next week. It’s all they had.
The discussions about the “elephant in the room” happened at lunch and during one-on-ones: “I don’t know if my boss is going to be here.” “Should I really push that issue with Joe? Maybe he will be gone next week.” “Will I have a new manager?” “The way I heard we are reorging is the same structure that we reorged out of last year.” The more people I talked with, the more I realized that some people were privy to more information than others. But even who had what info was mysterious.
It’s hard to focus on doing any real work when you don’t know if you’re going to have a job the next week. In this situation, the layoffs took place over two weeks. If your department was part of week two, then you had more time in the hellish unknown. According to Stephen Heidari-Robinson and Suzanne Heywood in their Harvard Business Review article, “The psychological impact of uncertainty during a reorg can be even more distressing than an actual layoff. The longer that badly planned reorgs drag on, the more the misery endures and the longer it takes to see the business results the reorg was intended to bring about.”5
Drawing out this type of news is really hard for the people involved. Maybe there are rationalizations that are made about this: “We don’t have the staff to simultaneously lay off people in all departments at once. This week we will address Sales, Marketing, and Service, and next week Engineering and Product Development.” As reasonable as that might look on paper, the fallout on the ground is quite the opposite if you’re in the teams that have delayed layoffs.
Being on the ground in this situation as a consultant was a different experience for me because I didn’t have the same kind of fear. I had my own work and multiple clients. However, I could feel the fear in my body from others, as people vented to me during our one-on-one meetings, and I could feel the fear during our faux grooming and planning meetings.
When you are with people who are going through a traumatic experience, it feels quite different than if you’re just reading about the company’s layoffs on social media. There is more empathy when you are in it on the ground with people. You can almost see the pain through observing their body language and facial expressions, and when you see them whispering to each other in small groups. Simon Sinek writes about this in his book Leaders Eat Last.6 Through this experience, I felt this firsthand.
So how can this type of situation be approached more humanistically? Laying off people promptly is probably the more humane way to go. Environments of fear (as well as joy) are contagious. People can’t get any real work done—or it is incredibly challenging to do so—when they don’t know if they’re going to be escorted out of the building the next week. You need to just rip off the bandage.
And if you’re going through a situation like this, you might get some insight into what is going on by talking with your manager. See what your manager knows because it may be helpful to you to understand the context of your department. Blowing off steam about the situation at an offsite lunch with coworkers could also help, if talking things out is your thing. Some people don’t like to process events like this quite so publicly, and so venting might not be appealing.
Having a plan B or seeking other opportunities is a completely appropriate thing to do in this type of situation. Maybe now is a good time for you to make a change and switch jobs. If you’ve been at the company for years, however, you might consider waiting it out to take advantage of a severance package. Who knows—maybe that would be better for you to consider.
Ambiguity flourishes in times of change, and even if we’re trying to be as clear as possible when structuring larger reteamings, it can cut into our hearts, as this next story did for me.
Ambiguity Around Layoffs
“It’s my last day,” Carlos told me in the parking lot, right after showing me his Chevy Volt, the type of car I was about to lease. He had tears welling up in his eyes.
“Were you laid off?”
“Yes,” he said.
It’s the beginning of a horrific week, I thought to myself. Oh my god. This is getting so personal.
“What kind of severance package did you get?” I asked him, hoping that they at least had given him a generous send-off. “I hope they gave you a good package—you’ve been here for so long.”
It had been about 15 years since he started at the company, maybe longer. He was a key architect. His visa was sponsored. He was more than well-respected by his peers. He had kids in high school and college. He was a fixture at this company.
His kind eyes flickered and looked away. “I don’t know yet. I’m supposed to find out today.”
I was stunned. He was a very senior engineer. As we both walked back inside, the excitement of the car moved to the wayside.
I had a feeling that the upcoming week was going to be tough. I walked back to my desk and couldn’t help but talk to Joe, the engineer at the desk next to me. He was one of the many whom I was happy to reunite with for this short-term, local gig at a client site I knew and loved.
“They must be trying to get rid of the high salaries,” Joe said. He looked at me with sad, empathetic eyes as I told him the story from the parking lot.
I walked to another part of the office and saw a program manager. She saw the look on my face. “Yeah, I heard about Carlos, too.”
I went back to my desk and started to get our task board ready for standup. Brent, an engineering manager, walked by. I noticed and went over to him. “I can’t believe that Carlos is being laid off.”
He looked at me with surprise. “What?”
“Yeah, he told me today is his last day. He’s waiting to find out about his severance.”
Brent appeared more and more animated and concerned.
“Are you his manager?” I asked.
“No, I’m his manager’s manager,” he said back to me. “I’ll be back!”
Brent rushed off. No, actually, Brent bolted! He was trying to go and clear up the situation because Carlos wasn’t being laid off. It was a big misunderstanding.
About 30 minutes later Carlos came to my desk. “I’m not getting laid off,” he said. “I thought I was, but it’s not the case.”
“I’m so glad you’re safe, Carlos,” I said. “This has been quite a week.”
When your company has a lot of ambiguity around layoffs or any other big change and you’re swirling in despair, I think the best thing you can do is talk with your manager. It’s their job to support you. Have a discussion about your job and the safety of it. You manager is probably more tapped into what is going on in the organization than you are. Managers must field questions in times of uncertainty and cascade information to their reports so they can make sense of the changes.
When we lack information, we tend to make it up. Brené Brown has a very nice treatment of this topic in her book Dare to Lead. She references the research that she did for her book Rising Strong, and notes that the most resilient research participants in her study would use some form of these sentences: “The story I’m telling myself… , The story I make up… , I make up that… ,” and so on.7 So think about that if you’re processing partial information, whether during a takeover or merging situation or during another situation where there is a great deal of uncertainty. What stories are you making up?
Drawn-out layoffs, ambiguity around who is getting laid off, and the general loss of coworkers is the darker side of the merging pattern, as we will see in the following story. It can feel chaotic, uncertain, and just physically awful.
Chaotic Takeovers
I arrived in the San Francisco office expecting the worst. At the standup the previous Friday, one of the engineers had proclaimed, “No we didn’t get to the code review yet. They were too busy firing most of our office.” I was consulting at this company that was in the middle of the takeover described in the past two stories. We were just acquired by a competitor.
It was a sad and painful time. Five percent of the global workforce had been laid off days before. This San Francisco office was hit the hardest. As I walked into the office I saw many empty desks. As one of my team members put it, “They fired everyone around my desk. I’m the only one left.”
I had worked at this office for the past three months, coaching two teams. Each of these two teams had members in the San Francisco office, as well as another remote office, so I traveled back and forth between the offices to get to know the different team members.
The previous time I had worked from the San Francisco office, there had been a baby shower in the kitchen for a well-liked coworker. “You should try the biryani,” Nimita, an engineer, had told me. I was excited to have met her for the first time that visit. On this visit, however, we would be saying goodbye. She had just gotten laid off, in addition to another member of my team—both were highly talented mobile developers who were still expected to be in the office for another couple of months for “knowledge transfer.”
Indeed, the mood was the polar opposite during this visit. The people from the party were gone. The happy times had passed. The space felt very different. Actually, at one point during the day, I felt like I was being beaten over the head with who knows what. The energy of the place was beyond what I had ever felt in a workplace. As a coach in that environment, I knew the people needed me. So I was there with them. I rolled with it.
As the week progressed, more and more visitors arrived at the office. They were all from one of the European divisions of the new company. Despite all of the layoffs, the company was also going through a reorganization.
My team was impacted by that. We lost our product owner and also our UX designer. We heard that we were going to get a new product owner from this European office. I was excited to meet him that week to get started. After all, we had had a new, different product owner a few weeks before that. We were essentially about to meet our third product owner in the past three months. That was quite the dynamic reteaming that we didn’t desire or like as a team. It felt like a revolving door. Yes, it was highly disruptive.
Many of the visitors were in a large conference room all day. We heard that our product owner was in there. So I went ahead and found out his name and sent him an email, since even though he was physically in the building, he was unavailable. I wrote, “We’d love for you to meet the team.” He told me that he would be in meetings most of the time.
A couple of the other team members met the product owner by chance. But we had no formal get-together with our new team member. He was too busy, and then he hopped on a plane and left the country. “We’ll have to adjust some of our meeting times now that our product owner is in Europe, and the rest of us are in California,” the program manager said to me as she, too, left to go back to Southern California. And that was it.
This was a bizarre and “distant” reteaming to say the least. And, it was more than a missed opportunity to get to know each other as people. Before I knew what had even happened, it was like the people had slipped through my fingers and dispersed across the globe. First impressions are important. And this one was more impersonal than I could have imagined. We were starting out our new team with an already damaged interpersonal dynamic.
If you find yourself in a chaotic takeover like this and you feel physically crappy, I have two words for you to consider: vacation time. If you have vacation days that you can use, this seems like a great time to use them and get out of the office. You could also take a mental health day and call in sick. Getting some distance by working remotely might be better for your health.
If you can’t possibly get away from the office during a time like this, you might try to distract yourself in order to cope. Maybe you can work in a conference room, or outside near the office. Maybe you can go for some one-on-one walks with some colleagues. For some of us, talking things out when they get difficult is helpful. For others, maybe being quiet and alone is better. If you’re in a situation like this, I feel for you. For me, changing consulting assignments was the ultimate solution.
In this chapter we have gone over how at the team level you can combine forces between teams to bring greater collaboration opportunities. You can also join groups of teams together to reorient them toward work missions. These are fairly contained and smaller entity transformations that to me seem easier to get your head around in comparison to the higher-level merging of companies, which is a much bigger deal.
This chapter detailed what can go wrong or get messy when individual teams combine. These mergers of sorts are lower risk than merging at the higher level of panarchy, the company level. I don’t claim to have all of the answers about company mergers, as I’ve experienced them at a certain level of abstraction up to director level in the three software companies I consulted with or worked at full time. But I have experienced mergers as a human, and I will say that being successful with them takes great care and attention for the people. So how do you do mergers better than the horrors that I have described here? There’s another book that remains to be written on that.
Until then, let’s burn some sage and switch to a new topic, something lighter and driven by learning and fulfillment. Onward to the switching pattern!
1 William Them, in an interview with the author, November 2016.
2 Kristian Lindwall, in an interview with the author, September 2016.
3 Visit the Liberating Structures website and join their Slack community.
4 Tabaka, Collaboration Explained, 80.
5 Heidari-Robinson and Heywood, “Assessment,” 1.