Where does engineering time actually go?

Where the Attention Went shows one bar per person, segmented by class of work and measured in attention-days — calendar days a task sat in a working state, counting only tasks that moved. It shows where attention was directed, which is a different and more defensible thing than how many hours were worked.

Is this the same as time tracking?

No, and it cannot be converted into it. Tasks overlap — one engineer held eleven in a working state at once on the reference window — so a person’s attention-days across tasks routinely exceed the number of days in the window. It is a share-of-attention proxy, not FTE effort, and the widget states so on its face.

Why is one person’s bar so much shorter than everyone else’s?

Check for the late-joiner marker under their name first. Anyone whose first recorded activity falls inside the window is measured from that date rather than the window start, and the marker names the date. Bar length is also driven by how many tasks someone holds concurrently, so it is not a productivity ranking.

What does the unclassified segment mean?

Attention on work that no classifier could categorise. It is a fact about the pipeline, not about the work, and it has a segment of its own precisely so that a person whose work nobody has classified reports days rather than appearing to have been idle.

Where engineering time goes: attention per person, split by class of work

One bar per person, segmented by what kind of work the attention went to. It is the widget most likely to be misread as a timesheet, so the first thing to establish is what it is not: it measures where attention was directed, not how many hours anyone worked, and the two cannot be converted into each other.

deckgauge · Board · Team Focus

Person	Attention split	Days
Engineer A	roadmap ████████ · opex ███ · internal █	96
Engineer B	roadmap ██ · opex ██████████	88
Engineer C from 2026-05-14	roadmap ████ · internal ██	41
Engineer D	opex ████ · unclassified █████	52

Bars segmented by class, with a late joiner marked.

Calendar days in a working state, moved tasks only. A share-of-attention proxy, not FTE effort.

What it measures, and where the data comes from

An attention-day is one calendar day a task spent in a state this board treats as working, clipped to the reporting window. Days are summed per person per class, from Jira and Azure DevOps transition history, counting only tasks that actually moved in the window.

The classes are A — Roadmap / CAPEX, B — OPEX, C — Internal technical, and Unclassified.

This is not effort, and it cannot be made into effortTasks overlap. On the reference window one engineer held eleven tasks in a working state simultaneously, so his attention-days across tasks far exceeded the days in the window. Any reading that treats a bar as FTE effort, or divides it by the window length to get a utilisation figure, is wrong — which is why the qualifier is printed on the widget itself rather than hidden in a tooltip.

How the number is calculated

Each task's working spells inside the window are measured and summed. A spell runs from the transition into a working state until the next transition, or to the window's end if the task is still sitting there.

One task's attention-days

Date	Transition	Working?	Days accrued
3 Jun	To Do → In Progress	yes	—
12 Jun	In Progress → Blocked	no	9
20 Jun	Blocked → In Review	yes	—
30 Jun	(window ends, still In Review)	yes	10

Window: 1 June – 30 June. Working states: In Progress, In Review.

That task contributes 9 + 10 = 19 attention-days. The eight days it spent Blocked contribute nothing, because Blocked is not a working state on this board.

Those 19 days land in the segment matching the task's class. Repeat across every moved task the person owns, and the bar is the result. Two people each holding one 19-day task and one holding two overlapping 19-day tasks produce bars of 19 and 38 — which is a statement about concurrency, not about effort.

How late joiners are handled

Anyone whose first recorded activity falls inside the window is measured from that date rather than from the window start, and the bar carries the date in text.

The effect is large. On the reference window, the same person and the same 21 days of work read as 38% active days measured from the window start and 75% measured from their actual first activity. The first reads as someone barely present; the second as one of the more consistent contributors.

A start date presented as idleness is the worst error this view can makeSo the correction is applied before any percentage is computed, not offered as a toggle. Note the deliberate limit: no recorded activity at all is not treated as a late joiner. There is nothing to measure, and inferring a start date from silence would be the same mistake in another form.

How to read it

Read the class mix, not the bar length. Length is driven as much by task overlap as by anything else, so ranking people by it produces a concurrency leaderboard dressed up as a productivity one.

Check for late-joiner markers before comparing anyone to anyone. An unmarked comparison against a partial window is the most common wrong read here.

Then look for a person carrying almost entirely one class. Sustained single-class loading is worth a conversation either way: someone permanently on OPEX is absorbing the interrupt load for everyone else, and someone permanently on one roadmap epic is a bus-factor risk.

What it tells you over time

The distribution across people is more stable than any individual bar, so a shift in who carries the OPEX segment is the signal to watch. When it stops rotating and settles on one or two people, that is usually invisible in every other metric and shows up here first.

