Two-Pizza Teams Are Just the Start, Part 1: Accountability and Empowerment Are Key to High-Performing Agile Organizations

Go Faster, Innovate More

Go Faster. Innovate more. It sounds like a simple directive. Almost every executive I talk to wants to bring new ideas to market faster, accelerate innovation, and deploy advanced technology solutions in less time. Oh, and they need to do all that while building secure, reliable, compliant, and resilient solutions. But how? Our legacy approach to organizing and empowering teams does not lend itself to doing this easily. True agility is not something you can order or purchase, and although the cloud certainly helps make these things possible, it alone will not achieve the benefits enterprises want.

What will? Accountability and empowerment are must-haves for high-performing agile teams. To truly become a high-performing agile organization, you must look at your organization structure differently and be willing to change your mindset and behavior. At Amazon Web Services (AWS), this starts with the concept of two-pizza teams: teams that are small enough to be fed by no more than two pizzas each, typically composed of five to 10 people. But just focusing on team size is not enough. The key to going faster, being more innovative, and utilizing new advanced technologies is to establish teams that have clear lines of accountability for delivering business value and empower them to do so.

In this post, I’ll discuss how our traditional organizational model holds us back from achieving our dreams of agility. In my follow-up post, I’ll propose practical strategies for baking accountability and empowerment into an organization’s structure. Let’s get started.

Skill-Based Teams Are Not the Way

Like many executives, I’ve spent countless hours over the past 25-plus years trying to perfect a model of organizing IT capabilities into dedicated skill-based teams. Everything is nice, neat, and tidy: all the database engineers together into one team, all the quality engineers together in another, all the software engineers together into another, and so on. Turns out, it’s easier said than done.

Theoretically, these teams draw upon their expertise to establish standards and best practices that create consistency, provide technical superiority, reduce risk, and drive down costs. It’s not that this model hasn’t worked to a degree—it certainly has helped organizations eliminate technical sprawl and standardize specific technologies. It just doesn’t work nearly well enough for today’s high-performing agile organizations. The skill-based organizational model focuses on how to manage technology instead of on how to leverage technology as a catalyst for innovation and strategic advantage. It’s not that innovation doesn’t occur, but rather that it tends to be more haphazard as teams rarely feel empowered or expected to innovate.

The legacy skill-based model compels enterprises to utilize project-based teams (project teams), where work is broken up and spread across several skill-based teams. This model necessitates multiple points of coordination and negotiation among teams to establish expectations, prioritize work, and synchronize deliveries. This is all very inefficient and prone to miscommunication and slow execution, and teams can easily become overburdened.

There is seldom a limit to how large these teams can become, with some growing to hundreds of people. Not surprisingly, as the number of team members increases, there is a direct correlation to a decrease in productivity. This is known as the Ringelmann effect, which attributes a larger team size to creating a loss of motivation and loss of coordination across the larger team. Large teams place a great deal of cognitive load on team members. For instance, when you have a six-person team there are 15 distinct relationships that need to be maintained. Sounds like a lot, right? By comparison, a 25-person team has 300 connections, and a 50-person team has 1,225 connections.

In my experience, I found these skill-based teams to be suboptimal. What about you? Do you feel that a skill-based organizational model helps you build solutions faster? Does it improve your compliance? Does it help you align with your customers and stakeholders? To be frank with you, I doubt that it does. In fact, I’m sure you’ve found it near impossible to avoid skill-based teams from becoming a bottleneck. It’s extremely difficult to achieve cost savings and standardization in skill-based teams while keeping up with the speed of rest of the organization.

Who Is Responsible for Results?

Skill-based teams aren’t just inefficient and unwieldy. They also create a behavioral barrier to agility. With so much expertise centralized in these teams, you would expect success to be inevitable. But in reality, it becomes virtually impossible to hold anyone accountable for results. On skill-based teams, somehow everyone is responsible for results and yet, at the same time, no one seems to be responsible…well, no one who can do anything about it. In most cases, there is not one person accountable for delivery who is also empowered to deliver. Each skill-based team has multiple deliverables, all competing for their time, and the one person likely focused on the complete deliverable, the program or project manager, often can’t reprioritize work or marshal resources and instead just escalates issues.

