Korva is a scroll of the internet’s best ideas.
Good ideas can destroy a company
Bezos and the backlog
Early in Amazon's history, Jeff Wilke told Jeff Bezos that he had enough ideas to destroy Amazon. Bezos had been releasing ideas the moment they came to him, and each one created a backlog, a queue, a piece of work in process, and a distraction. An organization can accept work only at a certain rate, and the ideas were stacking up faster than that without adding any value.
Holding ideas back
Bezos learned to prioritize them better. He kept lists of his ideas and held them back until the organization was ready.
The founder's trap
The same trap catches any founder who generates ideas easily. Each idea can be sound, so nothing looks wrong. Picture a marketing team handed fourteen new ideas, two more arriving every day, a tweet about what someone else is doing, an event to attend, and a person to meet. The volume alone can suffocate the team.
Why does unfinished work slow a whole organization?
Little's Law, proved by the mathematician John Little in 1961, says the average time an item spends in a system equals the number of items in progress divided by the rate at which items finish. If the finish rate stays fixed and more work is added, every item waits longer. Software teams cap work in progress for this reason. A longer wait means each idea gets stale before anyone acts on it.
Why do queues explode near full capacity?
Queueing theory shows that waiting time does not grow in a straight line as a team gets busier. In the simplest model, the average wait rises in proportion to one divided by the share of capacity left free. A team running at 90 percent busy waits about ten times longer than a team running at 50 percent busy. That sharp curve is why a few extra requests can turn a manageable list into a standstill.
How did Amazon structure teams around limited bandwidth?
Amazon became known in the early 2000s for its two-pizza team rule, which said a team should be small enough to be fed by two pizzas. The rule kept teams from needing long meetings to coordinate with one another. Each small team owned a service and published the interface other teams could use. That design limited how much work any one team could be handed at once.
More from My First Million
