The tension every engineering lead is sitting in
If you run a remote team in 2026, you have probably felt both sides of this. Your CFO asks what the Cursor and Claude Code licences are returning. Your CEO asks why the roadmap slipped. And you, privately, are not sure what half the team did last sprint, because the work happens in editors and agent sessions you cannot see, and standup answers are three sentences of summary.
Quick Answer
Developer productivity tracking without surveillance means tracking the work, not the person. You measure what shipped (commits, PRs, issues), where effort went (session metadata: durations, repos, languages), and what your AI spend returned. You do not capture screenshots, keystrokes, file contents, or webcam frames. The work-level data answers every question a lead legitimately has. The person-level data answers questions you should not be asking, and it costs you the trust that makes a team worth leading. Below: why the tension exists, the reframe that resolves it, exactly what visibility you need and what crosses the line, and a rollout pattern that will not blow up in your first retro.
So you go looking at the tooling market, and the loudest category is employee monitoring: screenshot capture every few minutes, keystroke counts, idle-time detection, webcam check-ins. The pitch is that visibility requires watching people. Post a screenshot-tool rollout announcement in Slack and watch your best people update their CVs.
The tension is real because both instincts are correct. You do need to know what is shipping. And your engineers are right that surveillance is corrosive. Good engineers read a screenshot tool as a statement: we do not trust you. They respond the way trustworthy people always respond to distrust, by leaving or by performing. Neither one ships more software.
Track the work, not the person
Visibility and intrusion are not the same dial, though most leads frame them that way and pick a point on the line.
Surveillance tools watch the person and infer the work. Screenshots, keystroke rates, and active-window logs are attempts to reconstruct "was this human labouring" from behavioural evidence. Work-level tracking does the opposite. It watches the output and the sessions that produced it: what merged, which repos got effort, how long the sessions ran, what the agents did, what the tokens cost. One approach measures presence. The other measures production.
The AI era settles the argument. When Claude Code or a Codex agent writes a large share of the diff, "was the human typing" stops meaning anything. An engineer can be at their keyboard eight hours and ship nothing. Another can direct three agent runs from a phone and merge the feature that saves the quarter. Keystroke counts rank the first engineer above the second. Before it is even a privacy problem, that is a measurement problem: surveillance tools measure an input that no longer predicts output.
There is a second reason the work is the right layer. Standup updates and sprint reports are claims. "Nearly done" and "spent the week on the migration" are self-reported, and self-reports drift under pressure, which is why manual timesheets lie so reliably. A record of sessions and shipped output is evidence. When you track the work, you get an answer you do not have to take anyone's word for, which surveillance never delivers.
What visibility a lead legitimately needs
Run the test from the other direction. For each question you want answered, ask whether it is about the work or about the person. In two years of building tracking tooling and talking to engineering managers about it, every defensible need I have heard reduces to four things.
What shipped. Commits, merged PRs, closed issues, per project and per week. This is the ground truth your roadmap conversations should run on, and it is the visibility engineering productivity metrics exist to provide.
Where effort went. Which repos and projects consumed the team's hours, from session durations, not from anyone's memory on Friday afternoon. This is how you catch the project that quietly ate 40 percent of the sprint, and the context switching that shreds focused time before anyone complains.
AI leverage. Which agents ran, what the tokens cost, and what shipped as a result. You are paying for these tools; output per unit of effort is the number that says whether they are working. No monitoring tool captures this at all.
Blockers, early. A repo where sessions pile up while merges flatline is a stuck engineer or a stuck review queue. Seeing that on Tuesday instead of at the retro is the most valuable thing team-level data does.
Notice what the list does not contain: when people started, how long lunch ran, what was on the screen, whether the mouse moved. In practice, no roadmap or budget decision has ever needed those.
| Question | Work-level answer | Surveillance answer |
|---|---|---|
| Is the roadmap on track? | Shipped output per project over time | Cannot answer it |
| Is the AI spend worth it? | Agent runs, token cost, resulting output | Cannot answer it |
| Is someone blocked? | Sessions rising while merges stall | Idle-time alerts, wrong signal |
| Is the team working? | The shipped record answers this implicitly | Screenshots, keystrokes, presence |
What crosses the line
If you have ever inherited a monitoring tool from a previous manager, you have seen what these do to a team's behaviour. The line is not fuzzy. These four cross it, every time.
Screenshots and screen recording. They capture personal messages, medical tabs, and passwords alongside code. There is no aggregation that fixes this; the capture itself is the violation.
Keystroke and input logging. Measures typing, which AI-era output no longer correlates with, at the price of logging everything typed. Worst trade in the category.
Idle-time shaming. Auto-flagging "inactive" minutes treats thinking, whiteboarding, and reading as theft. It often produces mouse-jiggler culture within a month: engineers optimising for the metric instead of the work.
Individual leaderboards used punitively. Ranking engineers by commits or hours and letting the rank drive performance conversations. Almost always this gets gamed within a quarter, and it punishes exactly the senior people whose output is unblocking everyone else.
There is one more line, and it runs through my own product too. Any tool that shows individual-level data at all is a trade-off. Aggregated views leak less, but a lead who can see per-person sessions holds real power over the people generating them, and a per-person work record can be misused by a bad manager even when it contains no screenshots. The difference between visibility and surveillance is partly what you capture, and partly who controls it and what it is used for. Say that to your team in plain words before you roll anything out. Pretending the trade-off does not exist is how trust dies on contact.
Rolling out developer productivity tracking without surveillance
Tracking rollouts fail on sequencing more than tooling: data appears above engineers before it appears in front of them, and from then on it reads as management's tool. The pattern below rests on one rule. The team meets their own data before you do.
- Say why, in writing, before any install. One paragraph: the questions you need answered (roadmap, AI spend, blockers) and the uses that are off the table (performance ranking, hour policing). You will be held to this document, and that is the point.
- Individuals first, private by default. Everyone runs the tracker for two or three weeks seeing only their own data. Engineers usually find it useful for themselves fast; their own leverage numbers and where their remote hours actually go are interesting long before any manager looks.
- Aggregate before you individuate. The first team view is totals and trends: output per project, AI leverage, effort distribution. Per-person data stays owned by the person.
- The team can see what you see. Whatever dashboard the lead has, the team has. Symmetric visibility is the structural difference between a mirror and a one-way window.
- Review the deal at 60 days. Ask what felt useful and what felt watched, and cut what felt watched. A tracking setup the team would not vote to keep is surveillance with better manners.
Where DevClocked fits
Full disclosure: I build DevClocked, and it is built on the work-not-person line this article draws. Capture is metadata only: session durations, repo names, languages, agent runs, token costs. No screenshots, no keystroke logging, no file contents, by architecture rather than by policy toggle. Developers own their individual profiles, and the team workspace aggregates on top: what shipped, where effort went, and leverage benchmarking across projects, with AI-vs-human attribution that answers the licence-spend question directly. It fits teams of roughly 2 to 50 that live in AI agents and want ground truth instead of roll-ups.
Even this is wrong in one case. A low-trust organisation will weaponise any metric. If your managers currently use output data to rank and punish, metadata-only capture just hands them cleaner ammunition. The fix there is management, not tooling, and no tracker should be installed until the trust problem is dealt with.
Related Guides
- Engineering team time tracking: the parent guide to tracking a whole team's hours and output.
- Time tracking for remote developers: the individual-level view your engineers will use first.
- Manual timesheets are lying to you: why self-reported hours drift, and what replaces them.
- Engineering productivity metrics that matter: which numbers deserve a place in your team view.
- The hidden cost of context switching: the effort leak that team-level session data makes visible.
