Poorly Built Racecars Don't Win

Imagine you are setting off to win an ambitious car race. You assemble a team of folks with plenty of experience and lay out a plan.

A simple guiding principle is at the core of your plan—faster is better.

You source parts from the places that can get them to you the fastest. Your team wastes lots of them by trying to assemble quickly. They strip bolts, snap parts, wear out gaskets, and lose things as the shop floor turns into a warzone of activity.

You set aggressive milestones for the car’s construction, so the team works late to reach those milestones. They set up brakes as fast as they can. They quickly bolt on steering. They work hard and fast, and all the while, there’s a sentiment brewing among your team—this car isn’t safe.

On the first day, starting the car ends in disaster. So does the second attempt and the third. People shout and point fingers as to who messed things up this time. The team works late again, trying to get the car to start.

Eventually, the car starts running, and the next milestone is a test drive. Before getting in for the first drive, the driver asks if there’s anything they should know. The team has about a thousand things they want to say, but instead, “Just take it easy. We know there are going to be problems.”

The car stalls out. It shudders violently on the road. It drifts. There are smells of burning plastic, rubber, and gasoline filling the driver’s seat. The car struggles to turn off and the brakes scream, spark, and do not stop the car the way they should.

The team muddles on, working late to fix what they can, trying to meet the deadlines in time for the race. On the big day, the team is exhausted and nervous. The driver gets in, and the race starts. The car never finishes, though.

This analogy is about how most software groups work.

While teams and leaders discuss quality often, it is a far lesser concern than raw speed. Quality is something you can worry about after you get the job done.

Software launches are plagued with hotfixes, outages, brittle infrastructure, and performance problems. Customers abandon the product as the team scrambles through the nights to get it done and meet the next deadline.

Take, in contrast, a professional team operating with a well-defined set of quality standards, practices, and approaches. The shop floor is clean and white without a trace of oil. Every tool is where it belongs, and parts aren’t wasted. The driver gets into a car he knows was built by a team of professionals who prioritized quality. That team’s car starts the first time and performs well. They spend time improving performance instead of trying to get it to exist.

These two groups start with the same intent, to win races, but while one spends extra on parts and overtime and ultimately struggles to complete a race, the other stays much closer to budget and performs better in the race.

The major difference is the second team understood that quality makes you go faster.

If you’re in a team or leading one that seems never to have enough time, can’t catch up, and is always fixing and dealing with the mistakes of a few weeks ago, the time is to shift focus from speed and focus on quality.

As your team learns to do things well, they won’t suffer problems of the past because they won’t exist. When a software bug can take 4x as much time to fix as it did to create, the savings are staggering.

Don’t get me wrong, shifting to focus on quality will make things worse before they get better. This will happen for an unfortunate reason—nobody actually knows how to do quality work.

Accept the growing pains and make quality part of how all work happens, and you’ll see the changes within just a few months. You’ll see the stress of your team drop, your releases will be a footnote, and your team will begin to make progress in a way you’ve never seen.

If you want to win a race, don’t focus on speed. Focus on quality.