Time tracking
Engineers
Engineering time is fragmented across a dozen contexts a day, and somebody in finance needs it split between what is capitalised and what is not. For another implementation reference, see the Monitask overview.
Two audiences who want opposite thingsThe actual problem
Engineering wants to record nothing and get on with it. Finance needs the hours split between what is capitalised and what is expensed, because the accounting treatment of software development depends on which phase work belongs to, and a claim for research relief depends on records nobody kept.
That tension is the whole of this page. It is not solved by persuading engineers that timesheets are interesting.
Why engineering time is hard to capture
Three properties
Fragmentation. A day contains a dozen contexts: the feature, the incident, the review, the question from support, the meeting. Reconstructing that on Friday produces fiction.
Ambiguity. Debugging a feature while building it is both phases at once, and the split is a judgement rather than a fact.
Legitimate resistance. Engineers have generally seen time data used to compare people, and the objection is to that use rather than to recording.
What works
- Capture attached to the work already being tracked: the ticket, the branch, the issue.
- Four seconds to log, at the moment of switching.
- A weekly confirmation rather than a weekly reconstruction.
- Categories that map to the accounting split, decided once with finance, so that nobody makes the judgement weekly.
The last is the one that saves the most argument. Agreeing in advance which kinds of work are capitalised removes a monthly negotiation between two functions that dislike having it.
What the team seesDisclosure
Their own records, their own weekly totals, and the category split. No comparison between individuals, anywhere in the product.
Every record is visible to the engineer it belongs to and can be corrected by them.
There is no per-person leaderboard, no activity score and no ranking, because those are the features that make engineering teams defeat time tracking rather than use it.
The accounting caveat
Which costs may be capitalised, over what period, and what records support a research relief claim are questions of accounting standards and tax law in your jurisdiction, and they differ.
This page describes why the records are needed. It does not tell you what your treatment should be, and nothing here is accounting or tax advice. Agree the categories with your own accountant before configuring anything.
Estimates are not the same thing
Recorded time and estimated time answer different questions, and comparing them per person is the fastest way to make estimates useless. Estimates inflate, which is rational, and the organisation concludes the team slowed down.
Compare them at team level, over quarters, to improve forecasting. Never at individual level, for any purpose.
Incidents and interruption
The most valuable thing engineering time data produces is usually not the capitalisation split. It is the visible proportion of the week going to interruption: incidents, support escalations, questions that could have been documentation.
That number is normally believed to be small and is normally not. Having it makes the case for the work that reduces it, which is the work that never gets prioritised because nothing measures it.
What to ask any supplier in this market
- Does the product rank individuals in any view?
- Does it record activity as well as time?
- Can the engineer see and correct everything?
- Does it integrate with what the team already uses, or does it ask them to open something else?
The first is the one that decides adoption. A product with a leaderboard will be defeated by the team within a quarter, and the data it produces afterwards will be worse than nothing because somebody will believe it.
The conversation with the team
Have it before deploying anything, and have it honestly. What is recorded, what it is for, who sees it, and what it will not be used for.
The unstated fear is always the same: that this will be used to compare people or to justify a decision about somebody. If it will not be, say so specifically, and then make the product incapable of it rather than relying on a promise.
Engineers see their own records and their own totals.
There is no view anywhere in the product that ranks or compares individuals, which is a design decision rather than a configuration one and cannot be switched on.
What finance actually needs
Less than engineering fears. Usually a split of hours between agreed categories, per period, at team or project level, with enough documentation to explain the basis if asked.
Not per-person detail, not activity, not a comparison. Agreeing that scope with finance at the start removes most of the objection, because the objection is generally to a use nobody was actually proposing.
Retrospective entry, and its limits
Nobody records everything as it happens. A day reconstructed the same afternoon is roughly right; a week reconstructed on Friday is roughly wrong, and the error is not random: it flattens toward whatever the person believes they should have been doing.
Which is why the design target is the same day rather than perfect capture, and why a weekly confirmation is a confirmation rather than an entry point.
Contractors and the same records
Engineering teams run on contractors, and their hours matter to both the capitalisation split and the invoice. Bringing them into the same categories is worth more than any internal report.
It also raises a question for your own advisers: how much control an engager exercises over the manner of work can bear on employment status, and mandating how time is recorded is a form of control. Nothing here is advice on that.
Where to start
Agree the categories with finance before anybody records anything. Two conversations and a table, and it removes the monthly judgement that otherwise falls on an engineer who did not want to make it.
One more thing worth measuring
Time spent waiting: on a review, on an environment, on a decision. It is invisible in every other system and it is frequently the largest single category of lost engineering capacity.
Recording it costs nothing extra and it produces the argument for fixing the thing causing the wait, which is otherwise nobody's priority because nothing counts it.