When estimates becomes deadlines with consequences!

Introduction

Ever been asked "How long will this take?" when you barely understand what "this" even is? Everyone looks at you expectantly. You're the senior dev. You should know, right?

It can happen A LOT when "estimates" become deadlines with consequences. I see Agile often leading to this problem. Long-term estimates are sometimes done off very little information, and then the new information you learn through iteration can't even be used because nobody wants to cut scope.

This article tackles why some estimates are fundamentally flawed and what you can actually do about it.

The Reality of Estimates

Asking for estimates early in a project is like like the survival game "The Forest", you wake up in an unknown wilderness with no idea what's around you.

Imagine your collegue/friend asking you how long it takes to escape from a jungle when you've just been blindfolded and dropped from a helicopter.

Good Estimates

Pretend you are running from point A to point B, on a well-paved concrete road. You can probably guesstimate how long it takes you to run from point A to point B by car, right?

It's not even guessing when you had to go from point A' to B' in the past, or maybe you've seen other similarities/learnings from past projects. Maybe someone on your team took the same route once with a bicycle.

Those are actual data-driven and reliable estimates to communicate and plan on while still accounting for the surprise element or some sort of risk factor (a car is twice as fast as the bicycle for ex).

Bad Estimates

Projects with limited data sets or few similarities to past work aren't like that. You're more on the survival mode, just like the forest example above.

In order to figure out how long it will take to escape the island, you have to

• Do some locational grounding ("Where am I on the map?")
• Learn basic survival stuff ("How can I find food and water?")
• Simple exploration ("Is that running water? Maybe we can follow it to the sea…")

You can't wander around without knowing where to find food or clean water first, right? Similarly, you can't answer your friend before that given you know the least about the problem you are solving.

As time progresses you will become more and more confident as you hone in on your way off the island.

This is the collapse of the so-called Cone of Uncertainty. You've built your raft, you are cruising down the river at a predictable speed and can see the moon hovering over the ocean.

NOW you can make a reliable estimate!

When Estimates Should Actually Happen

Deadlines based on estimates should only really be given at a certain stage in the project. Here's few examples of when you can actually give meaningful estimates:

• Post domain familiarity: You've talked to users, mapped the business rules, identified the edge cases, prioritized problems etc.
• Post experimentation or POCs: You know what the technical challenges actually are, not what you think they might be and potentially have a dirty solution that de-risks/identify unknowns.
• You've identified the unknowns: You have a clear list of what you still need to figure out, and started to think off concrete risk, compiling Plan Bs etc...
• You've done similar work before: You have actual data points, not wishful thinking

Notice that most of these does not happen in the first week of a project.

The Agile Trap

Agile methodology, despite its good intentions, often makes this problem worse. The framework pushes for early planning and "commitment" to sprints and releases.

However people tend to confuse that implementation and directly ties it to upwards communications and overall project deliverables.

Here's a few symptoms of Agile gone wrong on a project:

1. Sprint Planning Theater: Everyone sits in a room pointing story cards with Fibonacci numbers on unsolved and unclear tickets/problems
2. Velocity Worship: Teams get measured on their "sprint velocity" then questioned on the ticket they bring and work they estimate
3. Commitment Pressure: "The team committed to this sprint" becomes "the team promised this deadline"
4. Scope Creep Denial: New information/risk emerges during iteration, but nobody wants to cut scope because "we already estimated/communicated X"

The result? Estimates become deadlines, deadlines become promises, and promises become grounds for performance reviews.

Real World Dynamics

Realistically, upper management often focuses on results and timelines, caring less about the implementation details and challenges faced during development.

This is understandable as they deal with different pressures and priorities, needing to focus more on deliverables and business impact rather than technical implementation specifics.

This makes the pressure flows downhill:

• C-level executives / Directors want predictable roadmaps for board meetings
• Product managers want to promise features to customers
• Engineering managers want to deliver results and meet organizational goals
• Developers get stuck holding the bag when reality doesn't match the spreadsheet

The truth is, most organizations are fundamentally allergic to uncertainty. They'd rather have a confident wrong answer than an honest "I don't know yet."

Welcome to the other side

The reality is more nuanced than "management bad, developers good." On the business side, we simply can't say "uhh, I don't know" when ramping up a new program or project.

Obviously in the beginning though, "uhh I don't know" is kind of the reality. Leadership isn't looking for a nailed-down super-accurate estimate.

