Guess-timates and timelines

What do you hear when someone says that a product will be available in “Q1”? I’m guessing it could be:

• Jan to March
• Jan
• March
• Feb
• April (right after Q1)

Or if you hear “Early Q2”, do you hear

• April
• May (first half)
• May (second half — till the 31st) ?

Estimating timelines are hard. Quarters are a helpful starting point. In this post, I’ll cover:

1. Why we hear differently
2. Whether we should give up on timelines (no!)
3. How to drive clarity

1/ Why we hear differently

• Underlying assumptions: Mythical Man-Month puts it perfectly, and I paste the quote full “our techniques of estimating are poorly developed, more seriously, they reflect an unvoiced assumption which is quite untrue, i.e., that all will go well”. We assume everything will go well and that things take as long as they should take.
• Experience/optimism: If from one’s experiences, products shipped ~on time, and you are optimistic, you could hear Q1 as a firm January or early February. If you’re used to delays, and you’re less optimistic, you might hear March, potentially 31st March. Maybe at best mid-late Feb. Also, I love this quote on optimism — “all programmers are optimists. Perhaps this modern sorcery especially attracts those who believe in happy endings and fairy god mothers. Perhaps all the hundres of nitty frustrations drive away all but those who habitually focs on the end goal.” (Mythical Man-Month, pg14).

Credit to designstripe

2/ Do we give up on estimates? No!

Should we then give up on any timelines whatsoever? No!

• Experience builds the estimation muscle. One of the biggest joys of my time partnering with Coinbase product/eng teams is enjoying how experience drives greater precision in product rollout estimates. The delight of working with product and eng teams who have “done it before, multiple times” cannot be overstated. They KNOW what to do and what’s possible. As a cross functional partner — I love it!
• Experience builds communication muscle: One of the challenges of complex software construction is that there’s increased communication between teams (tasks cannot be partitioned — see pg 18-19 Mythical Man-Month). Experience usually means improvement in communication. The most effective engineers I see are great at communicating (writing especially) across all cross functions, and that helps them get things done on time.
• Aggressive timelines have value, because work expands to fill the time. Though I hate to admit it, if there’s more time, yes I’ll work towards that longer timeline. Work does expand to fill the time. Proceeds to hide from any TPMs reading this hehe. Sometimes starting with a target endpoint and working backwards (reasonably — a contract cannot sign in a day) does mean shipping faster.

3/ How to drive clarity

While I can’t speak to improving software development estimates (other than admiring when it's done well!), I try to drive more precise timelines in sales and partnerships. Some tips are:

1/ Play back timelines

It can be uncomfortable to ask for precision, and I know I shyed away from it previously. But even getting “earlier in the quarter” / “later in quarter” and monitoring that every few weeks is helpful.

2/ Benchmark with previous launches

Look at previous launches, ask about the dates, release timelines eg is it 1% roll out? Or all at once? What’s the timeline to get from beta to public facing? Which clients go first? What’s the process and how long does it take?

3/ Build in buffer

I fall prey to being too optimistic at times, but drawing next steps out in a spreadsheet, checking for business days / holidays / back and forth, helps to pressure test that.

Estimating timelines is hard — but it’s a muscle that can be built.

PS. I am grateful to the book Mythical Man-Month (collection of essays), and it has so many sharp insights (even for a non engineer). This post was very inspired by the specific “Mythical Man-Month” essay putting forth that more software projects have gone awry for lack of calendar time than for all other causes combined (pg14). It has so many funny quotes — highly recommend reading the full essay!