5 Reports Every Engineering Manager Should Run Weekly
Five engineering manager reports to run weekly—by tester, day, repository, PR, and label—so you spot bottlenecks early and lead with data instead of vibes.
Managing engineering on gut feel works right up until it doesn’t—usually the week a deadline slips and nobody saw it coming. The right engineering manager reports, run on a weekly cadence, replace that surprise with a steady read on where time goes and where work piles up. These five reports take minutes to pull and give you the signal to coach, rebalance, and plan before problems compound.
Why weekly, and why these five
A weekly rhythm is short enough to catch a trend before it becomes a fire, and long enough to smooth out daily noise. The five reports below each answer a different question—who, when, where, what, and which kind of work—and together they form a near-complete picture of your team’s delivery health. Pull them, scan for outliers, and act on what stands out.
1. Report by tester: balance the load
The question: is work distributed fairly, or is one person carrying the team? A by-tester report shows how testing time is spread across people for the week. Watch for two patterns—someone consistently over capacity (a burnout risk and a bus-factor problem) and someone idle (a sign of unclear assignment or a blocker you missed). Use it to rebalance for next week, not to rank individuals.
- Spot overload before it becomes attrition.
- Surface uneven assignment early.
- Open a coaching conversation grounded in data, not impressions.
2. Report by day: see the rhythm and the spikes
The question: when does work actually happen, and where are the gaps? A by-day breakdown reveals your team’s weekly rhythm—the steady days, the dead zones, and the crunch spikes. A consistent Friday cliff or a Monday that’s all meetings tells you something structural. Flat, predictable days are healthy; jagged ones usually mean interruptions or unplanned work eating the schedule.
3. Report by repository: find the time sinks
The question: which part of the codebase consumes disproportionate effort? Aggregating time by repository shows where your team’s hours actually land. A repo that eats far more time than its strategic value suggests is a candidate for investment—better tests, refactoring, or documentation—or a sign of accumulating technical debt. This report turns a vague “that service is always painful” into a number you can act on.
4. Report by pull request: catch the stuck ones
The question: which PRs are quietly stalling? A by-PR report surfaces where time is concentrated and which pull requests have absorbed far more effort than expected. A PR with mounting hours and no resolution is usually blocked, under-scoped, or fighting a hidden problem—exactly the thing a manager should unblock before it drags into next sprint. Use this to intervene while intervention still helps.
5. Report by label: read the work mix
The question: what kind of work is your team really doing? Because workflow states map to labels, a by-label report shows how time splits across categories—how much sat in ready_for_testing, how long things spent in_progress, how often work came back failed. A high failed-rework share points at upstream quality problems; a long ready_for_testing queue points at a testing bottleneck. This is the report that connects effort to process health.
Turning reports into action
Reports only matter if they change what you do. Build a fifteen-minute Monday habit: pull all five, look only for outliers, and leave with at most three actions—rebalance a load, unblock a PR, schedule a debt conversation. Resist the urge to act on every wiggle; weekly data has noise, and chasing it erodes trust. Watch trends across a few weeks before making structural calls.
The other half of the discipline is making the reports trustworthy. They’re only as good as the underlying time data, which means your team needs a low-friction way to track working time—start/stop timers that don’t interrupt flow, tied to the actual PR, repository, and label being worked. When tracking is effortless, the reports are honest. When it’s a chore, the data quietly rots and you’re back to vibes.
A useful framing: the by-tester and by-day reports are about people and rhythm, the by-repository and by-PR reports are about where effort concentrates, and the by-label report is about process health. Reading them in that order—people, hotspots, process—gives you a coherent narrative for your weekly one-on-ones and planning, instead of five disconnected charts.
One more habit separates managers who use reports well from those who drown in them: write down what you expected before you open the data. If you predicted a balanced load and the by-tester report shows one person at double everyone else, that gap is the most valuable signal you’ll get all week—it tells you your mental model of the team is wrong, and corrects it cheaply. Reports that merely confirm what you already believed are pleasant but low-value; the ones that surprise you are where the management leverage lives. Over a few weeks this turns your weekly review from a status ritual into a calibration loop, sharpening your instincts so that even between reports you read the team more accurately.
Key takeaways
Five reports—by tester, by day, by repository, by pull request, and by label—give an engineering manager a complete weekly read on load, rhythm, hotspots, stuck work, and process health. Run them on a fixed cadence, hunt for outliers, and leave each review with a small number of concrete actions. The point isn’t dashboards; it’s catching problems while they’re still small.
If you want these reports without building a reporting pipeline yourself, KazTrack tracks working time against real PRs, repositories, and labels and slices it by tester, day, repository, PR, and label out of the box—so your Monday review starts with answers, not a spreadsheet.