Thread by @jwdanner

Reading books is a luxury that few startup founders have time for.

This is a summary of Working Backwards, the most important book to read for startup founders this year.

Here is what you should take away from this book:

The four main topics I found useful for founders are:

1 - Organizing Your Team

2 - Organizing Your Time

3 - Being Creative

4 - Building a Moat

Organizing Your Team

1 — One metric per team

The book does a great job of describing what happens without a single metric per team. When a team has a choice between two metrics or more to define success, they inevitably go for the more known metric, or the easiest one to move.

Amazon tried fitness functions which combines metrics into a formula, but realized how good people were at gaming these formulas. I would say only a quarter of my companies can show me an org chart broken down by teams with a single metric each. This works, you should do it.

2 — The smallest unit of organization is a pod with 6–8 people and larger teams are made up of pods.

The team must be completely autonomous, with all of the resources in their control to achieve their goals and no requirements to do work for others.

In startups, the most common problem with pods is that the people on the team aren’t senior enough to lead them.

Product people are often stretched across too many projects and engineering talent is too junior to lead an autonomous team.

These are forcing functions both for focus (do a smaller number of things well) and for hiring (hire people capable of leading an autonomous team).

In the case of a seed stage startup, this is why a single pod is the best.

Probably an equally valuable insight from the book is that larger teams are just collections of fully autonomous pods.

This is a massive change in approach from the departmental organization that still dominates many startups.

This is an area where larger tech companies like Facebook and Google are ahead of startups. They have had to disaggregate power and responsibility to autonomous teams to compete.

As you move beyond your first pod, replicate it to another autonomous pod. Don't centralize!

3 — Technically, the product needs to be separated into clean interfaces so teams don’t depend on each other and don’t step on each other’s work.

My favorite description of this is here (gist.github.com/chitchcock/128…) by a Google engineer describing why Amazon was ahead.

Ultimately this allowed Amazon to create AWS, but more importantly, it allowed Amazon’s pods to be completely autonomous, working with shared services through well defined interfaces.

Organizing Your Time
Instead of slides, Amazon meetings require a memo of no more than six pages.

That memo is read during the first twenty minutes of the meeting, with team members sitting together silently.

Using a narrative structure for discussion and decision making is superior because people need context to get their heads into the idea and time to think.

Slides benefit the presenter, because they withhold information that would allow participants to make independent judgments.

Some of my startups have gone even farther in the covid and post-covid era.

Instead of scheduling a meeting, they write a document, allow people to edit it, and hold a meeting if there are meaty disagreements or areas that they want to go deeper in a live session.

Being Creative
The second half of the book starts with a great quote from Bezos, “I believe we are the best place in the world to fail, and failure and invention are inseparable twins. To invent, you have to experiment.”

It is important to note that the type of experimentation Amazon does is dependent on single-metric autonomous teams.

Repeatedly they would put someone in charge of an experiment like a Kindle or other new product, and remove them of any of the burdens of their previous role.

The teams have no dependencies and no responsibilities other than to achieve their goal, and that unlocks the creativity necessary to find an answer if one was there.

Building a Moat
I would have titled the Prime chapter “Building a Moat”, because Amazon leaned into the single most difficult thing in the business — removing friction from shipping.

They built a solution that requires tremendous scale and may be the ultimate moat.

One of the most fascinating parts of the book is the narration of all of the things Amazon tried with high urgency before they got to Prime.

It dispels the Hollywood version of startup stories where the founder has a brilliant idea and money rains from heaven.

My advice is to buy the Audible version, (audible.com/pd/Working-Bac…) put it on 2x and listen to chapters 3, 4, 7, 8 and 10 while you work out. The whole thing will take just under 2 hours to read and likely will change the way you think about building your company.

I hope you liked this thread. I write about all of the issues facing early stage startups and finding Product Market Fit (PMF)

Please follow me @jwdanner and please retweet this to help other founders.

Here is a blog piece I wrote with some more detail in case you aren't tired of this yet :)

johnwdanner.medium.com/working-backwa…

And here is the PMF framework I use with my founder's to intentionally experiment until they find PMF:

docs.google.com/document/d/1ya…