Time tracking without surveillance, and what we refuse to build

Every time-tracking product eventually gets the same feature request from the same kind of buyer: show me what my people are doing. The tooling to answer it exists and is not hard to build. We are not going to build it, and it is worth being specific about why, because "we care about privacy" is what everyone says while shipping the opposite.

Why the request keeps coming

It is worth being fair to the person asking. A manager who wants screenshots is usually not a sadist; they are frightened. They have a budget they cannot explain, a remote team they cannot see, and a boss asking a question they cannot answer. Monitoring software promises to convert that anxiety into a dashboard.

It does convert it. It just does not answer the question. What you get is a measure of presence, and presence was never the thing in doubt. What is in doubt is whether the work is going anywhere, which no amount of screen capture can tell you.

So the honest response is not "monitoring is bad". It is that monitoring answers a question nobody actually has, at a price paid by the people you most want to keep.

The list

Screenshots. Periodic captures of a worker's screen. They catch nothing a bad actor cannot avoid and everything a good one would rather keep private: a medical portal left open in another tab, a message from a partner. The cost is carried entirely by honest people.

Idle detection. Keyboard and mouse silence read as not-working. It penalises thinking, reading on paper, and whiteboards, which is to say it penalises the most valuable hours of the week.

Keystroke and click counts. A measure of typing, sold as a measure of work. It rewards volume in a job where the best edit is usually a deletion.

Leaderboards. Ranking colleagues by logged hours. It converts a coordination tool into a competition, and the winner is whoever is worst at estimating when to stop.

What surveillance costs, specifically

The argument against is usually made in terms of trust and dignity, which is true and also easy to wave away as soft. The concrete costs are easier to defend in a budget meeting.

You lose the honest log. The moment a record can be used against someone, it stops describing what happened. People round up, log the meeting they resented as work they are proud of, and stop writing the sentence that would have been useful. You have paid for a data set and received a performance.

You lose the people who have options. Monitoring is a strong negative signal in a job market, and it is strongest for exactly the senior people who could leave tomorrow. The team you keep is the team that cannot go elsewhere.

You inherit the data. Screenshots of employees' screens are a category of personal data with real legal weight in most of Europe, and a breach involving them is not a minor incident. Every image is a liability you chose to create.

You still cannot answer the question. After all of it, "is this project going to land?" remains a question about the work, answered by looking at the work.

What a team can see in Timato

Admins see per-person totals, because someone has to be able to answer whether a project is over budget and who is carrying it. Members see their own hours and the team's totals per project, never a name beside an hour count. Personal labels stay personal in either direction, and personal projects are never visible to the team at all.

If a measurement would change behaviour for the worse when people know about it, it is the wrong measurement.

That asymmetry is deliberate and we do not hide it in a settings page: the member view simply shows what a member can see. There is no mode that turns colleagues into a chart.

What actually reduces duplicated work is not visibility, it is coordination. A claimed task cannot be started by someone else. That one lock has saved more standup minutes than any dashboard we could have built.

What to do instead when you are worried

If a project is drifting and you want to know why, there is a sequence that works and none of it requires watching anybody.

1. Look at the project total against what you expected. Not per person, per project. If it is double, the estimate was wrong or the scope moved, and both are conversations rather than investigations.
2. Read the session goals on that project. The sentences will usually name the problem outright: the same rework appearing four times, an integration nobody scoped, a dependency that keeps going quiet.
3. Ask. Once you have a number and three sentences, the conversation starts from shared facts instead of a suspicion, and people answer it straightforwardly because there is nothing to defend.

That sequence has found every genuine problem we have had. None of them would have shown up in a screenshot, because none of them were caused by someone not being at their desk.

The line we will not move

Features are usually a matter of priority. This one is not. There is no plan to add screenshots, activity scores, idle detection or a ranking of colleagues, at any price, for any customer.

We would rather lose the deal, and we have. Writing it down publicly is partly for our own benefit: a policy you have published is much harder to quietly reverse two years later when a big enough logo asks nicely.

For the person being asked to install it

If you are on the other side of this, where someone has proposed monitoring software and you are expected to accept it, the most useful thing you can do is make the question specific.

Ask what decision the data will inform. Not what it measures, what it will change. Most proposals do not survive the question, because the honest answer is "it will make me feel better about a budget I do not understand", and that is a problem with a different solution.

Ask, too, what happens to the data: who can see it, how long it is kept, and what happens to it when someone leaves. These are reasonable operational questions rather than an accusation, and the answers are frequently "nobody has thought about it", which is itself the argument.