AWS re:Invent 2025 - A Leader's Guide to High-Performance Organizations (MAM225)

🦄 Making great presentations more accessible.
This project aims to enhances multilingual accessibility and discoverability while maintaining the integrity of original content. Detailed transcriptions and keyframes preserve the nuances and technical insights that make each session compelling.

Overview

📖 AWS re:Invent 2025 - A Leader's Guide to High-Performance Organizations (MAM225)

In this video, Matthias Patzak, AWS Executive in Residence, explains how to build high-performance organizations through six key characteristics: highly aligned, loosely coupled, outcome-focused, right-sized, well-controlled, and long-lived teams. He emphasizes that there's no one-size-fits-all operating model and warns against simply copying frameworks like the Spotify model. Key concepts include using commander's intent for alignment, treating dependencies as defects, reducing time-to-market from 49 weeks to 6 weeks by eliminating process bottlenecks, implementing hypothesis-driven development, and measuring business value delivered rather than output metrics. He discusses how AI agents will transform team composition while maintaining cross-functional capabilities, and stresses the importance of automation, platform teams, and stable teams to avoid "corporate psychopathy" of disbanding high-performing teams.

; This article is entirely auto-generated while preserving the original presentation content as much as possible. Please note that there may be typos or inaccuracies.

Main Part

Introduction: Beyond One-Size-Fits-All Operating Models

Welcome to this session, A Leader's Guide to High-Performance Organizations. I'm Matthias Patzak. I'm German, based out of Munich, Germany. I'm an Executive in Residence with AWS. Executive in Residence, we are a global team of former customer executives who have led transformation themselves. We talk with customers about technology sometimes, but most of the time we talk about people, process, and technology. And for probably 10, 15, 20 years, organizations want to know how to become more agile or how to become more efficient.

Actually, what do these organizations then do? Sometimes a leader photocopies someone else's organization. Who is familiar with the Spotify model? A few, actually. I like it a lot. I was CEO of AutoScout24 in 2014 when the Spotify model was released. It helped me to improve my organization, but you should not just photocopy someone else's organization. What other people do, on a plane back from a conference or re:Invent, they buy a book, they read it, and on the next day they ask the organization to implement what's in the book, or they hire one of the big five consultancies, put in a lot of money to ask them to implement the Spotify model, or implement what they have written in a book. But actually this is not how it works.

And the first mistake that some organizations do is that there is no one size fits all solution, no one size fits all operating model for an organization. Actually, in different areas of your business, in different areas of your organization, you want to apply different operating models. So for example, in an area where you need high predictability, you would provide low autonomy to the people. So this chart was created by a colleague of mine, the former CIO of McDonald's, and he said, Matthias, if McDonald's prepares fries in Mumbai and in Munich, they need to look the same, so you provide in this business process little autonomy to the people in the team. While if you execute an implementation of an ERP project or you want to reinvent retail as a strategic project, the outcome is unpredictable, so you need to provide more autonomy to the people acting in this project. And this is why there are at least two different areas in your business.

There's one where you have low variation, where you provide less autonomy, and this is where you want to optimize cost. This is where you want to reduce variation. This is where you use utility services like the AWS services. In other areas of your business where innovation happens, where you create custom-built solutions, you also want to reduce costs there, but they reduce cost of learning because you want to experiment and you want to innovate. The main KPI here is speed.

And this session is about how to become a high-performance organization. And our core beliefs in regards to a high-performance organization is agility. Being able to respond to change is the only competitive advantage. Second, your organization exists to deliver an outcome, not just output. And third, your organization has no end state. And this is why I like to quote Mike Cohn here. It doesn't matter how good you are today. If you're not better next month, you're no longer agile.

High Alignment Through Commander's Intent and Guiding Principles

From our perspective, when we talk to customers, a modern organization has six characteristics. First, being highly aligned. Second, being loosely coupled or providing local autonomy. Third, you focus on outcome, delivering business value and innovation to your customers. Fourth, being right-sized. At Amazon we talk about two-pizza teams. Nevertheless, being well controlled and long lived. So let's talk about being highly aligned.

This slide actually is out of the original Spotify model presentation, and from my perspective it was an important slide in realizing an important mental model in regards to operating models.

So usually what the agile community did for the last 20, 25, 30 years was we increased autonomy of our teams because with less coupling and more autonomy, you're optimizing for speed. But if you have a lot of autonomy in your organization and little alignment, everyone is acting fast but in any direction. This is not what you want. If you have a lot of alignment but you provide little autonomy, everyone is acting in the right direction but without any speed. What we want to create as a leader in an organization is an environment where you're loosely coupled, but nevertheless, all of your teams, all of your forces act like a vector in the same direction.

