The thing that governs not just the speed of execution but also the satisfaction of a team is cycle time.

When companies are small they build simple processes to prevent different parts of the organization from diverging from one another. But those processes start to break down at scale. The more things that land in that process, the longer and slower it gets. That shifts teams from proactive (doing what they think is best) to reactive (doing the best that they can). That, in turn, undermines their ability to build conviction in their decisions which ultimately threatens overall cohesion.

Cycle time is a function of how many vertical leaps a discussion has to traverse and how many people are involved at each level. The best way to reduce cycle time is to reduce vertical leaps because it affects both variables. In layman’s terms, this means the most important change to make is to push decision making down. The target isn’t a true “bottoms up” culture so much as a culture of strong local leadership. Without this teams will default to org-chart oriented ownership which works but is slow.

Why is strictly running things by org chart position so slow? The primary reason is that managers have a great deal of overhead to deal with. Ideally every manager would have a sufficiently strong and tenured bench that they could spend most of their time on work, but if they aren’t in such a position it is the right thing for them to do to prioritize taking care of their people. As a consequence, more senior individual contributors should own decision making. More senior managers should have small teams. Performance management should not focus on “absolute impact” but rather “return on investment.”

Another way to improve cycle time is by having fewer levels to traverse when a decision does need vertical leaps and reducing the latency of escalations. One element of this is escalating early and often rather than letting issues drag out. One thing that helps with that is assigning a Single Threaded Owner for each critical area of work. That is someone who is 100% focused on the task at hand and has no other responsibility.

Another way to improve cycle time is by reducing the number of people involved in each loop. In tech, one of the major roles that product managers and product marketing managers are intended to play is to serve as representatives for a wide range of other disciplines. A document with 50 co-authors is not a well owned document. It represents an extremely poor use of time for everyone and a very diffuse accountability for the content. A meeting with 50 people is even worse. I applaud the instinct towards direct inclusion but if every discipline has to be in every meeting execution will suffer. Every discipline needs to be represented, of course, but such representation need not always be direct.

Many celebrate the idea of smaller meetings until they themselves aren’t included. If your team cannot be represented without being in the room then something is wrong and escalation is appropriate. Companies of every size should set goals of reducing time spent in meetings.

Another way to improve cycle time is to make decisions more durable so the cycle doesn’t have to repeat later. One way we have found to do that is make decisions on demos and prototypes rather than docs and decks.

Another way to improve cycle time is to do less. Most companies have excessive parallelization, insufficient prioritization.

Another way to improve cycle time is to eliminate bottlenecks. In part this goal is best achieved by reducing the people involved. But sometimes there are critical people who absolutely have to be involved. These must be identified early, properly informed of their importance, and do anything they can to not block progress. It is particularly painful if someone weighs in late and restarts the progress, so sequencing these is critical.

The final optimization for cycle time is making sure the process for managing it is smooth. Good processes make things go faster. However as development changes over time processes need to be updated and some need to be retired. The cost of a bad process is several multiples worse than the benefit of a good one.