The productivity theater is boring and expensive

Most engineering managers are playing a video game where the high score doesn't matter. They track lines of code, commit frequency, and JIRA velocity. It’s theater. It’s noise.

You know who writes the most code? The junior dev who just pasted a 400-line stack overflow snippet into auth_middleware.go and broke production. He has great stats today. He also just cost the company $50k in downtime.

Productivity isn’t an output metric. It’s a latency metric.

The DORA trap

There is a massive obsession with DORA metrics. While Deployment Frequency and Lead Time for Changes matter, teams use them to hide behind mediocrity. If you deploy 20 times a day but 18 of those are hotfixes for the first 2, you aren't productive. You're just busy.

We talked to a team last week that bragged about their 15-minute CI pipeline. We looked at their repo. They had 400 flaky tests marked with @Ignore because nobody had the time to fix them.

This is the debt that kills teams. You think you're moving fast, but you're actually just dragging a heavy anchor through the mud. Speed is a byproduct of high-quality foundations, not a goal you hit by typing faster.

Stop measuring keystrokes

If you want to know how a team is doing, look at their time-to-first-review on GitHub. If a PR sits for two days, your sprint is dead. It doesn't matter how fast the code was written if it rots in a branch while the context evaporates.

We see this in our data at git11 constantly. The highest-performing teams don't have the highest commit counts. They have the tightest feedback loops.

They have a 'drop everything and review' culture. They don't let main stay broken for more than 10 minutes. They treat their CI config like it's production code, because it is.

The $200,000 CI pipeline

Your CI pipeline is likely your most expensive employee. If a dev earns $150k and spends 30 minutes a day waiting for npm test or go test ./... to finish, you’re burning thousands of dollars per month on staring at progress bars.

I’ve seen teams refuse to buy a $500/month CircleCI runner upgrade while paying five senior engineers to drink coffee while their builds queue. It’s financially illiterate.

If your local make build takes longer than 60 seconds, your devs are checking Twitter. Once they check Twitter, they’re gone for 15 minutes. That’s the real productivity killer. Context switching is the only tax that takes 80% of your income.

Documentation is just code that hasn't run yet

Internal wikis are where knowledge goes to die. If I have to search a Confluence page to find out how to set up docker-compose.yml, you’ve failed.

The setup should be a script. The documentation should be the code.

We spend too much time 'aligning' in meetings. Most meetings should have been an ADR (Architecture Decision Record) in the repo. If it’s not in git, it didn't happen. Decisions made in Zoom calls are ephemeral. They result in 'wait, why did we use DynamoDB for this?' six months later.

AI is not a magic wand

Everyone thinks adding an AI autocomplete tool will make them 10x faster. It won't. It will make you 10x faster at generating boilerplate that you now have to maintain.

If you use AI to write code you don’t understand, you aren't being productive. You're just generating future bugs at a higher velocity.

At git11, we use AI to analyze what’s actually happening in the codebase—finding dead paths, identifying where logic is getting too circular, and spotting where your review process is bottlenecked. The value isn't in writing the code; it's in understanding the mess you already built.

The 'No' list

To actually move the needle, stop doing these things immediately:

1. Stop daily standups that last longer than 10 minutes. If you’re 'updating' people, do it in Slack. Standup is for blockers. 2. Stop using 'Story Points' as a proxy for value. They are an estimation tool, not a performance metric.

1. Stop allowing PRs with more than 400 lines of changes. Nobody actually reviews a 1,000-line diff. They just LGTM and pray. 4. Stop pretending that 'Code Coverage' means your code works. It just means your code ran.

What actually works

Focus on the boring stuff.

Shrink your PR size. We found that PRs under 100 lines get reviewed 4x faster and have 50% fewer bugs. It’s a simple rule: if it’s big, break it up.

Invest in your dev environment. If git clone to hello world takes more than 10 minutes for a new hire, your onboarding is broken. Fix your scripts. Automate your secrets management with something like Doppler or Vault.

Delete code. Deleted code has no bugs. Deleted code requires no maintenance. The most productive day I ever had was deleting 4,000 lines of a service that wasn't being used anymore.

Productivity is about removing friction, not adding pressure. Put your energy into making the 'right way' the 'easy way.' If it’s hard to write tests, people won't write them. If it’s hard to deploy, people will fear it.

Fix the plumbing. The rest takes care of itself.