Compounding this is the transient and fragmented nature of these resources as they split their time and attention, switching from one project to another, resulting in them almost being incentivized to not take a long-term ownership view of anything. We see this when the responsibility for engineering and operation are on two different teams. The engineering teams build solutions without considering cost or how the product will be used. “That’s Operations’ responsibility,” they say. Operations responds by building a larger, more expensive infrastructure to “accommodate the poor engineering.” No one takes responsibility for costs, each just does their part. The process works as designed, and you, the executive, get stuck with the bill.

The large size of these teams plays into a psychological phenomenon called diffusion of responsibility. The more people that witness an event, the less likely anyone is to take action. People assume that someone else will take responsibility. This happens in these teams as well; everyone assumes that certainly, someone else will fix that, or check that this is secure, or make sure this can be deployed into production.

Even when someone wants to take action, their limited authority prevents them from being able to make meaningful progress. Instead, leaders of these teams are forced into situations where decisions are either made by consensus or require constant escalation to someone empowered to take action. This is the direct opposite of empowerment.

Who Can We Trust?

To manage risk—and to make up for the diffused responsibility in a skill-based team—we sometimes create processes that require teams to complete a gauntlet of heavy-handed audit-based control frameworks, approvals, and authorizations. This process is in theory designed to establish trust and attest to the quality and compliance of projects via a series of checklists and audits. But in reality, it is designed around the assumption that a developer wants to write noncompliant code, and the auditor’s goal is to catch them. This is not true. Overwhelmingly, developers want to write good code. Treating them like they don’t fosters distrust between parties, which worsens productivity. This lack of trust is exacerbated by the lack of cohesion and shared goals, and a throw-it-over-the-wall nature from one team to another.

The Business and IT

The skill-based organization structure, with its fragmented lines of communication and multiple handoffs, distances IT and reinforces the separation of IT from the rest of the enterprise. Teams are put into a position where they are often asked to deliver something for a customer that they don’t understand nor do they understand the problem to be solved.

Why is this? We have grown comfortable keeping technology at arm’s reach from rest of the enterprise. We have accepted the diffusion of responsibility and the anonymity provided by large ambiguous projects, making it difficult to establish clear ownership, shared priorities, and strong customer understanding.

In an attempt to overcome this, large program offices are created and business technology liaisons (or business partners) are hired to act as a conduit between IT and the business. Unfortunately, these roles are often unable to do more than take orders and communicate status, leading to more frustration and mystery as to what IT is working on. Additionally, engineers are asked to do three things they hate the most: (1) sit in meetings, (2) provide endless status updates to the PMO, and (3) communicate with one another. All of these activities pull or extract information from those doing the work, instead of letting them do the work.

All of this just makes working with IT harder and harder and often gives birth to shadow IT. More often than not, shadow IT emerges not because other departments want to run their own IT, but rather because departments are frustrated by delays, limited responsiveness, and lack of transparency from IT, and seek the path of least resistance to get something done.

Next Steps

All of this has diffused responsibility and accountability across teams and demotivates team members, as there is often no direct connection between results and recognition. Contributions go unappreciated, rewards are misapplied, and consequences are watered down or never occur.

We need a better approach. Ask yourself the following questions:

1. What kind of decisions are you, as a leader, making? Do you find yourself caught in the minutiae of a project?
2. Do teams that operate in secrecy from you, the rest of the organization, or one another?
3. If your project is late or a system is down, does it take several leaders and teams to sort it out? Does it take equally as many teams to work together to release new functionality?
4. Is shadow IT prevalent within your organization?

If you answered “yes” to any of these questions, you probably need to rethink how you structure your teams. It’s likely that your developers are not empowered to make their own decisions and are not encouraged to be accountable for their work.

The good news is, it doesn’t have to be this way. Perhaps you already understood the criticality of accountability, ownership, and empowerment. Or perhaps you’re starting to realize that your organization suffers from these challenges. Identifying the problem is half the battle: it’s time to think about how to fix it. In my next post, I’ll discuss practical ways to bake accountability and empowerment into your team structure and grow into a high-performing agile organization.