Throughout my career the question of "quality vs. speed" has always been a topic of spirited debate. The premise is that these are competing values, with some people, teams, or companies focused more on quality while others focus more on speed. It is almost like there is an implied spectrum, with quality on one side and speed on the other, so that you could assign every individual or team a "quality vs. speed score" from 0 to 100 to define where they fall on the spectrum, describing their relative attention to building high-quality things and moving fast.

The wrong question

My view is that the "quality vs. speed" question is poorly formed because it has a false premise. If there really were a spectrum, and if either quality or speed were in fact "more important", then one end of the spectrum ought to be "better" than the other. So let's consider the two ends.

Someone on the "quality" end of the spectrum would optimize for value per change: for every deliverable they produce, it should provide the highest possible value. "Do the best possible version." "Anything worth doing is worth doing right." Etc. This approach is known as perfectionism.

The problem with perfectionism is that it does not include the crucial variable of time. It makes a big difference whether the "best possible version" takes 2 hours to make, or 2 weeks, or 2 years. It also neglects to consider the surrounding context: if I'm a professional chef, I might want the best possible cookware, but not care as much about my shoes. If I'm a professional athlete, the opposite could be true.

I believe that optimizing for value-per-change comes from what most of us experienced during school. In school, the number of challenges we are given is fixed, and the best possible outcome results from completing all of those challenges as well as possible. The real world is not like this: we are not all given the same assignments. The best outcome for you is often not to deliver the A+ version of everything someone else gives you to do; often, the best outcome requires far more proactiveness—delivering more than strictly what was asked—and a willingness to iterate.

Someone on the "speed" end of the spectrum would optimize for change over time. Do things as fast as possible, then move on to the next thing. You might also call this "quantity over quality".

In contrast to perfectionism, which leaves out the variable of time, the speed-over-everything mindset leaves out the variable of quality, or value. If you can deliver 100 new products in a year, but they're all basically worthless, is that truly better than delivering nothing?

So if we only cared about quality, then we would say that whether you complete 1 project in a year, or 5, or 20, it makes no difference: all that matters is the average quality of them.

Meanwhile, if we only cared about speed, then we would say that whether the projects you complete in a year are F- quality, or C+ quality, or A+ quality on average, that doesn't matter: what's important is simply the number of projects you complete.

If we plot what these two approaches would look like over time, we would see something like this:

The right question

Rather than value-per-change, or change-over-time, I believe the right thing to optimize for is value over time. It is not that quality matters more than speed, or that speed matters more than quality, in any objective sense. What we are ultimately striving to do is to use the finite time we have to provide the greatest value within that time.

Remember bivariate optimization in math? This is where, say, you have 100 ft of fence and you need to enclose the largest possible rectangular area. Doing this requires solving for two variables (in this case, length and width) to maximize their product (area) with the constraint that they must add up to 100 ft.

You could "optimize for length", making the enclosure 48 ft long and only 1 ft wide. Or you could "optimize for width" and make it 48 ft wide and only 1 ft long.

Both of these approaches are clearly wrong: we can see that it isn't true that "length is more important than width" or vice versa. The thing we want to optimize for—the area—is a function of both of those factors. They need to play together.

I believe quality vs. speed is a false dichotomy. It is like asking about "length vs. width", pitting two dimensions against each other when what we actually care about requires both. Reimaginging the same spectrum I shared earlier with the two ends relabeled, it suddenly looks very silly.

So why does it sometimes probably feel to my teams like I only care about speed (or maybe your local leadership team is the opposite, and they seem to only care about quality)? Well, one possible explanation is that I'm just wrong. But another possibility is that speed or quality actually can be "more important", not objectively, but relative to the current state of things.

Getting the car where it needs to go

Here's an analogy I've shared in the past: imagine you and your team are driving a car through open wilderness, towards some important destination.

Suppose you and your team members get in the car, check your instruments, validate you're headed the right way, then drive 10 ft. forward. You stop, check your instruments again, validate again, and drive another 10 ft. And so on.

In this scenario, your group is focusing too much on heading the right direction, and not enough on getting there faster. To them, as an advisor, I might say: "Stop getting out of the car so much and just GO."

Or suppose your team gets in the car, figures out what direction you want to go, and then just floors it, racing for hours without stopping.

In this scenario your group is too focused on moving fast. You could be veering wildly off course, even heading 180 degrees the wrong way. If I were advising them I would say: "Whoa there, you're going the wrong way. Pause and check your instruments. Stop and check every now and then."

If we have a destination, we need to know both: (a) are we heading the right way, and (b) how fast are we moving. If we just know we're heading the right way, but we're only moving 2mph, it's going to take us a long time to get there—possibly so long that the destination won't even be worth reaching by the time we get there. Meanwhile, if we're moving 100mph, but heading the completely wrong direction, that doesn't do us any good either.

Clearly the "right" way to drive the car involves a balance between paying attention to where you're going while also moving as fast as possible. In practice, most teams are often too focused on one or the other.

Why speed gets all the love

As I've written before, it is very common that different people need to hear different things.

If my teams feel like I'm always telling them to "move faster", it doesn't mean "speed is more important than quality"; it means I believe their balance is off and there's a better way to get to the destination.

A lot of intelligent, hard-working people prioritize quality over speed by default because they don't consider the time dimension. Again, I blame the wrong lessons learned during school for this mindset, as every student in a class is forced to the same schedule (all take a quiz or a test on the same day, assignments are due the same day for everyone) so that time is fixed and quality is the only variable. In an academic setting, there is generally no bonus for completing assignments early, or for completing 2x the assignments of your peers. Sadly, the people who most need to unlearn this lesson are the A students! They are the ones who "won" in school by focusing solely on quality (i.e. getting the best possible grade).

The other thing is that I know we all want to put our best foot forward, which sometimes means planning to put our work in customers' hands when it's mostly "done", i.e. let's say 90% done. Sometimes I ask if we can ship something sooner, not necessarily because I want the overall project timeline to be shortened, but because I believe the end result will be higher-quality if we start getting feedback from customers much earlier in the process, giving us more time to incorporate that feedback into our work.

Area under the curve

The visual I tend to have in my mind is like this: imagine the value you deliver as an area chart, with time as the x-axis and value delivered (cumulative) as the y-axis. Essentially what I believe we want to do is to maximize the area under the curve. When we think about it this way, the following statements are all pretty obvious:

Quality (delivering more value) is good.

Quantity (delivering more things) is also good.

Delivering value earlier is good.

These things are all good. At any given time, we should ask ourselves: what maximizes area under the curve?

There is no set formula here. You could be Harper Lee and create one incredible masterpiece, win the Pulitzer Prize, and have greater impact than most of us would have in 10 lifetimes. You could also hustle your whole life, build 100 companies, and ultimately fail to leave a mark.

What we all have in common is that our time is always limited—the time we work on a project, the time we're together as a team, the time we work for a company, the time we're here on this Earth—and in the end we want to make the most of it.

Did you enjoy reading this?