Same crisis. Same people.
One team unravels. One grows.

For twelve years, I led cross-functional tech innovation teams at Amazon and launched more than twenty products that reached millions of customers, with multi-billion-dollar customer impact. Along the way, I also made an extraordinary number of mistakes. I missed signals I should have caught. I ran meetings that should never have happened. I gave feedback that landed wrong, made decisions that looked reasonable at the time and embarrassingly stupid in hindsight, and occasionally led a room full of talented people directly into a wall.

What I also did, eventually, was pay attention. I learned from those mistakes, and I followed a natural curiosity: a stubborn need to understand why things work the way they do. Over time, that curiosity turned them into something more useful than regret.

The question that consumed me most was not technical. It was simpler and stranger: why do some teams seem almost effortlessly effective, honest, and resilient under pressure, while others, staffed with equally talented people and similar resources, quietly struggle? I watched this play out repeatedly. Same company. Same tools. Same hiring bar. Completely different outcomes.

My conclusion, validated over many years and countless situations, is that the difference almost never lives in the skillset. It lives in the culture: in small, almost invisible choices that accumulate into habits. Those habits define how a team behaves and communicates, and above all how it holds together when things get hard. As they always do.

The difference almost never lives in the skillset. It lives in the culture.

This matters more now than it used to. Most organisations run on playbooks: processes, plans, and best practices that work as long as the next situation looks like the last one. In tech, it rarely does for long. Markets shift, reorganisations redraw teams, and AI changes how the work itself gets done, often faster than any playbook can be rewritten. When the playbook stops working, teams fall back on their habits. That is when culture decides the outcome, and when a team needs practices it can rely on without a script.

I spent a long time thinking about how to share what I had learned. Frameworks felt too clean, and principles too abstract. The lessons that mattered most were learned in messy, human situations, and stripping away that context often stripped away the lesson itself.

I kept coming back to stories because they preserve the nuance that advice often loses. They show how good intentions and reasonable decisions can still lead to poor outcomes, and what those outcomes cost a team. So rather than presenting these ideas as theory, I chose to capture them as human situations.

Each story follows the same structure. It opens with a situation any tech company might face, then reaches a decisive moment, a fork in the road, where two teams, Team Alpha and Team Beta, respond differently, despite having no meaningful difference in skill, experience, or intent. Team Alpha takes the path that quietly makes things worse. Team Beta takes the path that makes things better. What separates them is a set of specific mechanisms: the repeatable, concrete practices that produce one outcome instead of the other.

At the end of each story, I describe those mechanisms directly: the ones that get more out of people, ship stronger products, and build a culture people want to work in. Each one is something you can start doing on Monday morning.

The stories are hypothetical only in form. None is a one-to-one transcript of a single real event, but every event in them is rooted in something I witnessed, took part in, or caused. I fused moments together, changed the details, compressed the timelines, and built composite characters. Some of it may feel exaggerated: the confrontations too sharp, the mistakes too obvious, the patterns too easy to spot. Usually they are not. If a behaviour or decision appears here, I probably saw some version of it many times, across different teams and years. What I exaggerated is the concentration: patterns that unfolded over time, compressed into stories that make them easier to see.

No single leader did everything Team Alpha does. No single leader did everything Team Beta does either. I pushed them into two extremes to make the lessons visible; reality is usually messier. Most of us move back and forth between these two worlds, sometimes within the same week, meeting, or conversation.

I am in these stories in more than one way. I am the narrator who already knows the lesson, but I am also in Team Alpha. Many of the mistakes in these pages are my own, made on days when I was tired, rushed, defensive, distracted, or unaware of what I was doing. I am in Team Beta as well, though less consistently than I would like.

Being a consistently great leader is extraordinarily difficult, and writing this book did not change that. What has changed is that I recognise those moments sooner than I once did: the fork in the road appears a little earlier, and I choose the better path a little more often than I used to. This book is meant to do the same for you, through fifty-five concrete mechanisms. I do not share them as someone who has mastered them. I share them as someone who has needed every one of them.

None of what follows is only for the boss, the manager, or the most senior person in the room. Every person on a team, regardless of title or tenure, can shape culture and influence how the work gets done. The behaviours in these stories are things anyone, at any level, can and should own.

Everyone is a leader. Every person on a team, regardless of title or tenure, can shape culture.

Many of the ideas in these pages build on the work of others: the writers, researchers, and psychologists I have learned from, and above all the leaders I have watched up close, good and bad. What I add is the work of turning them into practice. From everything I read and saw, I picked what held up under real pressure, connected ideas that rarely appear side by side, and refined each one over years of trying it in my own teams. The result is a set of concrete mechanisms, each tied to the moment where it changes how a team behaves.

The book is structured into five chapters, each built around a moment where the usual playbook stops working: a challenge that plays out in most tech companies, and that I have seen determine whether a team thrives or quietly struggles.

