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

In my previous blog post, I shared with you why the legacy approach of project and skill-based teams stands in the way of organizations becoming high-performing agile organizations that are able to innovate quickly, bring new ideas to market faster, and deploy advanced technology solutions in less time.

So what is the answer? Accountability and empowerment are a must for these high-performing agile teams. Accountable employees manage their workload according to team objectives, proactively seek help when they need it, take responsibility when they make mistakes, and do so in an environment where they are empowered and given the authority to do something. It is the direct opposite of micro-management.

In my experience, and now having worked with numerous enterprises to advance their digital transformation, I have found four key characteristics that enable enterprises to become high-performing agile organizations.

Single-Threaded Leaders

A single-threaded leader is a leader who is 100% dedicated and accountable to a specific product, such as your mobile application, customer account, or the search capability in your e-commerce store. The single-threaded leader is responsible for turning strategy into real results, and they are empowered to do so.

The best way to undercut a strategic initiative is to make it someone’s part-time job. Yet this seems to be the preferred way of working. The CIO declares the initiative to be critical, but no one is empowered to make it happen end to end. Everyone expects someone else to do it. This is where the single-threaded leader steps in.

I have found that some of the most critical elements in determining whether a team will be successful is the strength of their leader, whether that leader can dedicate time to the team, and whether the leader is empowered to lead it.

Look across your teams and your projects and see if you have single-threaded leaders. Are your team leaders dedicated to a single initiative or are they working on multiple projects and applications? Are they empowered to solve problems, make decisions, and deliver results, or do they need to scale the walls of bureaucracy to get approval and coordinate work?

If you have not already done so, move your teams toward a single-threaded leader model. Ensure that team leaders can devote time to leading their teams and making decisions about their product rather than chasing approval from higher-ups.

Lastly on the topic of leaders—and I can’t stress this enough—if you have a model rife with business liaisons or business partners, look hard at how they are performing. They are often trapped in a model that gives them neither accountability nor empowerment. They are far from single-threaded. But this isn’t necessarily their fault. Reconsider the role that these people play. They’ll likely bring more value to the business as single-threaded leaders. Empower them with dedicated resources and clear, focused responsibilities and objectives.

Small Dedicated Teams Built Around an Application or Service

Single-threaded leaders obviously do not stand alone. They lead dedicated, multidisciplinary teams composed of people with diverse knowledge and skills that spend more time doing and less time communicating. Instead of focusing on false measurements of progress, such as code delivery, tests completed, and new standards created, these teams spend most of their time developing stable code.

I am sure at this point you have heard of Conway’s law, which states “organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.” In other words, your organizational structure drives your system architecture to look much the same. Simply put, you will be hard-pressed to move to a modern microservices architecture if you retain your legacy skill-based organization as the organization model itself is complicated and diffuse. You need to rethink your organizational design if you are going to make this work.

Instead, take a customer view of the product. Organize small teams around products (let’s call these teams “product teams”) and make accountability and empowerment clear by focusing their scope, providing dedicated resources, and establishing clear objectives. This will help customers and stakeholders know who and how to engage to get work done. Don’t make your customers (internal or external) have to figure out how to work with you. Instead, you need to figure out how to work with them.

My colleague Bryan Landerman explained the approach to this model well in his blog post “Considering Size and Scope of Services.” He provides this handy description of how his teams work: “In order to own a product or service, we typically organize as small teams, typically five to ten people, that are each in charge of a single component of a product or service. The components must be small enough for the team to fully own, from ideation through operations. If the components are simple enough that a single two-pizza team can own several components, then so be it. But as complexity grows, we should intentionally simplify these components, shrinking them in size (or splitting them into multiple components) to ensure each component can be fully owned by a single team.” Consider this a roadmap for how to structure your own empowered product teams.

We find the highest performing teams are teams that operate under the model “you write the code, you fix the code.” Product teams are responsible for everything from ideation, through engineering, testing, and deployment, all the way into operations and maintenance. There is no longer Engineering and Operations. They have come together within the same product team and have a shared sense of ownership to deliver business value. They do not disband once a deliverable is complete and move on to the next project. This not only allows them to develop a deeper appreciation for their customer and their needs, but also permits a long-term view to experimenting and innovating. It also establishes clear accountability for performance, financials, and value and makes responding to issues much clearer.

These product teams are for all intents and purposes “ring-fenced,” and as such, there is less need to coordinate and communicate across teams. This allows for faster response time, more agility, and better innovation.

Guardrails, Not Tollgates

Leaders often say that they want accountable, empowered teams that can operate autonomously, but in reality, this is often half-hearted and hampered by the fear of letting go. What if everyone starts working on what they want? What if people implement a new technology? How will we ensure compliance? My colleague Gregor Hohpe says in his book Cloud Strategy, “Everyone doing what they think is best, isn’t autonomy. That’s anarchy.”

To overcome this anarchy but still maintain control, adopt a model built not on tollgates, where you need to pause and seek approval or coordinate work with another team before progressing, but on guardrails. These guardrails come in many fashions. Some are automated tests built by your service teams (e.g., Security, Compliance) into your DevOps pipeline that maintain or ensure compliance. These tests should be fully automated, largely invisible to developers, and minimize friction within the DevOps pipeline. There can be no more “throw it over the wall” or “submit and await feedback” attitudes in teams. Guardrails also show up in more subtle forms through shared principles and goals that give teams guidance and measurement against which they can base decisions in the field.

To truly lean into these guardrails, relentlessly weed your SDLC garden and look for bottlenecks. Map your SDLC and look for handoffs from one team to another and ask why the team was not empowered to solve their own problems or why the problem wasn’t addressed via a self-service capability. I have done this numerous times throughout my career and it is always illuminating and maybe a little disheartening, but you can’t fix what you don’t know. I have always believed that these are easy wins with a big impact. A 10% improvement in efficiency in your SDLC is a 10% uplift across every team.

Reimagine Trust

As a leader, you must create a model that empowers these product teams to meet control objectives, but also allows them to operate swiftly within guardrails. Control functions established by Security and Compliance must trust that product teams can and will be responsible stewards of organization-wide principles and utilize continuous testing frameworks. Likewise, product teams must realize that they own their own controls and are fully accountable for ensuring they deliver reliable, secure, and compliant solutions.

Falling short on this will relegate these nimble, fast, autonomous product teams to underperform as they are held back by bureaucracy and unnecessary communications. In short, they’ll be drawn back to a heavy-handed model of tollgates.

Two-Pizza Teams, Revisited

At Amazon, we call these product teams two-pizza teams. We strongly believe it is the right way to work. Yes, calling them two-pizza teams puts the focus on team size, but even more importantly, a two-pizza team is about autonomy and accountability. By focusing on single-threaded owners, small autonomous teams, guardrails over tollgates, and reimagined trust, you can build a solid foundation of accountability and empowerment, and you’ll be well on your way to becoming a high-performing agile organization.