"Just give me a quick estimate."
Cool. You want fries with that too?
If you’ve ever worked as a developer, you know the question.
How long will this take?
Give me a ballpark.
Just need a quick number for planning...
Let’s be clear:
Asking for an engineering estimate without requirements, context, or time to think is like ordering a pizza without saying what toppings you want—or if you even have an oven.
And then being mad when it’s late, cold, and full of regret.
🧠 Devs Aren’t Psychic
You can’t expect accurate answers to questions you haven’t finished asking.
When someone says:
- “How long to integrate this third-party tool?”
- “What’s the ETA on this bug?”
- “Can you guess how long the refactor will take?”
...and provides zero detail, the only honest estimate is 🤷♂️.
🚫 Weaponizing Estimates Is a Leadership Fail
Bad estimates aren’t the problem.
Using estimates as commitments, ammo, or leverage—that’s the problem.
We see it happen all the time:
- PM gets an offhand guess, puts it on a timeline
- Feature explodes in complexity
- Devs are blamed for “slipping”
That’s not leadership. That’s corporate gaslighting.
🔍 Want Real Estimates? Do This Instead:
- Give clear requirements
- Let devs break down the work
- Encourage “I don’t know yet” as a valid response
- Ask for ranges, not single-point answers
- Don’t use estimates as truth—use them as a conversation
If it sounds like more effort… that’s because it is.
But it also means your team will trust you more, deliver more accurately, and spend less time rage-Googling “how to undo a commit from 6 days ago.”
🍕 TL;DR
Don’t treat dev time like takeout.
Stop asking for estimates like you’re ordering pizza.
Estimation isn’t fast food—it’s forecasting.
And if you're not bringing context, collaboration, and a little patience,
you’re just setting the table for a delivery disaster.
✊ LeadDontCtrl.com
Rebellious tech leadership. Delivered hot.