The first two are about people. The Launch Disaster is about psychological safety: the habits that determine whether people feel safe enough to admit a mistake, flag a risk, or ask for help before it becomes a crisis. The Friction Point zooms out from individuals to collaboration: the habits that keep people aligned and delivering together when pressure is real and disagreement is unavoidable.

The next two are about the work itself. The Olympus Bet is about execution: how a team keeps building the right thing, and knows when to change course instead of protecting a plan that no longer fits. The Choice Point is about decision-making: how a team defines the actual problem before debating solutions, and makes sure the strongest argument wins, not the most senior or most confident person in the room.

The final chapter, The AI Frontier, is about leading through rapid change. AI is the sharpest current example of the playbook no longer working, and the chapter’s mechanisms apply to any change that fast.

Looking back on those years and trying to make something useful of them turned out to be its own kind of healing, which I had not expected when I began: the mistakes that had weighed on me longest became the lessons I most wanted to share.

My hope is that something in these pages finds its way into your work, not in a defining moment but on an ordinary Tuesday: in a conversation, a decision, a small choice about how to lead. That is where the fork in the road usually appears.

It was launch day: the new customer-facing feature named “Polaris” was supposed to go live. Polaris promised every customer a precise arrival time for their parcel, such as “arriving between 2 and 3 p.m.”, updated as the parcel moved. The project was a cross-organisational effort, drawing together teams that had rarely worked closely with one another, each with their own priorities, processes, and ways of working.

The Signals team supplied live updates from warehouses and couriers: where every parcel was, minute by minute. The Orders team ran the order records that dozens of features shared: order histories, returns, refunds, customer service. At the centre sat the team that built the engine itself, the code that read the live updates, predicted when each parcel would arrive, and wrote that time into the customer’s order. That is the team this story follows.

For six gruelling months, this unlikely alliance had worked through everything a major product demands. It began with a planning document that forced the group to agree, sentence by sentence, on exactly what they were promising their customers and why, before a single line of code was written.¹ Only once that document had survived its reviews did the real work begin: engineers writing and shipping code, scientists developing and tuning models, designers refining the look and feel. Running alongside it: weekly cross-org progress reviews, late-night debugging sessions, and the kind of methodical error hunts reserved for the highest-priority features.

The release date had already slipped twice, despite everyone’s effort. With so many teams involved, every change needed three sign-offs, every handoff was checked twice, and every review waited on someone else’s calendar. By the time the date finally held, the teams were carrying the exhaustion of people who had been sprinting for too long. But underneath the tiredness was excitement. Polaris was an impressive piece of work, the kind of feature that could change the customer experience. Everyone involved had given more than was asked of them, and felt that whatever happened next, they had earned it.

Across the building, the contributing teams gathered in their own conference rooms: some had chilled champagne ready, others had laid out finger food. Usage dashboards were projected onto screens. Everyone’s attention was fixed on two numbers: how many customers opened the new tracking view, expected to climb within minutes, and the volume of “Where is my order?” contacts to customer service, which the feature was built to cut in the weeks ahead. With a single click, the code went live.

Then came the silence.

The first number did not move. The new tracking view was nowhere to be seen, but that was almost secondary. The second number moved the wrong way. The launch had broken something deeper: the order records that millions of customers relied on every day were filling with nonsense. Customers who had never heard of Polaris opened their order history to find parcels marked as cancelled, or delivery dates that had simply vanished. One customer, waiting on a birthday present for the next morning, was told it had been cancelled. Contacts to customer service were climbing by the minute.

The first instinct was the obvious one: roll back. Within minutes, the new code was offline. The orders stayed broken. Something in the launch had overwritten the order records that other features relied on, and taking the code offline could not undo what had already been written. This was bigger than a bad release, and nobody yet knew why.

A massive bug had slipped through the final review. Later, the reviews of what had gone wrong would call it a complex failure: one that grew out of small, individually harmless decisions which, combined for the first time under live conditions, produced a disaster. The root cause sat where several teams’ responsibilities met. No single group had messed up in any obvious sense. The system itself had failed. And the system was all of them.

This was the fork in the road. From here, the story splits. In one world is Team Alpha. In the other, Team Beta.

Both versions of that team had been all-in on the Polaris launch, and so had their leaders, who had each put six months of personal capital and credibility into making it succeed. Both watched the same dashboards turn against them. Both worked out, in the same few minutes, that rolling back would not undo the damage. Same disaster. Same impossible pressure. Same room waiting for someone to speak first.

Let us see how Team Alpha and Team Beta each respond.

1 Many companies start with a product brief. At Amazon, it is the PR/FAQ, the first step of Working Backwards: a press release written from the customer’s perspective, followed by the hard questions on feasibility, cost, and risk.