The timesheet wasn't lying. It was blind

adithyaharish1 pts1 comments

The timesheet wasn't lying. It was blind. — Meridian

← All writing

For the past year we've been building a tool that watches what you do on your machine — every window, every terminal, every doc — and tries to write your Jira updates for you. This is not a pitch for it. It's about the thing we found while building it, which turned out to be more interesting than the product.

The premise was simple: nobody remembers what they did yesterday. Standups are improv. Worklogs are historical fiction written minutes before the sprint review. So we assumed the problem we were solving was accuracy — people attributing time to the wrong ticket, padding, misremembering. We built accordingly: a classifier that matched real activity to tickets, tuned obsessively against false positives, with an abstain gate so it would rather say nothing than guess.

Then we ran it against a full week of real work and compared its output to what actually got logged by hand. We were hunting for the mismatches — hours logged to the wrong place.

There weren't any, really. What people logged was almost always correct. That was the first surprise.

§ 01The second surprise was the hole.

Roughly 45 hours of genuine work that week appeared in no ticket, no worklog, no standup. Not misattributed — absent. The failure mode of human work-tracking isn't precision. It's recall. Nobody lies on their timesheet. They just silently drop a third of their week, and neither they nor anyone else ever notices, because you can't notice an absence.

And the dropped work had a shape. It wasn't slacking. It was the debugging session that turned out to be an infra problem and therefore belonged to no ticket. The hour unblocking a teammate. Two dead-end approaches tried before the one that worked. The reading you do before you're allowed to have opinions about a system. All real. All load-bearing. All deleted — because at the end of the day your brain runs a quiet triage: does this map to something with a name? If not, it's discarded, and it doesn't feel like forgetting. It feels like nothing happened.

§ 02Why estimates never get better.

Once you see it, you see it everywhere, and it explains something everyone complains about: why estimates never get better. Every estimate leans on history — formally in tooling, informally in "how long did this take last time?" And that history is systematically missing the expensive parts. The false starts and yak-shaving never got written down, so the record says the last feature took four days when it took seven. Then we're shocked when the next one takes seven. The dataset isn't noisy; it's censored, and censored data is worse than noise because it's confidently wrong in one consistent direction.

It warps credit, too. The work that survives into the record is the work that had a ticket waiting for it. The person grinding through ambiguous, unticketed problems — often your most senior engineer, doing the org's most valuable work — produces the least evidence of having worked. We built our recording systems structurally biased against exactly the labor we claim to value most.

§ 03It invalidated our own architecture.

The humbling part for us: this invalidated our own architecture. We'd built a careful matcher — activity in, ticket out — and the data said matching was never the bottleneck. A system like this has to capture work before deciding where it belongs, and be willing to conclude "this was real, and there is no ticket for it." That verdict — hours of legitimate work with no home on the board — turned out to be the single most useful thing it could say. We'd been treating it as a classification failure. It was the finding.

§ 04You can't fix this with discipline.

You also can't fix this with discipline, which is everyone's first instinct. "Just log more diligently" fails because the deletion happens before the moment of logging. You can't faithfully record what your brain has already classified as nothing. The gap isn't between what people did and what they wrote down. It's between what they did and what they remember doing — and no process fixes that from the writing-down side.

So now I read every burndown chart and every "where did the quarter go" retro with one specific suspicion: the story isn't wrong. It's incomplete, in a consistent direction, and the missing hours sit precisely in the categories that would explain why everything takes longer than planned.

The lie in the timesheet was never the interesting part.

The interesting part is the work that, as far as any record shows, never happened at all.

👋

Let's be friends

We're a lot more fun over here than in a changelog. Pick your platform:

gh

GitHub

star us — we WILL notice 👀

𝕏

X / Twitter

hot takes & release memes

dc

Discord

come yell at us live, it's fun

ig

Instagram

mostly aesthetic timeline screenshots

in

LinkedIn

the professional one, we promise

no spam, just diamonds in your feed ✦

theme

work ticket never before timesheet wrong

Related Articles