In such an environment, what does no longer work is top-down orders because in strategy execution by top-down orders, you face three important gaps. The first one is the knowledge gap. The leaders in an organization that create a strategy believe everyone else in the organization knows all the same things that they know. Actually, this is not true. Then we have an alignment gap. You can try to describe a strategy as well as you could, but it's really hard to align everyone on this strategy. And then it always comes differently than you think it might happen, and this is the effects gap.

If you want to have a highly aligned organization, modern organizations apply a concept that is called the commander's intent. So you're not providing a plan and you're not asking people to execute against the plan. Instead, you provide your intent to close the knowledge gap. You clearly communicate what you want them to achieve and the why, and the why is most important. Then you brief your teams on this intent. What is the objective? What are the resources? What is the environment, and what are the constraints? Then they are making the plan, and then you do a back briefing, so your teams tell you how they understood your briefing and how they are going to execute it. And then while they execute, you provide them freedom to adjust their actions because it's not about the actions, it's about achieving the outcome.

In such an environment, you need guiding principles. At Amazon, we are a principle-driven organization, but you can also have very specific leadership principles that should drive actions in a certain environment. At AutoScout in 2014, we did a modernization project. We had a monolith, we had our own data centers based on ASP.NET and Microsoft technologies on a large Oracle cluster. But we decided we wanted to modernize, and so we modernized our tech stack to being cloud native on AWS microservices and Scala. The only decision I regret, we can discuss this later over coffee. And so it was a huge change, and we created, driven by the former Chief Technology Officer of my organization, Christian Dega, principles.

We said we want to apply ability around it, so we created this leadership principle. We also said, please engineers in this organization, please be bold, go into production early, value monitoring over tests. So for sure we had a CI/CD pipeline with automated testing in it, but testing and monitoring is the new testing. We established fail fast but recover and learn, and optimize for the mean time to recover, not mean time between failures. This was a great fit at this point in time for my organization. It might not be a fit for your organization, but you can drive behaviors by describing principles.

Whatever you do in creating alignment, don't boil the ocean. We recommend that you become ready by starting and not start when you're ready. What I observe in many customer organizations I work with is that they try to create alignment by more communication, more involvement of the people. And this is a measure that creates more alignment but makes you slower. Actually, at Amazon, we believe communication is a sign of dysfunction because it means people aren't working together in a close, organic way. And at Amazon we should be trying to figure out a way for teams to communicate less with each other, not more.

Or actually communicate about what matters and not what everyone believes they could contribute to.

Balancing Local Autonomy with Organizational Performance: Treating Dependencies as Defects

Let's not talk about local autonomy or being loosely coupled. Actually, there are hundreds of thousands of talks in the agile community about being loosely coupled and autonomous, so I want to skip this part. Maybe this is then advanced or modern agile, and I want to talk about how much is too much autonomy. This is a quote from Gregor Hohpe. He was a team member of my team, and he said, "Everyone doing what they think is best isn't autonomy. That's anarchy."

So what do I mean with this? There's a correlation in organizations between autonomy and performance. If you provide more autonomy to your teams, the performance of the teams is going to increase. With the increased autonomy and performance of teams, the performance of the organization is going to increase as well, but just until a certain point in time. If you further increase the autonomy of the teams, the performance of the overall organization is going to decline, and the performance of the teams a little bit later as well.

For example, if you allow each of your software development teams to decide on their own technology stack and decide on the programming language of this team, that's awesome for the developers in this team but a nightmare for the overall organization in the midterm. So as a leader, as an organization, it's important that you as a development community in an organization find the sweet spot between local autonomy and organizational performance.

This is why I try to avoid using the word autonomy at all when I talk to customers. I talk about coupling, loosely coupling, being less coupled. When you want to reduce decoupling in your organization, which is a very important measure, treat dependencies as a defect. This is why Jeff Bezos said we should try to communicate less with each other, because every communication is as well a dependency.

We know how to reduce technical dependencies, and I don't know how many talks we have about microservices at re:Invent this year, but actually this is the way to go if you want to decouple your architecture. You introduce a microservice or a modular monolith. But I want to talk about how to reduce organizational dependencies.

