Quick Wins are Neither

In the tech business, when was the last time a strategy of going for some quick wins actually worked out the way you thought? Quick wins, in practice, seem to consist of one of two things:

  1. A shoebox of wishes and magic feathers that someone, somewhere has been holding a candle for.
  2. A mixtape of amazing, blindingly obvious features and fixes that turn out to be technically complex and poorly understood power ballads.

It seems that quick wins never deliver the impact you thought they would or deliver it as painlessly as you thought they would. The next time your boss asks you for a quick win, do the following:

  1. Start by making a list of all the quick wins you could deliver.
  2. Look carefully at the age of each quick win. When were these created? Immediately discard anything older than six months, strongly consider discarding anything older than three months.
  3. Watch out for quick wins that originated as part of process initiatives or feature request workflow putsches that have gone stale.
  4. Can you trace each quick win back to its source then actually go speak to that person or persons about it? Will they describe the quick win exactly the same way it was filed, without prompting or leading?
  5. If a quick win originated as a feature request from a user or rhetorical set of users, think carefully about whether the playing field has changed since this was what they wanted. Maybe somebody had a bee in their bonnet, but now they have a hornet or wasp.
  6. Purchase a coffee for your engineer or designer or whoever's actually going to have to build your quick win. Get him or her to ballpark the amount of work honestly and fairly, then double the estimate. Tell your boss the high number and see how he or she reacts. In other words, if it wasn't quick, would you still want it?