More on this book
Community
Kindle Notes & Highlights
by
Colin Bryar
Read between
June 12 - September 7, 2021
“single-threaded leadership,” in which a single person, unencumbered by competing responsibilities, owns a single major initiative and heads up a separable, largely autonomous team to deliver its goals.
our explosive growth was slowing down our pace of innovation. We were spending more time coordinating and less time building.
as the number of software engineers grew, their work overlapped and intertwined until it was often difficult for teams to complete their work independently. Each overlap created one kind of dependency, which describes something one team needs but can’t supply for itself. If my team’s work requires effort from yours—whether it’s to build something new, participate, or review—you’re one of my dependencies. Conversely, if your team needs something from mine, I’m a dependency of yours.
At last we realized that all this cross-team communication didn’t really need refinement at all—it needed elimination.
This gave rise to a process called New Project Initiatives (NPI), whose job was global prioritization. Not global in the sense of geographic expansion, but rather in comparing every project under consideration to decide which ones were worthy of doing immediately and which ones could wait.
Here’s how NPI worked: Once every quarter, teams submitted projects they thought were worth doing that would require resources from outside their own team—which basically meant almost every project of reasonable size. It took quite a bit of work to prepare and submit an NPI request. You needed a “one-pager”; a written summary of the idea; an initial rough estimate of which teams would be impacted; a consumer adoption model, if applicable; a P&L; and an explanation of why it was strategically important for Amazon to embark on the initiative immediately. Just proposing the idea represented a
...more
figuring out how to “boost morale” is not Amazonian.
Amazon’s approach to morale was to attract world-class talent and create an environment in which they had maximum latitude to invent and build things to delight customers
Morale is, in a sense, an output metric, whereas freedom to invent and build is an input metric. If you clear the impediment to building, morale takes care of itself.
instead of finding new and better ways to manage our dependencies, we figure out how to remove them.
He laid out the defining characteristics, workflow, and management as follows. A two-pizza team will:
Be monitored in real time. A team’s real-time score on its fitness function would be displayed on a dashboard next to all the other two-pizza teams’ scores.
Be the business owner. The team will own and be responsible for all aspects of its area of focus, including design, technology, and business results. This paradigm shift eliminates the all-too-often heard excuses such as, “We built what the business folks asked us to, they just asked for the wrong product,” or “If the tech team had actually delivered what we asked for and did it on time, we would have hit our numbers.”
Today the advantages of a microservices-based architecture are well understood, and the approach has been adopted by many tech companies. The benefits include improved agility, developer productivity, scalability, and a better ability to resolve and recover from outages and failures. In addition, with microservices, it becomes possible to establish small, autonomous teams that can assume a level of ownership of their code that isn’t possible with a monolithic approach. The switch to microservices removed the shackles that had prevented the Amazon software teams from moving fast, and enabled
...more
Autonomous teams are built for speed. When they are aligned toward a common destination, they can go a long way in a short time. But when they are poorly aligned, the team can veer far off course just as quickly. So they need to be pointed in the right direction and have the tools to quickly course-correct when warranted.
before any proposed two-pizza team was approved, they had to meet with Jeff and their S-Team manager—often more than once—to discuss the team’s composition, charter, and fitness function.
the specifics of how the proposed team would go about achieving its goal were not discussed at the meeting. That was the team’s role to figure out for themselves.
each team started out with its own share of dependencies that would hold them back until eliminated, and eliminating the dependencies was hard work with little to no immediate payback.
The most successful teams invested much of their early time in removing dependencies and building “instrumentation”—our term for infrastructure used to measure every important action—before they began to innovate, meaning, add new features.
Other teams, however, put off doing the unglamorous work of removing their dependencies and instrumenting their systems. Instead, they focused too soon on the flashier work of developing new features, which enabled them to make some satisfying early progress. Their dependencies remained, however, and the continuing drag soon became apparent as the teams lost momentum.
Sometimes it’s best to start slow in order to move fast.
We found it helpful to think of such cross-functional projects as a kind of tax, a payment one team had to make in support of the overall forward progress of the company. We tried to minimize such intrusions but could not avoid them altogether.
Two-Pizza Teams Worked Best in Product Development
Seeing its early success in speeding up innovation, we wondered whether it might also work in retail, legal, HR, and other areas. The answer turned out to be no, because those areas did not suffer
Fitness Functions Were Actually Worse Than Their Component Metrics
fitness functions never really delivered on their promise
The leaders who had been trying to get this service off the ground before Tom Taylor took it over were exceptionally capable people, but while they were tending to all their other responsibilities, they just didn’t have the bandwidth to manage the myriad details FBA entailed.
a single-threaded leader of Amazon Echo and Alexa had the freedom and autonomy to assess the novel product problems that needed to be solved, decide what and how many teams they needed, how the responsibilities should be divided up among the teams, and how big each team should be.
be stubborn on the vision but flexible on the details.
The STL delivers high-velocity innovation, which in turn makes Amazon nimble and responsive even at its now-massive scale. Free of the hindrance of excess dependencies, innovators at every level can experiment and innovate faster, leading to more sharply defined products and a higher level of engagement for their creators. Ownership and accountability are much easier to establish under the STL model, keeping teams properly focused and accurately aligned with company strategies. While all these positive outcomes were possible before the first autonomous single-threaded team was created, now
...more
The first is known as the “six-pager.” It is used to describe, review, or propose just about any type of idea, process, or business.
The second narrative form is the PR/FAQ. This one is specifically linked to the Working Backwards process for new product development. In this chapter, we’ll focus on the six-pager and in the following chapter we’ll look at the PR/FAQ.
“As analysis becomes more causal, multivariate, comparative, evidence based, and resolution-intense,” he writes, “the more damaging the bullet list becomes.”
“Making this transition in large organizations requires a straightforward executive order: From now on your presentation software is Microsoft Word, not PowerPoint. Get used to it.”
The real risk with using PowerPoint in the manner we did, however, was the effect it could have on decision-making. A dynamic presenter could lead a group to approve a dismal idea. A poorly organized presentation could confuse people, produce discussion that was rambling and unfocused, and rob good ideas of the serious consideration they deserved.
A boring presentation could numb the brain so completely that people tuned out or started checking their email, thereby missing the good idea lurking beneath the droning voice and uninspiring visuals.
The reason writing a good 4 page memo is harder than “writing” a 20 page powerpoint is because the narrative structure of a good memo forces better thought and better understanding of what’s more important than what, and how things are related.
How to Write an Effective Six-Pager
The goal is to introduce the kind of complete and self-contained presentation that only the narrative form makes possible. Embrace it.
We know that people read complex information at the rough average of three minutes per page, which in turn defines the functional length of a written narrative as about six pages for a 60-minute meeting.
Why not distribute the narrative ahead of the meeting so we’re ready? A: The short time between distribution and the meeting might not give all attendees sufficient time for that task. Also, since the document replaces the deck, no time is lost by dedicating this phase of the meeting to a silent reading that brings everybody up to speed before Q&A begins. Last but certainly not least, this gives each presenting team the most possible time to complete and refine their presentation.
How will we measure the success of this change? A: Great question. We have not been able to identify a quantitative way to measure the quality of a series of S-Team decisions today, nor are we proposing a metric at this time. Comparing the two approaches will be a qualitative exercise. We propose implementing narratives for the next three months and then polling the S-Team to ask if they’re making better-informed decisions.
An Amazon quarterly business review, for instance, might be broken down like this instead: Introduction Tenets Accomplishments Misses Proposals for Next Period Headcount P&L FAQ Appendices
Some groups at Amazon go around the room, ask for high-level feedback, then pore over the document line by line. Other groups ask a single individual to give all their feedback on the entire document, then ask the next person in the audience to do the same. Just pick a method that works for you—there’s no single correct approach.
During the discussion stage, it’s also important that notes be taken on behalf of the entire audience, preferably by someone knowledgeable about the subject who is not the primary presenter. The presenter is generally too involved in answering questions to capture effective notes at the same time. If I don’t see anyone taking notes at the discussion stage, I will politely pause the meeting and ask who is going to do so. It’s vital that we capture and record the salient points of the ensuing discussion, as those comments become part of the output of the narrative process.
Providing valuable feedback and insight can prove to be as difficult as writing the narrative itself.
Because examples of excellent six-page narratives are disseminated throughout the company, and because expectations about their nature and quality are so well understood by employees, it rarely happens that a team presents a substandard narrative at a meeting.
he assumes each sentence he reads is wrong until he can prove otherwise.
Narratives are designed to increase the quantity and quality of effective communication in your organization
The work product of the meeting is ultimately a joint effort of the presenter and their audience
