Doing it fast

Friday, July 22 2022

Doing it fast

The fastest temporary fixes are usually the ones that are used for the longest 1. They’re done fast because they’re incredibly important. They’re used for a long time because as soon as they’re done they’re used, and it’s much harder to change a product or service that’s being used than one that is being played with, trialled, or ignored.

This is obviously, unfortunate. It leads to a strange distribution of quality in what you create, with great quality coming in for the low and middle priority items, and quality that may leave something to be desired for in the most important items.

Some ways round this could be:

  1. Get so good that you can produce high quality in a short space of time.
  2. Get better at recognising high priority items, so that you’re not left to the last minute to do it fast.
  3. Improve your processes and institutions, to have more mature conversations about what’s important and not leave them to the last minute.
  4. Get better at saying no and delaying releases until they’re of a high quality.

Only the middle points seem tenable.

However, the next time you see a ‘temporary’ fix that has existed for two years, it’s worth asking ‘is it that bad’? 2 It’s worth:

  1. Asking whether it’s just hard to understand
  2. Whether you could really build a better solution
  3. Whether the time spent building a better solution justifies the trade-off

  1. As a caveat this is generally if you don’t have mature processes or prioritisation. ↩︎

  2. A counterpoint to this is that things built at speed may be better because they were able to elicit a period of high focus or flow from the creator. ↩︎