They're looking for signs that the work is being identified and given critical thought.

Estimates Are Part of a Bigger Story

Your initial estimates are a component of the overall picture. When good PMs report timelines up the chain, they're also telling a story that includes risks, key decisions, resourcing, and important milestones. Execs all know (or they should) that the longer the timeline, the lower the confidence interval gets over time.

If a PM told their VP that the program is going to be ready to go to prod in Q2 2024, the first question is going to be about how they got to that date. Saying "That's just what engineering told me" does not fly.

But if they said: "We're estimating late Q2 24 go live, but we have XYZ open decisions and ABC risks that are being managed. The largest risk is this vendor timeline to release features we need in their product—they're currently estimating needing an additional 4 weeks, which has been figured into the end of Q2 timeline. We also are evaluating Software 1 and Software 2 to fit our needs, and are expecting a decision within the next two weeks". For sure, these are questions/uncertainties, but leadership knows the work is being well managed.

What Good Collaboration Looks Like

The real point, in the beginning, is to show that you have a good understanding of:

• What problem(s) you're solving for
• Your knowns and unknowns defined (think Johari window)
• How the work will impact the business
• How you'll measure success
• That engineering isn't going full wild west

Your job as a developer is to work with PMs to understand what a good, safe, and well-buffered estimate looks like for the work, and give them the information to show the why behind it.

Their job is to help you refine it and sell the result—backing your expertise up to the higher-ups.

Most good PMs I've seen want the super conservative estimate. They like to exist in the realm of under promise and over deliver.

When does the System Break

Things go south when:

• Engineers give estimates without context or confidence levels
• PMs strip away all the caveats when reporting up
• Leadership treats preliminary estimates as commitments
• Nobody adjusts the timeline when new information emerges

The solution isn't to stop giving estimates. It's to give better estimates with proper context, risks, and confidence intervals.

Practical Survival Strategies

Here's what you can actually do to survive this broken system and maybe even make it work better.

Give Estimates with Context, Not Just Numbers

Stop giving naked/half baked estimates. When someone asks "How long?", your answer should sound like:

"Based on what I know today, I estimate 6-8 weeks. That assumes we can get the API documentation from the vendor within the first week, and that the authentication integration works as advertised. The biggest risk is the data migration—if we discover the legacy system has data quality issues, that could add another 2-4 weeks. I'll have a better estimate after we do the proof of concept in week 2."

This does few things:

• Shows you've thought it through
• Gives leadership the context they need to report up
• Protects you when (not if) things change
• Set expectations on when the more accurate estimate or update would follow through

Document Everything

Document everything. Every tiny change, every missing design, every scope adjustment.

Keep it cold and factual like a war report. When/if shit hits the fan you'll need that paper trail.

Track:

• Requirements changes and when they happened
• Technical discoveries that changed the scope
• Dependencies that were unknown initially
• Time spent on "clarification" and "alignment"

Pad Your Estimates Like Your Life Depends On It

Always pad your estimates. Whatever time you think it'll take, double it. Then add 50%. They'll argue and cut it down anyway but at least you'll have breathing room.

If they question you, use the things you've documented to argue that optimistic estimates at this company are as useful as farts in a hurricane.

Historical estimates in the same org/company can help you pad things correctly.

Say No

Learn to say no like it's your job. Because it is your job. You're one of the people who knows what's possible and what's not.

When they come at you with impossible deadlines and shifting requirements, stand your ground.

Useful phrases:

• "We can hit that date if we cut these features..."
• "Based on what we learned last week, the estimate needs to change"
• "That timeline assumes zero unknowns, which historically hasn't been the case"

Forget About Reputation

What matters is delivering software that meets requirements. Better to be known as the team that's slow but reliable than the team that promises the moon and delivers swiss cheese.

Stop Trying to Fix a Broken System

Stop trying to fix a broken system. All these methodologies Scrum, Kanban, whatever are just Band-Aids on a bullet wound. Find what works for your team and ignore the rest.

Ending Notes

Organizations want the illusion of predictability as much as they want actual predictability.

Your job is to build software that works, communicate honestly about what you know and don't know, and protect your sanity in the process.

Estimates are tools for planning, not contracts for delivery. The sooner you internalize this distinction, the better off you'll be. Always experiment, measure, and understand the trade-offs you're making.

And remember: sometimes the most honest answer to "How long will this take?" is "Let me get back to you after we've explored the jungle for a week."