How to Measure Deep Work Without Screenshots — 5 Outcome Signals (2026)

Why screenshot-based deep-work measurement misses

Screenshot-based deep work measurement reads the screen, not the work — which means it punishes the half of engineering work that runs without a keyboard. A senior engineer reading a 40-page design doc. A staff engineer walking the office whiteboard to think through a queue-depth problem. A tech lead pairing on a call. All three are doing the highest-leverage deep work the team produces, and all three look idle to the screenshot dashboard.

The category mistake sits at the framing layer. A screenshot answers the question "what is on this person's screen right now". A deep-work signal needs to answer a different question — "is this person currently in a sustained block of uninterrupted thinking on a real work artefact". The first question is about the device. The second is about the work. The two are not the same question, and confusing them is how engineering teams end up with the surveillance dashboards their best engineers quietly route around.

The fix is not to drop measurement. It is to move it one layer up — from the endpoint to the work-system event stream. That stream lives in the project tracker, the version control system, the calendar, and the async-messaging tool the team is already running. Read those four sources together and the five outcome signals below fall out, and the screenshot question stops mattering.

Signal 1 — Focus density

Focus density is the share of the working hours a person spends in uninterrupted blocks longer than 60 minutes. The signal reads from three sources at once — the calendar (no meeting block), the async-messaging focus or do-not-disturb state, and the application-focus event log on whichever editor or IDE the person is working in. None of those sources require screen-content capture.

Show the signal as a delta against the person's own rolling four-week baseline. Not as a gap against a fixed organisation-wide target. A senior engineer who runs at 70 per cent focus density and slides to 50 per cent is showing capacity strain — the absolute number still looks fine but the delta does not. A junior engineer who runs at 40 per cent baseline and creeps up to 55 per cent is on a healthy track, even though the absolute number sits below the senior. Same metric, different baselines, both readable.

Signal 2 — Commit-to-pull-request rate

Commit-to-pull-request rate is the rolling 14-day count of pull requests opened divided by the count of commits pushed to feature branches. The healthy band for product engineering usually sits between 0.10 and 0.25, but the band is team-specific — calibrate to the team's own work pattern before reading the signal.

Two directions of drift matter. A ratio that falls below the baseline says work is accumulating in personal branches but not being opened for review — usually because the work is too large to review, or because the engineer is uncertain and hiding the work. A ratio that spikes above the baseline says small unfinished pull requests are being opened to look busy. Neither direction is read from screenshots; both are read from the version-control event log the team already keeps.

Signal 3 — Ticket-close-to-touch ratio

Ticket-close-to-touch ratio is the average count of project-tracker touches required to move a ticket from open to closed. A ticket that closes in three touches — picked up, worked, closed — sits at a healthy ratio. A ticket that touches the tracker 18 times before closing is signalling something: an underspecified ticket, an unresolved dependency, the wrong owner, or work that should have been broken into smaller tickets to begin with.

Read this signal at the team level, not the individual level. Closing-touch counts attribute to upstream and downstream dependencies, not just the engineer holding the ticket — a ticket that bounces twelve times because the design system team needs to ship a primitive first is not the ticket-owner's signal. Most engineering managers find the ticket-close-to-touch ratio is the first signal that surfaces a process problem the team had been treating as an individual performance problem.

Signal 4 — Switching cost

Switching cost is the count of application or workspace switches inside the working day, weighted by the cognitive distance between them. Two switches between an IDE and a terminal carry low cost — same mental context, same work artefact. A switch from an IDE to a video call to a spreadsheet to a long email and back to the IDE carries high cost — four context loads in one cycle, three minutes minimum to recover the working memory each time.

The signal reads from application-focus event logs only — the operating system already produces these events for window management. No screen content. No input data. A rising switching-cost trend on a person who used to baseline at low switching is the earliest leading indicator we have seen for capacity strain, usually two to three weeks ahead of the focus-density signal moving. The reason is mechanical — the cognitive load of switching shows up in behaviour before the engineer notices the deep-work blocks shrinking.

Signal 5 — Meeting encroachment

Meeting encroachment is the share of the working window claimed by meetings that should have been async — read directly from calendar metadata, not meeting content. The signal is the only one of the five that reads at the team level first and the individual level second, because the meeting load is a property of the team's coordination culture more than the individual's working pattern.

A team that runs at 35 per cent meeting encroachment is leaking deep-work capacity to coordination overhead. A team that runs at 55 per cent has lost the ability to ship anything that needs uninterrupted thinking, full stop. The reading depends on calendar metadata — start time, end time, attendee count, whether the meeting has an agenda — and pairs cleanly with the focus-density signal. The two move in inverse together. A team that closes meeting encroachment by ten points usually opens focus density by six to eight.

The five signals in one view

Calibrate to your team — don't import the numbers

The healthy bands above are starting points, not constants. A platform-engineering team that runs deep multi-week refactors will baseline higher on focus density and lower on commit-to-pull-request rate than a product team shipping daily. A staff-engineer cohort will baseline higher on switching cost than a junior cohort because they are pulled into more cross-team coordination. Take a four-week reading on every signal before treating any number as a target. The signal is the delta against the team's own baseline, not the absolute number.

The deeper question of how to replace surveillance-era productivity measurement with outcome-signal measurement is covered in the anti-surveillance productivity stack. The full five-signal worksheet — focus depth, commit cadence, meeting load, flow-state, blocker recovery — sits in the 5-signal self-audit worksheet on the resources page; it pairs with the deep-work signals above and runs in 30 minutes. For teams operating across the EU, the EU AI Act vendor scorecard walks the proportionality test for the broader productivity stack feeding the signals.

What an engineering manager actually does with these five signals

The five signals do not run themselves into a single composite score, and any vendor that suggests otherwise is selling a leaderboard, not a deep-work signal. Each signal answers a specific coaching question:

• Focus density falling against baseline — open the conversation about what is fragmenting the engineer's day. Usually a meeting load shift, sometimes an unblocking task that should have been delegated, occasionally early capacity strain.
• Commit-to-pull-request rate drifting low — the work in flight is not getting reviewed. Pair-program the next pull request, or break the work into smaller increments.
• Ticket-close-to-touch ratio elevated on a team — the upstream specification or downstream dependency is breaking the team's flow. The fix is rarely on the engineer holding the ticket.
• Switching cost rising — the engineer is being pulled across too many contexts. Look at meeting calendar, on-call rotation, and Slack channel membership for the source.
• Meeting encroachment over 45 per cent — the team is no longer a deep-work team. The fix is structural, owned by the manager, not the individual.

None of the five signals capture screen content. None capture keystroke data. None require a new agent on the engineer's endpoint. The audit trail teams think they get from screenshot-based dashboards already lives in the project tracker and version-control system the engineering team uses every day — the screenshot was producing a noisier copy of the same signal at a much higher data footprint.

FAQ