Surveillance-Free Timesheets: Track Hours Without Spyware

There are two reliable ways to make a team hate time tracking, and most companies find at least one. The first is surveillance: screenshot software and an "activity score" that docks people for reading documentation. The second is archaeology: nobody logs anything for six weeks, then an email asks everyone to reconstruct their hours by Friday. The first produces resignations. The second produces fiction. Both produce garbage data.

The fixes are structural, not motivational. A timesheet people tolerate rests on three design decisions: expected hours that come from each person's actual schedule, a short honest window for corrections, and logging that costs seconds. None of them involve watching anyone.

First, be honest about why you're tracking

There are three good reasons to collect hours from a product team:

• Finance evidence. R&D capitalization and tax relief claims rest on contemporaneous, per-person, per-project hours. We covered the money side in the capex/opex post; the record is worth real money, but only if it exists before someone asks.
• Client billing. If you invoice by the hour, the timesheet is the invoice's source of truth.
• Capacity truth. Knowing that a third of engineering went to unplanned maintenance is the difference between arguing about the roadmap and fixing the actual constraint.

If none of these apply to a team, don't make that team log time. In SquadBear, time tracking is a module an admin can turn off entirely, and off is a legitimate setting.

Expected hours come from the schedule, not a flat 8

Most tools assume everyone owes 8 hours, Monday through Friday. Real teams have part-timers, four-day weeks, short Fridays, and public holidays.

Aleksandra at Northlake works Monday to Thursday. Her week grid expects 0 hours on Friday, not 8 with a standing explanation owed to her manager. Public holidays expect 0, and when her Wednesday leave request is approved, Wednesday's expectation drops too. A schedule can even carry per-weekday hours, so a team that runs 6-hour Fridays sees 6 expected that day and 8 the rest of the week.

The precision matters because of the delta. When "expected" is accurate, "you've logged 12 of 32 hours this week" is a useful nudge to fill the grid before memory fades. When it's a flat 40 applied to a part-timer, the same number is an accusation she has to keep disproving. The delta is a prompt, never a verdict.

The editing window: short, honest, audited

Hours data is only worth something while it's contemporaneous: auditors trust records made close to the work, and a timesheet backfilled weeks later from memory falls apart under examination.

But "no edits, ever" is also wrong, because real mistakes exist: hours on the wrong work item, a day logged twice, a forgotten afternoon. The workable compromise is a rolling window: recent entries stay editable, older ones lock, and corrections stay cheap while memory is still trustworthy.

Northlake sets its window to 7 days. On Monday, Aleksandra notices that last Tuesday's 8 hours landed on the wrong work item. That's 6 days back, inside the window, so she opens her month view, deletes the wrong entry, and logs the 8 hours where they belong. Had she noticed two days later, the cell would render locked and the API would refuse the same write, and she'd ask Marta, an admin, to make the fix.

Admin overrides are the pressure valve, and every one of them is audited, including an admin correcting their own past entry. A backdated fix is always possible and always leaves a trace.

Logging has to cost seconds

Whatever a timesheet costs in minutes per day, multiply it by headcount and 220 working days before deciding it's fine.

A week grid should arrive pre-filled with the week's shape: every work item from projects you're on, at 0 hours, so Monday opens with what you're expected to work on. Logging is typing 7.5 into a cell and hitting Enter. A predictable week is one click of "copy last week." And hours should attach to the work's real name: search the Jira, GitHub, Linear or Asana issue you were already in, pick it, and the hours land against it. The first log creates the work item, later logs from anyone accumulate on it, and nothing is ever written back to the tracker.

Or skip the grid and tell your assistant:

"Log 6 hours yesterday on Platform v2 against PLAT-142, and show me what my week still expects."

What to never do

Screenshot capture, keystroke counting, idle detection, activity scores. The category sells because it answers a real anxiety, but the data it produces is close to worthless. People adapt within days: the mouse learns to wiggle, the browser learns to look busy, and from then on you measure how well each person performs being watched. Meanwhile the people with the most options update their CVs, because a screenshot every ten minutes tells them what the company believes about them.

If the timesheets feel untrustworthy enough that monitoring is tempting, treat that as a verdict on the timesheet design. Wrong expected hours, a lock that forbids honest corrections, or logging that eats fifteen minutes a day all produce bad data; monitoring just sits on top of them, plus resentment.

Where this lives in SquadBear

Everything above is the design of SquadBear's time module.

• Time tracking → My week is the seeded grid: every work item from your projects at 0h, plain text cells that take decimals and save on Enter, and a Copy last week that skips anything already filled.
• Time tracking → My month is the calendar view, logged vs. expected per day with holidays and leave tinted; click a day to edit or delete its entries.
• Time tracking → Team timesheets gives managers a week grid across their people, with a CSV export of logged, expected, leave and delta hours per person. Admins see the whole workspace.
• Workspace settings → Time tracking sets the correction window: empty means no limit, 0 locks everything before today. Past the cutoff, employee edits are blocked in the UI and rejected by the API; admin fixes always work and are always audited. People can submit a week or a month; managers approve or send it back from Inbox. Admins can close time through a date when payroll needs the books still.
• Workspace settings → Issue trackers connects Jira, GitHub, Linear or Asana so hours attach to real issues. Nothing is pushed back to the tracker.

There is no monitoring surface to configure, because none exists. The only data in the system is what someone typed or told an agent, and a correction is one sentence:

"Move last Tuesday's 8 hours from Bug triage to Platform v2."

Try it on a real week

Start free and set the editing window before you invite the team, or ask the demo to walk through a sample week grid right now.

Related reading: CapEx vs. OpEx for engineering time on what the hours are worth to finance, and burnout tracking without the Big Brother on reading team signals without surveilling the people producing them.