Optimize for the speed of learning, not the speed of doing

Jacob Singh, who was the CTO for Grofers, is currently part of Sequoia India’s CTO in Residence program.

We all want to “move faster.” But speed is a sneaky thing to measure. While speed in execution is great, most organizations fail because they build the wrong things, not because they take too long to build them. So what we really need is velocity.

Velocity = Speed x Direction

This may seem like a pedantic difference, but perversely many of the things we as founders and leaders try to do to make things faster, actually reduce our velocity. There’s a good reason for this and it stems from us misunderstanding what type of problem we are dealing with.

Most of our lives we have been trained to address complicated problems with a certain set of tactics, but startups are by nature complex problems and require an entirely different approach. This post will show you mental models and tactics to help you plan less, build less, learn faster and keep your teams communicating effectively in these complex environments.

Dave Snowden at IBM created a framework for leaders to determine which type of situation they are in and how to assess it. This framework is known as cynefin (pronounced kun-ne-fin).

Most problems we faced in work and school were complicated problems. Complicated problems have clear goals and a fairly well understood correlation between inputs and outputs. For instance: Solving a sudoko is complicated. We know the rules, and the faster we can find patterns, the faster we will complete the task. If I am faster, or if I put multiple people on the puzzle, we’ll get it done faster.

Chess on the other hand is a complex problem. Throwing more chess players at it probably won’t help and the game continues to change as we react to our opponent. Complex problems have a high degree of the unknown. The goal shifts as we work on it – we may need to toss out many initial assumptions as we progress. Our direction needs to change frequently as we work.

A Complicated problem is one where the plan is rational and works, we know the direction, so the analysis and speed of execution is the most important.

Our progress in Complex situations is limited not by how fast we move, but how frequently we calibrate our direction.

A complicated problem looks like a boat race, a complex problem is a voyage to discover a new land.

Learning how to read music is complicated, writing a hit song is complex

Running an automobile factory is complicated, designing a car is complex

Making software scale to millions of users is complicated, building a product a million users want to buy is complex.

In startups, particularly venture backed ones, founders are looking for outsized results. Outsized results are always complex because if it was obvious what needed to be done, everyone would be doing it.

Complicated problems are solved by a cycle of:

• Sense (see there is a problem)
• Analyze (send in experts to analyze the problem and devise a solution)
• Respond (act out the plan and realize the gain)

Complex problems are solved by a cycle of:

• Probe (run many experiments to find out how the system works)
• Sense (analyze the results)
• Respond (Change plans, double down, start again)

This post is the first in a three-part series that will highlight three principles you need to embody as a team to combat complex problems:

1) Be wrong faster: Don’t make plans, make progress.

2) Start less, finish more: The art of doing more by doing less at once.

3) Minimally Viable Process: Dude’s law and the virtuous loop