Ops Heads, Founders, and Engineering Managers running 25-300 employee Indian IT and services shops. If you have ever asked "is this person working 12 hours productively or 4?" and your current instrument cannot answer, this audit is for you.
A 30-minute self-audit on your current team using five behaviour signals. No new tooling required to start — you can do the first pass with calendar exports, IDE history, and a clean spreadsheet.
Clock-in/clock-out fails. It records presence, not value. The five signals here are what separates a productivity intelligence rollout from an attendance system — they replace timesheets for appraisal-grade decisions.
A per-employee scorecard (0-100), a team-level rollup, and a Red/Amber/Green decision matrix for what conversation to have next — environmental, individual coaching, or status-quo.
The first signal. How many uninterrupted blocks of real work does each engineer get per day — and how long are they? Focus depth is the strongest single correlate of shipped value in small-team studies.
The count of uninterrupted focus blocks longer than 45 minutes per day, per employee. Note: this is a count of blocks, not the total focus minutes. A 6-hour day of fragmented 20-minute slots scores zero on this signal even though the calendar shows six "focused" hours.
Look at app foreground time on the primary work surface (IDE, design tool, doc editor, terminal). A "context switch" is foreground time on a non-primary app exceeding 30-60 seconds. Anything under that threshold counts as a glance, not a break. A focus block ends when a switch over the threshold occurs; the block "counts" if its uninterrupted duration is > 45 minutes.
| # | Engineer | Day | Focus blocks >45min | Total focus minutes | Score 0-100 |
|---|---|---|---|---|---|
| 1 | Mon | ||||
| 2 | Tue | ||||
| 3 | Wed | ||||
| 4 | Thu | ||||
| 5 | Fri | ||||
| 6 | Mon | ||||
| 7 | Tue | ||||
| 8 | Wed |
If the team's median sits at <3 blocks/day across five working days, this is structurally a meeting-load problem, not a motivation problem. The intervention is calendar redesign (no-meeting blocks, async standups), not a one-on-one about effort. Read the result before scheduling the conversation.
A rhythm signal, not a volume signal. Healthy engineering teams have low day-to-day variance in when commits land. Panic-Friday-commits — the spike that appears when a whole week's work compresses into the last two hours of the workweek — is the failure mode you are looking for.
Standard deviation of commit times across the working week, per engineer. Low std-dev = healthy rhythm (commits land throughout the week). High std-dev with a Friday-late cluster = panic mode, often masking a blocker conversation that did not happen on Monday.
| # | Engineer | Total commits (week) | Days with ≥1 commit | Friday-late % of commits | Score 0-100 |
|---|---|---|---|---|---|
| 1 | |||||
| 2 | |||||
| 3 | |||||
| 4 |
Benchmarks: Healthy = commits on ≥4 of 5 days, Friday-late < 25%. Watch = commits on 3 days. Panic = commits on ≤2 days OR Friday-late > 50%.
Signal 03 · All rolesThe most fixable signal on this list. Meeting load is rarely about importance and almost always about default-yes calendaring. The audit asks: how many hours per day is each employee in calendar-blocked time, and how many distinct meetings did that compress into?
Percentage of working day in calendar-blocked time + count of distinct meetings per day. Use the employee's own calendar export (Google/Outlook) for the past 7 days. Count each meeting once, even if recurring.
| # | Employee | Total meeting hours (7d) | Avg meetings/day | Hours/day in meetings | Score 0-100 |
|---|---|---|---|---|---|
| 1 | |||||
| 2 | |||||
| 3 | |||||
| 4 |
A stricter cousin of Signal 1. Where focus depth counts blocks longer than 45 minutes, flow-state counts the rarer, deeper sessions — single-app, single-purpose, ≥ 90 minutes uninterrupted. These are the sessions where the hard work happens.
Total minutes per week in blocks of ≥ 90 minutes uninterrupted in a single primary application. A 110-minute IDE block counts. A 95-minute block split by a 30-second Slack glance counts (under the context-switch threshold). A 95-minute block split by 4 minutes on email does not count.
| # | Employee | Flow blocks ≥90min | Total flow minutes | Avg block length | Score 0-100 |
|---|---|---|---|---|---|
| 1 | |||||
| 2 | |||||
| 3 | |||||
| 4 |
Benchmarks: Healthy = ≥ 5 blocks/week, ≥ 600 minutes total. Watch = 3-4 blocks/week. Red = ≤ 2 blocks/week.
Signal 05 · All rolesThe hardest signal to fake. When an engineer hits a blocker — failing test, broken environment, ambiguous spec — how long does it take them to either resolve it or escalate it and resume focus? Long recovery times almost never indicate skill gaps; they indicate environmental dysfunction.
Median interval from "blocker detected" to "focus resumed", in minutes. A blocker is detected when there is an abrupt context-switch followed by > 10 minutes of off-primary-app activity. Focus is resumed when the primary work surface returns to foreground for > 15 minutes uninterrupted.
| # | Employee | Blocker events (7d) | Median recovery (min) | Longest recovery (min) | Score 0-100 |
|---|---|---|---|---|---|
| 1 | |||||
| 2 | |||||
| 3 | |||||
| 4 |
Combine the five signals into a per-employee score (0-100, 20 points each), then roll up to a team-level median and spread. The scorecard's job is not to rank individuals — it is to surface where the next conversation should go.
| # | Employee | S1 Focus | S2 Commit | S3 Meeting | S4 Flow | S5 Blocker | Total /100 | Tier |
|---|---|---|---|---|---|---|---|---|
| 1 | /20 | /20 | /20 | /20 | /20 | |||
| 2 | /20 | /20 | /20 | /20 | /20 | |||
| 3 | /20 | /20 | /20 | /20 | /20 | |||
| 4 | /20 | /20 | /20 | /20 | /20 | |||
| 5 | /20 | /20 | /20 | /20 | /20 |
≥ 75
Healthy work shape. No structural action required for this person.
50 - 74
Investigate meeting load or unblock conversation first. Coaching second.
< 50
Almost always structural / environmental. Coaching is the last lever, not the first.
| If team median is … | And spread is … | Action this week |
|---|---|---|
| Green (≥ 75) | Tight (range ≤ 15) | Status quo. Re-audit in 60 days. |
| Green (≥ 75) | Wide (range > 25) | Individual coaching conversation with low-end outliers. Look for blocker-recovery patterns. |
| Amber (50-74) | Tight or wide | Environmental audit first. Calendar redesign + blocker-resolution loop. Re-audit after 30 days. Do not coach individuals yet. |
| Red (< 50) | Any | System-level problem. Treat this as an operating-model intervention, not a performance one. Bring in HR + Ops + Eng leadership before the next sprint. |
One important note. The scorecard is composite — it averages five fundamentally different signals. An individual with a 70 driven by 20+20+20+5+5 is in a different situation from one with a 70 driven by 14+14+14+14+14. Always read the signal breakdown before the total.
The audit you just completed is a one-week snapshot. Sustained measurement is a four-week rollout. Below is the order it should happen in — particularly the non-negotiable on Week 3 self-view.
If the audit surfaced something you would like another set of eyes on — the calibration, the team-rollup conversation, or the four-week rollout — book a free 15-minute walkthrough.
Companion Google Sheets calculator for the five signals will be sent in the follow-up email — it auto-computes per-employee scores from the worksheet inputs above.
Disclaimer. This worksheet is operational, not legal or HR advice. The benchmark thresholds reflect composite small-IT customer deployments across 25-300 employee Indian services shops in 2025-2026; calibrate to your team's role mix before treating any single number as a decision boundary. No real customer names or proprietary data are reproduced here — all examples are composite. For employment, monitoring, or appraisal-related policy questions, consult counsel familiar with your jurisdiction.