In my role, I'm a sparring partner for executives, and sometimes I also do reviews, reviews of the organization. One of my core beliefs is that the most important part, the most important cell of an organization is the team. So I like to start these reviews in teams, and then I also review their scrum or kanban boards, however they organize the work. Each board is different, but basically they look like this: you have a backlog column or a to do column, you have a next column, an in development column, a waiting column, and done.

I do this review because I want to understand what is the time to market in this organization. If you would ask the engineering manager of this team or a developer, they would say our time to market is two weeks because we run in two week sprints. Then I ask, okay, what does done mean in your organization? And then I ask, okay, done means your user is using your software. Sometimes the answer is no, no, no, no, it's not. Done means it works on my machine, but then we have to integrate it into the testing environment, but this happens just once a quarter. So now time to market is ten weeks.

Then you ask, what does integration mean? Is it then being used by the user? No, no, no, no. Then business needs to accept it. That happens once a quarter. But then users are using it? No, not yet, because then our supplier needs to release it into production. What started as a two week sprint, very proud software development teams, is now a time to market of twenty-six weeks.

But it's getting even worse because then I ask about this backlog column. Where do the ideas come from? And then the story is like this. Our salespeople send us requests. We have a backlog out of 3000 requests. And because it's 3000 requests, someone needs to prioritize it, so we have a prioritization step. Now we have a time to market of 30 weeks because not all of them are very well written. You wait for clarification. Then for the prioritized items, we need to write a business concept. We do no longer write a business plan because business plans are so old school, so we write business concepts. But again, we need to clarify some data, some assumptions. We're going to wait. Time to market is now 42 weeks.

For all of the business concepts that were approved, we need to define a budget. It takes some time, and then our solution architects are going to write the software design and software architecture for the solution so that the developers in the team know what to do. 49 weeks from idea to impact. And this is why agile software development is not business agility. From our perspective, this is waterfall agile certified. And I encourage everyone to adopt agile in software development. But I also encourage everyone to apply agile for the rest of the process. And it's easy to reduce this time to market from 49 weeks to, we will see where we end.

So for example, you could just remove certain steps in the process. So why wait for approval for the business concept? Why wait for budgeting? Why wait for an IT concept? You could just do budgeting differently, not budget every single initiative, every single project, but you could do capacity-based budgeting. A business owner, a domain owner has a certain capacity, and this is a budget, and inside of this capacity, this person can decide what is the most important story you want to develop. Or IT concept, from my perspective, the developers in a team, they should be capable that they could design their software development design themselves.

Or very easy, you could just increase the frequency of steps in your process. Prioritization, not once a quarter, but once a month. Integration, weekly. Acceptance test and release monthly. Or you automate steps and actually, every single step in your development life cycle after software development should be fully automated. At Autoscout, we treated every single manual change to production as an incident. And so we were down to 6 weeks from idea to impact. And this did not need a reorganization. It was just working on the process.

Focus on Outcomes: From Feature Factories to Hypothesis-Driven Development

So let's talk about focus on outcomes. A lot of organizations reduce dependencies in the organization. They optimize for flow. They're finally being able to deliver features in 6 weeks and not 49 weeks, but they become a feature factory. They are able to deliver features very fast. They are optimizing for flow, but they are not changing business KPIs. And this is why we recommend as an organization you should really focus on changing outcome.

And this is why it's important. What is your definition of done? And from my perspective, done does not mean works on my machine. Done means someone's need was met. And someone should be your customer. And it's totally okay that you have some KPIs and some measures in your organization as a fitness function so that you understand how fit are you. But don't focus on story points completed, requirements developed, and test scripts completed. These are metrics that help you to understand how fit you are, but this is not the most important metric.

If you want to optimize for delivering outcome to your customers, you need to work backwards from your customers' needs, and this is how Amazon innovates.

We always work backwards from the needs and problems of our customers. You can't innovate inside a meeting room. If you want to innovate, if you want to deliver, I recommend that you get outside of your office building. Observe and visit your customer, your user in their natural environment. Observe how they use your product, identify their needs, their problems, and then try to fix those problems. There is uncertainty involved.

This is why I recommend research and development thinking in your software development process. Some organizations treat software like hardware. They design it, they build it, they ship it, and that's it. But it's software, and this is why I recommend hypothesis-driven development. There is a great blog post by ThoughtWorks about it, and actually as an organization you should describe every story like this. We believe this capability, this feature will result in this outcome.

For example, in an e-commerce shop, we believe this new payment method will result in a higher net promoter score, or maybe even better as an outcome, a higher conversion rate or more revenue. But the most important aspect is the third line: we will know we have succeeded when we see a measurable signal. So as a product owner, you need to define beforehand what is the KPI you want to change and what is the signal that you want to see that you believe this implementation was a success.

