How to use ephemeral teams responsibly
Ephemeral teams form for a short time around a particular problem or project. They disband once the problem is solved or the project is complete. While the concept has many benefits and has gained momentum in the software world, it also has some dangers. Let’s discuss those benefits and the very real but often overlooked dangers, and then talk about how we can take advantage of the ephemeral teams concept without running into the risks.
The benefits
Let me start by saying that ephemeral teams have many benefits.
For one, they make it possible for individuals to work on the projects that motivate them (shoutout to the Agile manifesto!). Having the autonomy to select one’s own team can be a boon to developer happiness and productivity.
With a more static team structure, employees can be stuck with the work that falls into their domain, whether it excites them or not. In my experience, developers hired into a team that supports growth or marketing often feel like their work isn’t that meaningful. They joined the company because they wanted to work on the core product, not because they wanted to optimize ads and landing pages. (Let me interject quickly that this is often a failure on the business side to explain the role. These business problems are fascinating and rewarding to solve, but this isn’t immediately obvious to most engineers).
However, with the ability to move from project to project, engineers can spend some time doing the “necessary” work of optimizing landing pages and sometimes doing the “meaningful” work of contributing to the core product.
In addition to helping engineers, ephemeral teams can help the business move faster. They can boost velocity because they can help fix capacity mismatches and avoid bottlenecks. For instance, if one team has too many backend engineers but not enough iOS engineers for a particular project, the company could dissolve that grouping and create an ephemeral team with more iOS engineers to handle the project. Meanwhile, the extra backend engineers could slide to another ephemeral team to lend their capacity to a different project. By matching capacity to projects, the company can theoretically handle more work in parallel than it would have been able to with static teams.
The dangers
While ephemeral teams offer benefits for employees and the company, they also pose serious (and often overlooked) dangers. By taking stock of the risks, we can figure out a way to achieve the benefits while avoiding the dangers.
Costs of chemistry
The first danger is that teams take a long time to build chemistry together, and until they do, performance tends to suffer. Tuckman’s “Forming-Storming-Norming-Performing” is a generally accepted model of how this works (check out the Wikipedia page). Teams come together (forming) and tend to experience a little tension or conflict as they learn how to work together and build trust (storming); they emerge with acceptance for one another and a shared team identity (norming), and then finally, they reach a place of autonomy with the ability to make decisions effectively as a team (performing).
A significant difference between norming and performing is that team members in the norming phase often feel unable to disagree or dissent. There is a fear of causing conflict after just exiting the storming phase. And some teams never leave the storming phase if they can’t figure out how to get along! To make effective decisions, team members have to be able to disagree. However, it takes a lot of time and energy for a team to get to that place, and in some cases, teams never reach it.
As a result, ephemeral teams are quite costly and risky. They’re costly because teams will spend time and energy going through the forming, storming, and norming stages every time a new team comes together. Further, there’s an opportunity cost since a static, long-lived team could have spent that time and energy developing. They’re also risky because, as mentioned, some teams may never exit the storming stage.
Could some opportunity cost be saved by not building an ephemeral team from scratch? We might imagine that keeping the core of a group the same while rotating a few members would keep the team identity mostly intact. That could help the team at least continue “norming,” right? Unfortunately, that’s not the case.
Tuckman’s research suggests that teams re-enter the storming stage when team dynamics change. Any change in leadership is especially likely to plunge a team back into the storming phase, and since ephemeral teams crop up around new projects, leadership often does change. Even if an engineering manager stays constant with the team, the product manager and other stakeholders likely will not. Since these folks typically inhabit a leadership role for a team, every new project will lead to a new round of storming.
Overhead overload
The second danger for ephemeral teams is that cognitive load can get out of hand. Although it is rare to consider cognitive load when building teams and assigning work, it is a fundamental constraint.
Guidelines, emerging from work around domains and team relationships to domains, like the books Domain Driven Design, Accelerate, and Team Topologies, indicate that ideally one team would correspond to one domain to keep cognitive load in check. (Please note that these are affiliate links, so if you purchase those books through the link, I’ll get a small commission).
You can think of a domain as a single conceptual space where terms take on a particular meaning. For instance, if I’m in the “referral” domain, the words “fulfill,” “redeem,” “sender,” and “recipient” take on a particular meaning. One clue that I’ve left the referral domain and entered another is if terms start to mean something else. For example, if “sender” and “recipient” start referring to people passing messages (rather than referrals), that’s a clue I’ve entered, say, a “messaging” domain.
Naturally, this means every domain comes with overhead since each has its business context and terminology. Therefore, the more domains packed into a single team, the more overhead there will be for that team and the more context-switching team members need to do. It also requires more precise communication within the team since the same terms can mean different things, and it requires team members to be on guard against potential miscommunications or misunderstandings.
Now, imagine the team members are also changing, and you can see how this problem multiplies for an ephemeral team. Team members context-switch every time a new ephemeral team spins up. Engineers must learn the new context without confusing it with the previous context, eating up time and creating miscommunication risks. Exacerbating the problem is the fact that engineers are still in on-call or maintenance rotations for services they’ve worked on previously. They must juggle multiple domains as they switch back and forth between on-call and the project at hand, which slows them down and adds risk.
Hidden costs of handoffs
Speaking of engineers being on-call, this segues nicely into the last risk: with an ephemeral team, the team developing the code will not be the team operating the code. There is no operating plan for an ephemeral team because it is ephemeral; it dissolves after the project is complete. However, someone has to run the services! Someone has to update packages, keep an eye on monitors, and respond to production incidents. That means there must be a handoff between the ephemeral team and whoever the “someone” is who will keep it running.
Handing off the code instantly incurs tech debt since the team taking over the code needs to learn what it does and all the business context to understand why it does what it does. Learning is necessary to be on-call effectively or to do future work on the codebase. For instance, addressing logic bugs requires the team running the service to know what the correct logic should be!
Further, a handoff takes away a chance for learning and growth. That’s because the people who write the code don’t get to see how their code does in production. They can’t learn how users respond—a lost opportunity to build business knowledge. They also can’t see all the bugs and other production issues that crop up, which is a lost opportunity to refine and iterate on software designs. Without teams building a knowledge base about their users, the company loses out on crucial signals to steer the business. And if engineers aren’t improving how they build, it fails to accumulate technical leverage.
Get the benefits, avoid the dangers
With the pros and cons of ephemeral teams laid out before us, we can try to take advantage of the benefits while avoiding the dangers.
First off, if engineer motivation and morale are an issue, the research in Accelerate says that there are many changes we can make while still using static teams. For one, they found that adopting continuous delivery practices can decrease engineer burnout by making deployments less painful and reducing the amount of rework or unplanned work that teams must do.
Those same practices also impact company culture, often shifting it to be more generative. The book describes this as a culture that shares risks, cooperates well, doesn’t assign blame for failures, and accepts new ideas. Regardless of the team, if you take away the worst parts of an engineer’s job (i.e., tedious, risky deployments and fixing production defects) and improve the culture around them, their outlook will improve significantly.
On top of that, these same delivery capabilities can solve the second issue ephemeral teams attempted to address. Companies reach for ephemeral teams to increase delivery speed, but we can save all of the costs and headaches associated with ephemeral teams by simply adopting proven delivery practices instead. Accelerate advocates for test automation, continuous integration, trunk-based dev, loosely-coupled architecture, and autonomous, empowered teams, to name a few. The authors have proven that these practices not only improve delivery speed but also improve system stability—a benefit that ephemeral teams cannot provide. Rather, ephemeral teams risk decreasing system stability due to the handoffs and the cognitive load associated with on-call.
In some rare cases, an ephemeral team may be necessary and beneficial. For instance, it could be the best solution if a production issue affects a system that touches multiple teams (such as a legacy monolithic system). In this case, you’d probably want to pull in developers from the various teams to get enough context to deal with the issue. Since only one or two team members from any given team need to be involved, the disruption to everyday feature work and on-call would be minimal. Plus, the handoff would be small since each team was already touching the system.
The key to making the ephemeral team succeed is to exercise restraint; use one ephemeral team to solve the problem but rely on autonomous, empowered, long-lived teams otherwise. Support those teams in investing in continuous delivery capabilities to help them move faster and enjoy their work more. Lastly, learn to break down the work so that it can be brought to the teams rather than needing to build teams around the work.
