The first challenge you need to tackle is your company’s operating model. How are the teams structured, what are their responsibilities, how do they communicate, and how well does this structure align with the business goals? Does it allow them to independently deliver business outcomes to the customer? Is there a need for frequent hand-offs to other teams for routine day-to-day work? Do they lack expertise in areas that are critical to the functioning of their software, and so on?
Four foundational team structures can be adopted by organizations operating at any scale. Before we dive into the details, it’s important to highlight that these team setups might take slightly different forms, depending on the size and DevOps maturity of the organization. So, instead of applying them as a static template, consider them as inspirations from which new teams could be formed, or existing teams could transition into. Focus more on what value these structures bring and how they could help your teams focus on what they do best.
Value-stream aligned teams
These teams are laser-focused on a well-defined unique stream of work. They are your front-line warriors, always having well-established communication interfaces with the end customers, external or internal. The north star for this team should be providing business value to the end user. Depending on the company size and product offering, this single stream could be scoped to a complete product or service, a collection of features within a product, or something more granular if needed. What is important is that they take complete responsibility, starting from gathering inputs from the customers, understanding their pain points, developing software to address the gaps, and operating it in production. Companies such as AWS, for example, might want to align these team structures with different services that the cloud provider offers. So, a dedicated team might take care of AWS CodeBuild, and another could own AWS CodePipeline, for example. These teams have possess cross-functional skills that allow them to understand the business needs of the customers and translate those needs into software features. They should also have all the skills in-house for operating these workloads at a global scale. From a DevOps perspective, this checks all boxes, such as you-build-it-you-run-it, operating with autonomy, building with the end customer in mind, and so on.
Taking a different example of, let’s say, eBay, might warrant the need to scope the streams a bit differently. So, there could be a team responsible for checkout, one for product catalog listing, another for fraud management, and so on. However, the core principles remain the same. These teams should be able to deliver value almost independently of any other team in the company.
Another challenge organizations frequently face is how big these teams should be. To ensure effective collaboration, shared responsibility, and team dynamics, it’s a good rule of thumb to keep the headcount below 10-12. This is what Amazon also calls the2-Pizza team, a team that can be fed with two pizzas and has the full authority to make decisions in the best interest of their stream.
The other teams we are going to discuss are more enablers for the core value streams in your organization. They are the ones coming into the picture to offer support in areas that slow down the value streams in providing value to the end users.