What Not to Build

Ruling something out before it exists costs a conversation. Removing it afterwards requires admitting it should not have been built.

Activity percentages

Keystroke and mouse counts presented as a productivity measure.

Why not: they measure input, not work. Reading, thinking and talking all score low; typing badly scores high. And they are trivially gamed, which everyone involved knows.

Instead: nothing. The question they claim to answer is answered by looking at the work.

Screenshots

Why not: no time recording purpose requires them, they capture confidential and personal content indiscriminately, and proportionality fails plainly because a less intrusive method exists.

Instead: a contemporaneous record with a narrative, which is the professional standard and is usually what a client actually wants.

Automatic deduction of idle time

Why not: it removes pay for time that may have been worked, without the person's input, which is a wage-and-hour exposure and a fairness problem at once.

Instead: prompt the person to classify the gap. Keeps the judgement where the knowledge is.

Individual billable or utilisation targets

Why not: they produce the disappearance of supervision, training and business development from the record, and they push recorded totals toward the target rather than toward accuracy.

Instead: team-level planning measures with the investment categories excluded from the calculation.

Ranking people by hours

Why not: the data is not accurate enough to support it, and the comparison measures the work assigned rather than the person.

Instead: effort by project and by work type, which answers the question that was actually being asked.

Silent manager edits

Why not: a record the worker cannot see changed is not a record; it is the employer's assertion.

Instead: every edit visible to the worker, logged, disputable.

Location tracking through the day

Why not: a clock-in location check is proportionate for site-based work; continuous tracking is not, and no payroll question requires it.

Instead: a check at the point of clocking, and nothing between.

Biometric clocking where a badge would do

Why not: biometric data carries heavier obligations, consent in employment is weak, and regulators have repeatedly found it disproportionate where an alternative exists.

Instead: a badge or a code, with supervision addressing the sharing problem.

The design-time test

What decision does this inform? If none, drop it.

Could duration alone inform it? If yes, do that.

Would you explain this feature, in detail, to the people it applies to? If not, that discomfort is the answer.

Apply all three before procurement, because a deployed feature acquires defenders and the conversation gets harder.

Ruling it out at proposal stage

The moment when refusal is still cheap.

A configured feature acquires defenders. Someone has seen it work, it exists, and removing it becomes a loss rather than a decision.

Which means the design-time test belongs before the proof of concept.

Ask the three questions when the idea is described: what decision, could duration alone inform it, would you explain it in detail to the people it applies to.

A week of refusal at proposal stage costs a conversation. The same refusal after a pilot costs a fight.

Recording what was ruled out

The document that answers the same proposal when it returns.

What was proposed.

What was ruled out and the specific reason — legal, technical, or both.

What was built instead.

Who decided, and when.

Findable, so the second identical request is answered by reference rather than argued from scratch.

Reviewed annually, because circumstances change — which is different from being overturned under pressure by someone who did not read it.

Check the difficult case

Use open the workflow reference to frame one representative test for this issue. The useful evidence is not the marketing description itself but the record created when a worker corrects an entry, a manager reviews it and an administrator exports it.