Most of the time if you ship a feature and you measure the impact via A/B testing, you won't see any signal, and this is totally fine. The signal then is you need to improve. You need to build, measure, and learn. I do believe that we should measure productivity in software development organizations. I've written a blog post about this, but from my perspective, these are the core performance indicators of a software development organization.

The most important one is business value delivered. So on a team level, for every release, measure via A/B testing for every feature whether this feature changes a business KPI. Then as an engineering manager, as a product owner, maintain an achievement log so that you are able to prove to your business stakeholders, to the business, to whomever, what are the actual achievements. You should measure throughput and cycle time in your organization.

Quality probably has twenty to thirty different metrics: functional, non-functional, security metrics. I talked about how no organization has an end state and you should always be agile and adapt, so you need to measure the motivation and the engagement level of the people in your organization so that you know when you can do more changes or fewer changes. We should have an understanding of cost, but from my perspective, being innovative and delivering business value is much more important than having a focus on cost.

Right-Sizing Teams: Two-Pizza Teams, Cross-Functional Skills, and the Agent Revolution

So let's talk about being right-sized. Right-sized is not just about the size of teams or the size of organizations. Actually it's more about having the right size, but also having the right people, the right culture, and the right skills. About right size: at Amazon we say no team should be larger than it could be fed with two American-sized pizzas. So it's not clearly defined, and the reason behind it is because in this example we have eight people on a team, but these eight people have to maintain twenty-eight communication channels, twenty-eight relationships.

Let's increase this number. Now twelve people. Twelve people on a team have to maintain sixty-six communication channels, sixty-six relationships. There are certain numbers in organizations and communities that define the right size of a group, and this is called Dunbar numbers. So five, 15, 150, and 1500 are population groups on teams, certain numbers.

When a relationship breaks and you have a different type of relationship in this organization, you should be mindful of these types of numbers in your organizations.

So let's talk about having the right skills. We believe powerful teams should be cross-functional with a cross-functional team set, and this is something that won't change with agents and agentic AI. It's the other way around. We will see as individual contributors in teams use agents, they will become even more cross-functional and more T-shaped. It's important that you have subject matter experts, that you have a healthy mix of junior and senior people in your teams, and it's important that you invest in reskilling, upskilling, and training.

So there is not a single right number from a sizing perspective, but we believe that a team should be small enough so that the people in the team can build personal trust, make decisions quickly, and be cohesive as a team, but also large enough to deliver outcomes, be independent from others, and have the cross-functional knowledge in a team to be able to deliver. And the size of teams might change. This slide might be true, might be wrong. It totally depends on the context of the organization.

But in the future, software development teams could look differently. So in this example, maybe you just have one product manager, one design lead, and one to two software developers, but each of the persons in the team uses several agents, and so you might have five to ten agents. Personally, I believe it will look differently. This slide assumes that just the software developers in the team will use agents and generative AI, so just the developers are being more efficient and not the designer and the product manager.

And so I believe the actual setup, the actual number of people in a team will stay very similar to what we see right now, but every person, every role in a team is going to be more efficient. From a technical perspective, the number of agents you can delegate work to is from a technical point of view unlimited, maybe just limited by cost. What really limits the number of agents a person can delegate to is the mental load that it takes when you try to delegate work to another person.

So my mental model or my analogy for an agent is that you can get a highly trained, highly intelligent, well-educated college graduate and you can delegate to them, so they work a lot, day and night, but they don't have experience, so you need to know how to delegate. Another example of how a team could be is this example. Data is becoming more and more important. What we see as an issue with central data lakes is very often missing ownership, and this is one of the core concepts behind Data Mesh, where the teams that create transactional data also take ownership about this data in the context of making this data available as a data product for analytical and AI users.

And so teams might also look like having one product manager, one business analyst, and a design lead, a number of software developers. In this example, also just two software developers, but two to three data engineers, one to two data scientists, and in this model also one DevOps engineer. In my organization at AutoScout, we had an ability to run it model, so the software developers also ran their code, and again, a number of agents.

And agents will be specialized, specialized by role, product management agent, design agent, software development agent, and they will be specialized on the business domain of the team. Because an agent needs to understand the software architecture and the business domain where it's being engaged,

and this will be part of the knowledge that you as a software development team provide to your specific agents.

Well-Controlled Organizations: Platforms, Automation, and AI Agents on Call

