Thread by @bothra90

The next time you’re prioritizing, create estimates first! Let me explain why:

(1/n)

Let's say you are trying to decide between which of two tasks (let's call them X and Y) to do first. Doing X saves $2000/day and Y saves $100k/day. Which one would you do first?

(2/n)

Instinctively, we feel compelled to do Y first. After all, its “impact” is 5x that of X. But there’s a fallacy lurking here (I’m not sure if it has a name 🤷 ) - we haven’t accounted for the amount of effort involved in doing X or Y.

(3/n)

If doing X takes 1 day and Y takes 3 months, it’s better to do X first. It only pushes out Y by a day (costing us $100k) but saves us $180k ($2000/day for 3 months). A net saving of $80k.

(4/n)

That doesn’t even take into account the fact that large projects are hard to accurately estimate and usually end up taking longer than originally expected.

(5/n)

If, on the other hand, X takes 3 days and Y takes 2 weeks, it’s better to do Y first because the cost of doing X first is $300k while the benefit is only $280k.

This is because X is no longer a lower-hanging fruit than Y.

(6/n)

In software engineering, a common rhetoric these days is #NoEstimates. Unfortunately, an extreme stance like this can prevent us from identifying quick wins like X that can have linear (or even compounding) returns.

(7/n)

My hope is we can embrace estimates without penalizing people or teams when they are off.

To get better at estimating read: jacobian.org/series/estimat… from @jacobian (h/t)

(8/8)