“That’ll take about 2 hours.”
Sounds precise. But it almost never is. Your time estimates are systematically off – and that has nothing to do with lack of experience. It’s the nature of work itself.
Why time is so hard to plan
When you estimate a task, you assume the best case: no interruptions, a clear process, no surprises. Reality looks different. Distractions pull you out of focus, complexity only reveals itself during execution and unknown problems show up exactly when you need them the least.
Time isn’t a stable unit of measurement for work. It fluctuates – depending on context, energy level and how often the phone rings.
A realistic view from the trenches
This is especially obvious in software development. You plan a task for 2 hours. Then an unexpected bug appears, a dependency doesn’t work and a detail needs to be completely rethought. Two hours become half a day.
There’s an ironic rule of thumb for a reason: estimate, add 20 per cent – then multiply by 3. Exaggerated? Maybe. But often closer to reality than the original estimate.
And this isn’t just a software thing. Whether it’s renovating, doing your taxes or “quickly tidying up the garage” – the best case usually remains exactly that: a best case.
The real problem
Precise time estimates suggest a level of control you don’t have. You’re measuring something that can’t be measured reliably. The result: false expectations, unnecessary pressure and frustration the moment reality deviates from the estimate. And it almost always does.
A better approach: T-shirt sizes
Instead of squeezing time into hours, work with relative sizes: S for quick wins, M for manageable, L for bigger and focus-intensive, XL for too big – needs to be broken down.
The key advantage: you think in scope, not in the illusion of time. And you immediately spot when something has grown too large.
The most important rule
No task should be bigger than L. Why? Because large tasks are hard to plan, tend to get postponed and create mental blocks. You stare at the mountain and don’t know where to start.
The solution is simple: break it down. “Build a new website” is a clear XL chunk. Split up, it becomes: sketch the idea, set up the technical foundation, define the structure, write the content, implement the design, build the tech. Suddenly a vague mega-project turns into a clear workflow – and every single step is doable.
Less estimating. More doing.
In the end, the key question shifts: away from “How long will this take?” – towards “What’s the next meaningful step?” And that’s exactly what moves you forward faster. Because what matters isn’t how well you estimated – it’s how consistently you execute.
heidenreich do!