Why do cars have brakes? In a silent session, it's hard to ask, but how would you drive a car that doesn't have any brakes? Very slowly. You would drive faster. It's okay. And the same is true with organizations. We said we are optimizing for a high-performance organization. We optimize for speed. We reduce coupling. But you need to be well controlled even as a loosely coupled organization, loosely coupled in the sense that you need to have sensors that realize when something is going to happen that is not okay, and then you need to react very quickly as an organization.

With traditional operating models and traditional data centers, you have to decide if you want to be fast or secure. Startups, and I have a startup and scale-up background, they might decide, okay, we optimize more for being fast than being secure, while regulated industries optimize more for being secure while being fast. With modern operating models and cloud technologies, you can be fast and secure. But just as long as you provide the right measures.

Actually, what you want to create in an organization isn't set up like this. You want to have independent teams, cross-functional, very capable, that take risks. And they take risks because they know they're on a rope, so the blast radius of a wrong decision in your architecture, in your infrastructure, is limited. And this is the role of platforms in an organization.

For having a high velocity but well-controlled organizational setup, our recommendation is that you automate everything. So you should definitely automate your test and release processes and have a proper CI/CD pipeline. You should automate your infrastructure. This will also help you so that you can apply agents in your infrastructure. You should automate all of your security measures. This is one of the reasons why we just launched the Frontier Security agents.

And monitoring is the new testing. Observability is getting more important than ever. You need to have a real-time understanding of your infrastructure and your agents. And with one of the Frontier agents, the Incident agent, with proper monitoring in place, with infrastructure as code, these Frontier agents can react to incidents on your behalf.

And who builds these measures? Who automates everything? Actually, this is the purpose of platforms in organizations. In every organization, you want to have loosely coupled teams that share nothing and they're standing on the shoulders of strong platforms, platforms that provide tooling, services, training, and consulting so that the software and product development teams can be fast.

And what we see in organizations are three different types of platforms. One is the most common one, an infrastructure platform, software developer experience platform, developer happiness platform, however you want to call them. So they provide tooling and infrastructure so that the software developers can be simple, efficient, and stress-free. Data platforms in the sense of a data mesh support federated data teams, software development teams that take ownership for the data product to reduce the cognitive load of providing these data platforms, these data products, to the rest of the organization. Then most of the organizations have complex business systems where a lot of teams have dependencies to. And to manage these dependencies and the challenge of prioritizing all requests, usually these complex business systems are also part of a business platform.

What's going to change with agents, and especially with the new Frontier Incident DevOps agent, is how we handle on-call and how we handle incidents. Traditional on-call looks like this: a human gets paged, a human investigates, and a human fixes something. When you have agents on call, it looks differently. Because your AI agent gets alerted first, the AI agent investigates, but a human reviews and decides. And then your AI agent can execute pre-approved fixes, or the human intervenes.

Right now, this just works for certain types of incidents. So for the time being, agents will be able to work on your priority four and priority five incidents probably independently. Priority two and priority three incidents, there will be a human in the loop. And priority one incidents will always and still be managed by humans, maybe with the support of agents to investigate and analyze, but this is still the core domain of humans.

Long-Lived Teams and Conclusion: Preserving Domain Knowledge for High Performance

So let's talk about being long-lived. We invested a lot in this organization being highly aligned, being well controlled, loosely coupled. We invested in reskilling and upskilling. And then still some organizations work in a project-based approach, in an approach where they continuously change the teams. And with every change in a team, you disrupt this team. And this is why disbanding high-performing teams is worse than vandalism. It's corporate psychopathy.

We believe having stable teams is very, very important for the performance of your organization. And why is this? Businesses are complex, business processes are complex. Business logic is complex. So the people on a team, the product owner, the QA engineers, the software developers, it takes them a long time to understand the business domain. And if you change the setup of a team, you lose this knowledge. And the same is true for the infrastructure part, the software development part, the security part, so the technical domain of this team. Disrupting a team reduces the performance of the organization.

So we're coming to an end. These are the characteristics of a modern organization. Try to become highly aligned but loosely coupled. Focus on outcomes in your organization. Try to always be right-sized but also well controlled. And try to minimize changing your teams.

If you want to learn more about how to set up high-performance organizations, these are the books that the people on my team authored. My book is All Hands on Tech. I have five copies of them here as a giveaway if you want to have them. If you want to have questions, if you want to discuss, feel free to come to me here at the front after the talk. Thank you very much.

---

; This article is entirely auto-generated using Amazon Bedrock.