Originally published in DevOps Digest
Many of us are now working remotely, whether we like it or not. We may be in a new work environment, having to find a space to work and get familiar with a new routine. We may have new distractions such as kids at home or less of a work-life boundary. We certainly have new worries such as COVID-19 and changes with our economy, society, and family. There are new communication challenges if your team is working remotely for the first time. And we face new economic challenges as supply and demand are disrupted and changing.
It’s helpful in the midst of all these changes to recognize that progress is not always forward. And that even the most challenging situations can be transformed into opportunities. In particular we benefit both personally and as organizations from having a time to pause. This can be a chance to reconsider the way we work together. Sometimes the most powerful thing a team can do is to regroup.
One of the challenges that development and IT operations teams have been experiencing for many years is the struggle to keep different environments in sync and to follow an orderly development lifecycle in a way that’s efficient and painless. The DevOps revolution has been extremely influential. But late adopters that have been contemplating shifting from a world of ad hoc deployments to a world of systematic innovation delivery, might now have both the impetus and the opportunity they’ve been looking for.
One area of significant concern is the significant slowdown in innovation many organizations experience as they attempt to scale up their teams. This is something that we’ve been pondering and analyzing. This blog is an attempt to share some insights into how teams can best structure themselves.
Those who build your Org build your company. Your development teams have an outsized influence on your organization. Your development teams build your apps. Your apps support your employees. And your employees support your customers. Therefore It’s critically important that you do a really good job in managing your development team and your development process.
I like to start by looking at what distinguishes a team from just a group of people. If you walk into a room and see five or ten people sitting there, is it a group or a team? You can’t tell; it could be either. A team is an emergent property of a group; it’s not just a group of individuals. What distinguishes a team from a group of individuals is that a team is working towards a shared goal.
We can perhaps distinguish three similar things: A group of individuals, a team, and a high-performing team. As mentioned, a team is necessarily working towards a common goal. A high-performing team is one which is far more effective than a typical team. The question then becomes how do you enable a high-performing team? To accomplish that you need special conditions to come together. A high-performing team can be understood as a team that has optimized the benefit that they derive from each individual. But in fact even more than that, a high-performing team enables each of those individuals to do things that they couldn’t possibly do on their own. That’s the real magic and power of a team.
“The purpose of an organization is to enable ordinary human beings to do extraordinary things”
— Peter Drucker
I think about three keys to developing high-performing teams. These are accomplished at three different scales: the organization level, the team level, and the individual level. The first key relates to organizational structure: how you design your teams relative to what your business is and the value you bring to your customers. The second key is how you enable alignment and collaboration on a team level. And the third key is how you unlock the motivation and drive of each individual.
KEY 1: ORGANIZE YOUR TEAMS AROUND CUSTOMER VALUE
In thinking about organizational structure there are two rules that are emphasized in the DevOps community which have an impact on how you structure your teams. The first is called Conway’s law, which basically says that your architecture will come to mirror your organizational structure. And the second is what I’ve started calling Domino’s law (a play on the pizza company) which is that large teams aren’t efficient. Therefore you need to do what Amazon does and have teams that you can feed with two pizzas. That means teams of at most 5 to 10 people.
One way to accomplish both Conway’s Law and Domino’s Law is to organize into stream-aligned teams. Stream-aligned teams are based on the concept of value streams. To understand value streams, begin by asking “precisely what value do we deliver to customers?” You need to identify all of the different products and services that you deliver to customers that bring value, and then understand the sequence of steps and workers who collaborate to deliver that value. The relationship from customer request through to fulfilling that request is called a value stream. It is extremely powerful to group the people who work together to deliver that value into a common team, and this is what’s called stream-aligned teams.
So for example if your team is building an application for your company’s customer service agents, then all of the people who collaborate to gather requirements, build the app, test it, release it and so forth all constitute one stream-aligned team. If you design your organizational boundaries around these teams, that enables them to develop expertise and deep relationships with these customer service users, so they not only can understand the application, but they can understand the customer service users and their jobs, and in fact they can gradually come to understand the end customers that these agents support.
In a similar way you can segment your users and the applications that they depend on, and organize your teams in a way that best supports all of those applications and end-users. There will of course be some shared metadata, that is inevitable. But you want to minimize that shared metadata, so that you minimize the need for these teams to coordinate just to do their job. That coordination is a tarpit, that can sink an enormous amount of time and energy. That kind of coordination is the main reason that we see large teams struggling to innovate at scale.
And of course, each of these teams should be a two-Pizza team, in accordance with Domino’s law.
Each team will benefit from having autonomy to choose the tools that work best for them and for their applications. At the same time, it’s powerful to have the centralized visibility, reporting, and economies of scale that comes from adopting standardized tools. Organizations should appreciate that both integration and differentiation bring their benefits and look to build on development platforms that provide deep flexibility and ease of integration.