Developer Productivity

How to Run an Engineering Productivity Audit

Vaibhav Verma

June 2, 2026

11 min read

productivity-auditdeveloper-productivityengineering-leadershipmetricsengineering-efficiencyteam-management

How to Run an Engineering Productivity Audit

Last year, our CEO asked why it took 6 engineers 4 months to build a feature our competitor shipped in 6 weeks with 3 people. I didn't have a good answer. I had excuses: our codebase was more complex, our requirements were different, we had more edge cases. All true. None satisfying.

That question drove me to build a structured approach for auditing engineering productivity. Not the fluffy "are your developers happy?" kind of audit. A systematic examination of where engineering time actually goes, what's blocking throughput, and what specific changes would have the highest impact.

I've now run this audit at three organizations. Every single time, it revealed that 30-45% of engineering time was being consumed by activities that produced zero customer value. Not because engineers were slacking. Because the systems, processes, and tooling around them were broken in ways nobody had quantified.

The Contrarian Take: Productivity Isn't About Working Faster

Most productivity initiatives focus on making engineers work faster: better tools, fewer meetings, more "focus time." That's optimizing the wrong variable. The biggest productivity gains come from eliminating work that shouldn't exist.

In every audit I've run, I find that engineers spend more time on non-value work than actual feature development:

Activity	% of Engineering Time	Value Category
Writing and reviewing code	32%	Direct value
Debugging and incident response	18%	Necessary but reactive
Waiting (CI, reviews, environments)	17%	Pure waste
Meetings and communication	15%	Mixed value
Tooling and environment issues	10%	Pure waste
Rework (bugs, scope changes)	8%	Avoidable waste

That's 35% of engineering time in the "waste" categories. For a team of 20 engineers at $200K average fully loaded cost, that's $1.4M per year spent on waiting, fighting tools, and redoing work.

The Audit Process: 5 Phases

Phase 1: Instrument (Week 1)

You can't improve what you don't measure. Start by collecting data from systems that already exist.

From your version control (Git/GitHub/GitLab):

bash

# PR cycle time distribution
gh pr list --state merged --limit 200 --json number,createdAt,mergedAt,additions,deletions \
  --jq '.[] | {
    pr: .number,
    cycleHours: ((.mergedAt | fromdateiso8601) - (.createdAt | fromdateiso8601)) / 3600,
    size: (.additions + .deletions)
  }' | jq -s 'sort_by(.cycleHours)'

# Review wait time: time between PR creation and first review
gh pr list --state merged --limit 100 --json number,createdAt,reviews \
  --jq '.[] | select(.reviews | length > 0) | {
    pr: .number,
    waitHours: (((.reviews[0].submittedAt | fromdateiso8601) - (.createdAt | fromdateiso8601)) / 3600)
  }'

From your CI/CD system:

bash

# Average CI pipeline duration
gh run list --limit 50 --json databaseId,startedAt,updatedAt,conclusion \
  --jq '.[] | select(.conclusion == "success") | {
    durationMinutes: ((.updatedAt | fromdateiso8601) - (.startedAt | fromdateiso8601)) / 60
  }' | jq -s '{avgMinutes: (map(.durationMinutes) | add / length)}'

From your incident tracker:

Count incidents per month, mean time to resolution, and which components caused them. This data usually lives in PagerDuty, Opsgenie, or a spreadsheet.

Phase 2: Survey (Week 1, parallel with Phase 1)

Automated data tells you what is happening. Surveys tell you why. I use a focused 10-question survey, rated 1-5:

"I can get my development environment working within 30 minutes of a fresh setup"
"Our CI pipeline rarely blocks me from shipping"
"I can get a code review within 4 hours of opening a PR"
"Our test suite gives me confidence that my changes work"
"I rarely have to redo work because of changing requirements"
"I spend most of my day writing code, not fighting tooling"
"I can find and understand existing code when I need to"
"Deployments are boring and predictable"
"I know what I should be working on and why it matters"
"Our on-call rotation is manageable and doesn't burn people out"

Any question averaging below 3.0 is a red flag. Below 2.0 is a productivity emergency.

Phase 3: Shadow (Week 2)

This is the most uncomfortable and most valuable phase. Shadow 3-5 engineers for a full day each. Don't ask them to report their time. Sit next to them (or watch their screen share) and log what they do.

typescript

// Time tracking categories for shadowing
interface TimeBlock {
  engineer: string;
  startTime: string;
  endTime: string;
  activity:
    | 'coding'
    | 'code_review'
    | 'debugging'
    | 'waiting_ci'
    | 'waiting_review'
    | 'environment_issues'
    | 'meeting'
    | 'communication'
    | 'context_switching'
    | 'requirements_clarification'
    | 'incident_response';
  notes: string;
}

I've never done a shadow session that didn't reveal something the automated data missed. In one session, I watched an engineer spend 45 minutes trying to reproduce a bug locally because the staging environment didn't match production. That doesn't show up in any dashboard.

Phase 4: Analyze (Week 3)

Cross-reference all three data sources to identify the top productivity drains. I rank them using an impact formula:

Impact Score = (Engineers Affected) x (Hours Lost Per Week) x (Ease of Fix, 1-5)

Example findings from a real audit:

Issue	Engineers Affected	Hours/Week	Ease of Fix	Impact Score
CI takes 28 minutes average	18	3.2	4	230
Code review wait > 8 hours	18	4.5	3	243
Dev environment setup takes 2 days	4 (new hires/quarter)	16	5	320
Flaky tests cause false failures	18	2.1	3	113
No staging for integration testing	12	5.0	2	120

The dev environment setup scored highest because while it affects fewer people, the hours lost are massive and the fix (containerized dev setup) is well-understood.

Deliver findings as a prioritized list with expected ROI for each fix. I limit recommendations to 5 items. More than that and nothing gets done.

markdown

## Engineering Productivity Audit - Recommendations

### 1. Containerize development environment
- **Impact:** Save 32 engineer-days per year on setup
- **Cost:** 2 weeks of platform engineering time
- **ROI:** 8x in first year
- **Metric to track:** Time from "laptop received" to "first PR merged"

### 2. Implement review SLA with automated assignment
- **Impact:** Reduce cycle time by 40%
- **Cost:** 3 days to set up, ongoing process change
- **ROI:** 4.5 hours/week/engineer recovered
- **Metric to track:** P50 and P90 time to first review

### 3. Parallelize CI pipeline
- **Impact:** Reduce CI time from 28 to 9 minutes
- **Cost:** 1 week of DevOps engineering
- **ROI:** 57 engineer-hours/month recovered
- **Metric to track:** P50 CI duration

The Stealable Framework: The AUDIT Cadence

Run this on a cycle:

A - Assess quarterly. Full data collection from git, CI, and incident systems. 1 day of effort once you've built the scripts.

U - Understand through surveys. Same 10 questions every quarter. Track trends. A question that drops from 3.5 to 2.8 is an early warning.

D - Deep-dive semi-annually. Full shadow sessions and cross-referencing. This is the expensive part. Do it twice a year.

I - Implement the top 3. Not top 5. Not top 10. Three items per quarter. Finish them completely before taking on more.

T - Track relentlessly. Every recommendation gets a metric. Review metrics monthly. If a fix didn't move the metric, understand why.

The hardest part of the audit isn't collecting data or making recommendations. It's getting leadership to prioritize productivity improvements over feature work. Frame it in dollars: "This audit identified $1.4M in annual waste. Each recommendation has an ROI above 4x. The first three items pay for themselves in one quarter."

I've never seen a leadership team say no to those numbers. The key is having the data to back them up, and that's exactly what this audit gives you.