“The best way to fail at inventing something is by making it somebody’s part-time job.”1

Speed, or more accurately velocity, which measures both speed and direction, matters in business. With all other things being equal, the organization that moves faster will innovate more, simply because it will be able to conduct a higher number of experiments per unit of time. Yet many companies find themselves struggling against their own bureaucratic drag, which appears in the form of layer upon layer of permission, ownership, and accountability, all working against fast, decisive forward progress.

“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.

During this phase, we became aware of another, less positive trend: our explosive growth was slowing down our pace of innovation. We were spending more time coordinating and less time building.

Managing dependencies requires coordination—two or more people sitting down to hash out a solution—and coordination takes time. As Amazon grew, we realized that despite our best efforts, we were spending too much time coordinating and not enough time building. That’s because, while the growth in employees was linear, the number of their possible lines of communication grew exponentially. Regardless of what form it takes—and we’ll get into the different forms in more detail shortly—every dependency creates drag.

growing number of dependencies delayed results, increased frustration, and disempowered teams.

The variations in technical dependencies are endless, but each one binds teams more tightly together, turning a rapid sprint into a stumbling sack race where only the most coordinated will cross the finish line.

When a software architecture includes a large number of technical dependencies, it is said to be tightly coupled, a bad thing that frustrates all involved

Our organizational chart created extra work in a similar fashion, forcing teams to slog through layers of people to secure project approval, prioritization, and allocation of shared resources that were required to deliver a project. These organizational dependencies were just as debilitating as the technical ones.

Too much of any kind of dependency not only slows down the pace of innovation but also creates a dispiriting second-order effect: disempowered teams. When a team is tasked with solving a particular problem and is judged by their solution, they should expect to have the tools and authority to complete the job.