An unclassified segment growing across windows means classification is degrading — check How Work Was Classified, because every class-based figure on the view weakens with it.

Check the raw data Every number here is reproducible. Add Every Task, and Why — the ledger — to the same board and the same period. It lists every task with its raw state from Jira or Azure DevOps sitting beside the delivery stage it was mapped to, its class, the reason the classifier gave, its owner, its source system and its move count, and it filters by person, class and stage.

For this widget: set the Person filter to one name to see every task behind that bar, with the class and the reason each was given. A class mix that looks wrong is confirmed or corrected there — and with edit rights, a class can be changed in place and the bars follow.

The raw state sits next to the mapped stage deliberately: that is what lets you see how a state was interpreted and argue with it, rather than being handed a stage and asked to trust it. See the ledger reference for the full column list, or Ledger & caveats for the method behind it.

Example situations

1. One person absorbing all the unplanned work

deckgauge · Where the Attention Went

Person	Roadmap	OPEX	Internal
Engineer A	71%	18%	11%
Engineer B	66%	24%	10%
Engineer C	7%	89%	4%
Engineer D	74%	19%	7%

One bar is almost entirely OPEX.

What you're seeing: three engineers are on roadmap work at around 70%. The fourth is at 7% roadmap and 89% OPEX. The team's aggregate roadmap share looks acceptable precisely because one person is absorbing the entire interrupt load, which is invisible in any board-level number.

How to react: this is a fairness and retention problem before it is a metrics problem. The person shielding everyone else from unplanned work is also the person whose ticket counts and delivery figures will look weakest everywhere else on this view.

Managerial playRotate the interrupt load on a named schedule rather than letting it settle by default, because it settles on whoever is most willing to pick it up and that is rarely a deliberate choice. Say plainly to that person that the pattern is visible and not going unnoticed — being permanently on support while peers ship roadmap work is a common reason good engineers leave, and it is usually invisible in performance conversations that only look at delivery. Check their row on Person by Person before any review cycle: it will show few features in production, and that number will be a direct consequence of a role decision rather than of their work.

2. A short bar that is a start date, not a quiet quarter

deckgauge · Where the Attention Went

Person	Attention-days	Measured from
Engineer A	96	window start
Engineer B	88	window start
Engineer C	41	2026-05-14 — first recorded activity

The marker under the name is the whole story.

What you're seeing: Engineer C's bar is less than half the others'. They joined six weeks into a thirteen-week window. Measured over their actual tenure they are tracking in line with the team; measured against the window they look like someone who contributed little.

How to react: the widget has already applied the correction to any rate it computes and has told you the date. The remaining risk is entirely in how a human reads the bar, particularly in a screenshot pasted into a deck where the marker gets cropped.

Managerial playNever circulate this widget as an image without the late-joiner text, and if you are pasting it into a review deck, add the tenure explicitly rather than relying on a reader to spot an 11px note. When comparing a new joiner to the team at all, compare the class mix rather than the totals — mix is tenure-independent, totals are not. And treat the first window as diagnostic of onboarding rather than of the person: a new joiner whose attention is spread across four classes in month one is usually a sign nobody gave them a focused first project.

Frequently asked

Where does engineering time actually go?: Where the Attention Went shows one bar per person, segmented by class of work and measured in attention-days — calendar days a task sat in a working state, counting only tasks that moved. It shows where attention was directed, which is a different and more defensible thing than how many hours were worked.
Is this the same as time tracking?: No, and it cannot be converted into it. Tasks overlap — one engineer held eleven in a working state at once on the reference window — so a person’s attention-days across tasks routinely exceed the number of days in the window. It is a share-of-attention proxy, not FTE effort, and the widget states so on its face.
Why is one person’s bar so much shorter than everyone else’s?: Check for the late-joiner marker under their name first. Anyone whose first recorded activity falls inside the window is measured from that date rather than the window start, and the marker names the date. Bar length is also driven by how many tasks someone holds concurrently, so it is not a productivity ranking.
What does the unclassified segment mean?: Attention on work that no classifier could categorise. It is a fact about the pipeline, not about the work, and it has a segment of its own precisely so that a person whose work nobody has classified reports days rather than appearing to have been idle.

Related widgets

Focus Map — the same attention, as a person × work-area matrix, separating days spent from days merely elapsed.
Person by Person — the same split as a table, with delivery and movement columns beside it.
Roadmap Focus — the same attention-days summed into one board-level share.
Every Task, and Why — the tasks behind one bar.
Method: Attention days and Classifying work.
Back to the widget reference.

Last updated 10 September 2026