The productivity graph is broken and we’re pretending it’s fine
You know that neat little curve in project planning tools that suggests you’ll produce value at a steady pace from Monday to Friday? It’s a lie. Not a malicious lie. Just a completely detached-from-reality one.
The myth of the 8-hour brain
Most jobs still pretend that productivity is something that can be sliced neatly into eight equal hours a day. But if you’ve ever done any kind of deep, focused, creative, or strategic work, you already know: it doesn’t work like that.
“Sometimes I work 40 hours in one day. Sometimes I need a week to find 4.”
That quote wasn’t meant to be profound. I just said it out loud once, and people nodded like I’d confessed something they weren’t allowed to say themselves.
the 1–4–40 reality
Here’s what it actually looks like for a lot of us:
- On some days, you get 1 hour of real output, and spend the rest trapped in inboxes, meetings, or brain fog
- Some days, you hit a rhythm and produce 4 hours of high-value work.
- Once in a blue moon, you get 40 hours of clarity in a single caffeine-fueled sprint and wonder if you’ve unlocked a new dimension
The problem isn’t the variation. The problem is pretending the variation doesn’t exist, and building performance expectations around a model that’s never been true.
It’s not about discipline
It’s easy to assume this inconsistency means you’re undisciplined. That you need better routines. A stricter schedule. A fancier Pomodoro timer. But what if it’s not about discipline? What if knowledge work is simply unpredictable, because focus, creativity, and problem-solving are not linear resources? You don’t summon insight on command. You don’t plan your most productive hour, it sneaks up on you at 6:43 a.m. in the shower or at 9:19 p.m. when you should be unwinding.
I found this cartoon a little too relatable :-)

The Cal Newport effect
One of the best comments I got on this topic was about Deep Work by Cal Newport: “Real productivity doesn’t mean being busy all day. It means doing focused, meaningful work without distractions.” Exactly 🫳🎤⬇️. And how many hours of that do we realistically get in a typical day? Two, maybe three—if we’re lucky, rested, and no one scheduled a team sync at 9:00 a.m.
So how should we think about productivity?
Start with this: value ≠ hours. Your job isn’t to fill time. It’s to deliver outcomes, solve problems, make good decisions, and occasionally do something brilliant. And most of that happens in peaks, not in steady state. So instead of fighting the 1–4–40 reality, try designing around it:
- Guard your deep work hours like gold - I for example have a maximum of 2 hours of meetings per day - rest is real work
- Not every hour will be productive, and that’s okay. There is this thing of productive procrastination where you subconsciously go through all the steps that you aren’t ready for, yet. And when the time comes, you processed it so thoroughly, that you exactly know what to do. And then you spread your wings and fly.
- Measure by impact, clarity, and progress, your clock is not a good way to measure productivity.
Let’s stop pretending
The graph is broken. Our brains don’t work on conveyor belts. And yet, we keep designing work environments, performance metrics, and schedules as if they do.You’re not lazy. You’re not broken. You’re just working in a system that wasn’t built for how people actually think. Maybe it’s time to fix the graph instead of forcing ourselves to fit it.
Published on:
Learn moreWe can help you with The productivity graph is broken and we’re pretending it’s fine
If you want help implementing, troubleshooting, or improving this product, contact us and we’ll point you in the right direction.
Related posts
You are holding GitHub Copilot Wrong!
Most developers think that one can’t really use GitHub Copilot wrong. There is a chat interface that lets you also choose a model, so th...
You are holding GitHub Copilot Wrong!
Part 0 showed why constant prompting, re-prompting, and steering GitHub Copilot feels fragile. Not because Copilot is unreliable, but because ...
Building a Multi-Hierarchy Ticket Classification System (Because Keywords Aren't Enough)
Look, I love a good keyword-based system as much as the next developer. They’re fast, predictable, and when your user says “VPN,&r...
Secretless cross-tenant dataverse access
Client secrets are like hiding your house key under the mat; easy to grab and impossible to audit. Certificates are just slightly better, beca...
How Azure CLI handles your tokens and what you might be ignoring
Running az login feels like magic. A browser pops up, you pick an account, and from then on, everything just works. No more passwords, no more...
How Dev Proxy teaches you to make your apps more resilient
I added Microsoft Dev Proxy to my Mermaid → Dataverse converter, because I wanted to test how it handled rate limits and API errors. What I go...
Building Azure functions that never store secrets — ever
What if your function could hit Microsoft Graph with no client secrets, no certs, and no Key Vault entries? That is exactly what a Managed id...
Introducing Mermaid to Dataverse Converter
Why diagrams matter (and why they usually fail us) Entity-Relationship Diagrams (ERDs) are the universal shorthand for talking about data mode...
It’s OK to be seen trying
It’s OK to be seen trying Somewhere along the way, we started believing that you’re only allowed to speak after you’ve figured everything out....
Stuck in pilot - Part 1: no foundations, no future
“We just need to test the AI. We’ll figure out the data later.” That sentence has quietly killed more AI pilots than any model failure ever ...