Quality and Speed are not opposites

You've probably seen and heard of the project management triangle. Scope, cost, and time. Also expressed as quality, price, speed; you can't have all 3 together. Stated in another way if you control for other variables, these three factors are always in tension with each other. You increase one, and the other that's being compared to is decreased.

In most real life practical situations we have a limited fixed budget, so on an operational level all we have are quality and speed to handle, and so there's always this tension in development where you can either get something fast, or you have to wait for it to be completed with a better quality.

Or at least, that's what common wisdom has taught us. But what if that intuitive piece of common wisdom is not actually true? How can it not be true you may ask? It feels like a mathematical reality. It feels as simple as a basic speed, distance, and time equation from elementary physics.

I have a different idea. Perhaps my most famous slogan while working as project director for Ephemeral Light was "Quality is speed, speed is quality". It was made into a sticker and pasted on the notebook that I was given as a gift to me by my team and studio. My fellow teammates would find this amusing. Quality and speed are opposites, right!? Well actually they're not. They're only opposites if you define them in a very specific way.

Speed-As-Compromise

The way we traditionally think of speed is as a synonym for corner cutting. When stated like that, of course it seems preposterous, because it is! However, this idea hasn't spontaneously appeared from the ether. There is a very real historical root to this phenomenon. It's simple, when a boss asks for you to "Get it done!" and "be faster!", what they're asking for you to do is finish something by a deadline no matter what. It's the Triangle in action: time, quality, cost. Quality will suffer when pushed.

When asked to get something done quicker, as in everything is the same except the deadline has been pushed forward, you are forced into making compromises on quality. In this sense, being "faster" just means making more compromises. That's not what being faster is supposed to mean though. Since when is corner cutting synonymous with speed? That's not what being faster means.

Speed-As-Completion Rate

Speed is velocity, right? So let's just define it as what it's supposed to be. A better and more accurate way of thinking about speed is as the rate of completion. How much output does the team/unit/individual have in a given day/week/month. As a corollary quality then can be defined as how much output can be generated.

A project's quality can only be increased by either increasing the time which costs money, or... increasing the speed. Quality is the distance, and more speed means either reaching the same quality faster or achieving more in the same time window.

This is what speed means. Not as compromise and corner cutting, but as the rate at which output is produced. With this perspective it makes sense to then say that quality and speed are the same thing. Speed is quality, and quality is [achieved by] speed. The part in the brackets is dropped for dramatic effect, but nevertheless it's true. Higher speed means you achieve more quality output, not less.

Now you may think that well speed in this sense is almost entirely fixed. People work at variable but statistically predictable averages. You can't just ask individuals for "more speed". That is all true, but you can work towards increasing the team's speed. The onus is on the project managers and leaders, not on the individuals to simply push themselves harder.

And there are many ways that speed can be increased. There's not a one-size-fits-all solution, but there are many examples. In fact there are so many that a majority of a good project manager's time can be dedicated to just this as there are always ways to improve speed.

A generic category of subset of ways to increase speed is to find bottlenecks and elevate them. As a crude example imagine a team of 10 people performing 3 linear processes, and we've split them into 3 groups of 5-3-2 people for each process. Over time we realize that the group with 3 people is overloaded with work, and the group with 2 is idle because they are waiting on the group of 3 to progress. We could switch one of the people in first process to the second group, so now we have groups of 4-4-2 instead. The middle group now gets more done, is less overloaded, and now the group with 2 people is no longer idle. The speed of the entire team is up, and as a result more work overall is accomplished, quality is raised.

There are many more ways too. Reducing distractions, reducing interruptions, improving communication efficiency are a few other generic category of actions that can be taken.

Quality-As-Fit

Now that we've established that speed and quality are synonymous from a mathematical lens, there's one more perspective that is important here too, which is about lead times and time to market.

There's many ways to frame this, but simply put, the faster you can get something done, the closer the project will be fit with the market. When a project or product is greenlit, it's made with a positive prediction that what we're making is going to succeed based on our understanding of the market. The longer time that passes, the more that understanding of the market has time to divert from the reality of it as the market and people more broadly speaking are fluid and in a constant state of change.

Your quality therefore not only is how much overall output you made but also how accurate your prediction of your product's market fit is going to be. The faster you can get the project done, the higher your quality due to the prediction being more accurate. Speed is quality.

Closing Words

Ultimately, the goal isn't to make people work faster. It's to make the work flow better. As producers and project managers, our job is to identify what gets in the team's way, remove unnecessary friction, and create an environment where people can do their best work without constantly fighting the process.

Not every trade-off can be avoided, and some things genuinely take time. But we should ask ourselves whether we're dealing with an unavoidable constraint or a problem in how we work. It's surprising how often there actually is a problem that can be worked when we might think there isn't.

Quality is speed, speed is quality. Not because they're exactly always interchangeable, but because the best way to deliver better work faster is often to stop treating them as opposing goals.