Status Droid how long software work actually takes

What to Track, and How Finely

Most time tracking fails for the same reason: it asks for more than anyone will supply, so people fill it in on Friday from memory, and memory is the thing that is broken.

The fix is to record less, at the moment it happens, in fields that require no judgement. Teams evaluating employee monitoring software should decide in advance which signals are necessary, who can see them, and how those signals will be interpreted.

The five fields

Per task. Not per hour, not per subtask.

Start and stop timestamps. Actual clock times, not durations you calculate. A duration you type is a duration you estimated.

Task category. One of three: mostly generation, mostly integration, mostly verification. Chosen when you start, and — importantly — corrected when you finish if it turned out to be something else. That correction is itself data.

Assisted or not. A flag. Whether you used an assistant meaningfully on this task. GitLab publishes engineering and DevOps material that complements this measurement discussion See GitLab Blog.

Estimate, recorded before you start. The single field with the highest return, because it lets you compute your own calibration rather than reading someone else's.

Rework flag. Whether this task existed because something earlier was wrong. This is the field that catches the cost that would otherwise be invisible.

Five fields, roughly fifteen seconds a task. That is the entire system.

Why not finer

The instinct is to break work down further — time per subtask, time spent prompting versus reviewing versus typing.

Three reasons not to.

Nobody sustains it. Tracking that costs more than about fifteen seconds per task gets abandoned within a fortnight, and inconsistent data is worse than none because you will trust it anyway.

Switching cost. Fine-grained tracking requires stopping to categorise, which interrupts the work you are measuring and changes the number.

You do not need it. The decisions you will actually make — how to estimate, what to bill, which work to hand to an assistant — are all answerable at task granularity.

METR labelled 143 hours of screen recordings to get second-level resolution. That is what genuine fine-grained measurement costs, and it is a research budget, not a workflow.

What to skip

Lines of code, commits, pull request counts. Output volume was a weak proxy before and is now actively misleading — assisted developers commit three to four times more while introducing security findings ten times more. Any metric that rewards volume now rewards the wrong thing.

Story points. A relative measure anchored on a shared sense of size, and that anchor moved differently for each person.

Utilisation. Percentage of the day billable measures how busy people were, which is not what anyone wanted to know.

Anything a dashboard offers because it can compute it. The available metrics are the easy ones, which is not the same as the useful ones. (Cycle time and lead time are worth keeping, with corrections.)

The one thing worth adding later

Once the five fields are habitual, one more earns its place.

Confidence at estimate time, on a three-point scale: sure, roughly, guessing.

It costs two seconds and it tells you something no other field does — whether your misses come from bad estimating or from work you correctly flagged as unknowable. Those need different fixes: the first is calibration, the second is ranges and re-estimation.

How long before it is useful

Fifteen tasks gives you a rough shape: which categories run over, whether assisted tasks differ.

Two months gives you usable ratios per category — enough to estimate from your own data instead of anyone's average, provided you read it without fooling yourself.

Six months lets you see whether anything changed, which matters because the tooling keeps moving and your ratios have a shelf life.

Do not analyse before fifteen. The variance in software tasks is large enough that four data points will tell you a confident and wrong story.

The failure to watch for

Tracking that becomes performance. The moment the data is used to judge people, it stops describing reality — everyone rounds toward the number that makes them look reasonable, and you are back to recall with extra steps.

Which means for a small team the safest arrangement is that the data is for estimating and pricing, not for evaluating individuals, and that this is said explicitly rather than assumed. If you cannot promise that, you will get pleasant numbers and no information.

The short version