You can't work in a fast-growing tech company without finding the perennial clash between wanting the product out by a deadline and those who are willing to wait until quality meets higher standards.

The truth is, quality vs. speed is a false dilemma. The reality is somewhere in between. We will sometimes release with known bugs, and sometimes a bug will need to hold up the release. Sometimes the bug doesn't break the release, but we hold it up anyway because it's a way to put pressure on the organization to implement a new paradigm, such as a refactoring of significant services, or a design system change. Releases may be sent out on time even in an incomplete state because of a 3rd party who has a hard deadline, or because we want to iterate on the feature and only need an MVP for now.

It's always nuanced. It's always imperfect. There is never a right answer that works in every situation. This is why it's so important to ensure that a company has a focus on quality over speed.

Any organization can move quickly. It's not hard. You just implement agile processes and hire talented people who play well with others. Sure, that can be a feat, but with an excellent interview process companies tend to achieve quick movement by following prevailing agile paradigms. The temptation will always be there to return to prioritizing planning and deadlines and busywork, but agile companies will not give in.

What can happen, though, when a company starts moving quickly is that the employees can start to cut corners. When management sees what employees are capable of in "crunch time" -- when the company has a high need to quickly for whatever reason -- they'll want to see if that velocity can be maintained after the need for it has passed.

In the short-term, any company can move fast, but sprinters are not marathoners. Marathoners can be fast relative to the distance they travel, but they can't beat a sprinter in a 100-yard dash. It just doesn't happen. So without a refocus on quality, the organization can fail to acknowledge the temporary nature of that sprinting velocity. This is where burnout can occur, but when the pressure to deliver quickly remains, burnt-out people will either call out this imbalance or save themselves and cut corners.

I argue that any organization that wants to continue to deliver quality at a fast pace needs to create a culture where it is okay to call out problems regardless of title or tenure. Quality matters and everyone knows that, but not everyone acts accordingly. Sometimes it is easier to ignore the few bugs that made it into Production because we had the deadline and everyone else was trying to hit the deadline too. Sacrificing quality is the easiest thing to do because we always want to get more value into the hands of users faster. If we can't call it out when quality is taking a backseat, then we can't rely on the organization to always prioritize quality.

The deadline will always have supporters. When the time it takes to achieve quality is at odds with that deadline, we need to know quality will have an advocate, and that the advocate will be heard when they speak up, and that they will be taken seriously by people in charge of whoever is responsible for setting that deadline.

In the end, deadlines are arbitrary. Plans don't ever go the way we expect them to. That's reality. Quality is not arbitrary. Quality is an ideal, and it is subjective, but it is also readily apparent to everyone when something is of poor quality, or when it could be of higher quality.

If we know it, users know it. Users can't see our deadlines, but they will always judge us on our quality.