Developer Productivity at 100+ Engineers: What Actually Matters
Progress metrics that survive 100+ engineers
- Treat time to first PR as an onboarding health score and make day-one merges normal.
- Use median time to merge to expose review, policy, and CI drag instead of policing commit counts.
- Track PR composition so you know when you are building the future versus paying for the past.
- Leaders must stay close to the codebase to interpret these signals in context.
Most dashboards lean heavily on commits, points, or PR totals. These motion metrics are useful signals, but they only capture how active the team is, not whether the system is actually healthy.
Watch Tony's session
In the video What actually matters for developer productivity at 100+ engineers scale, Tony Dong shares the three signals he trusts after running teams from startups to public companies.
Runtime: 12 minutes · Recorded October 2025
The signals that matter at 100+ engineers
Time to first PR
This metric is a proxy for onboarding quality. When a new engineer can merge even a tiny fix on day one, you know environment setup, docs, access, and the review playbook are tight.
Tony keeps a backlog of low-stakes issues and automates setup scripts so new hires experience the full CI and deploy cycle immediately.
Median time to merge
Median time to merge exposes how efficiently code moves through review and CI. Layer AI review to create a strong baseline, clarify ownership, and ruthlessly trim bottlenecks that keep PRs waiting.
At Twitter, Tony used a multi-tier CI system to run only critical tests per PR, then batched the full suite later. At Rippling he enforced minimum viable tests so no suite ran longer than ten minutes.
PR composition
Tag each PR as a feature, fix, or refactor so you can see whether energy powers roadmap goals or maintenance. When bug fix ratios spike, you know debt or instability needs attention.
Once you have a few weeks of data, the signal becomes obvious and you can redirect teams, advocate for resources, or automate fixes.
Why progress metrics matter more than motion metrics
Pros
- Expose onboarding, review, and delivery friction so teams can fix it early.
- Highlight where platform investments in CI, docs, or automation will remove real bottlenecks.
- Show whether engineering energy drives roadmap progress instead of being consumed by break/fix cycles.
- Connect directly to developer confidence, predictability, and customer outcomes.
Cons
- Motion metrics like commits or velocity rise even when throughput doesn't improve.
- Lines changed reward noisy diffs and penalize thoughtful refactors, obscuring true impact.
- PR totals hide how long work sits in queues or why it stalls.
- High-level activity counts miss the hidden taxes that appear once teams scale past 100 engineers.
Time to first PR: treat onboarding like a product
Tony was told to merge something on his very first day in his post-college startup role, not because the change was valuable, but because it forced him through the entire toolchain. That fast loop built confidence and surfaced friction instantly.
It built confidence fast because I now understood how everything fit together.
- Automate setup. Containerize environments, ship setup scripts, and pre-approve access so laptops are ready within hours.
- Curate day-one tickets. Keep a queue of doc edits, small fixes, or config tweaks so new hires experience the full edit-test-review-merge loop immediately.
- Clarify ownership. Document who reviews which surfaces and where coding standards live to remove guesswork.
- Instrument the metric. Track the hours between badge activation and first merge, then review it alongside onboarding surveys every week.
Median time to merge: compress the review and CI loop
Once onboarding is healthy, the biggest productivity tax is how long code waits for review or CI. Tony layers AI reviewers so every pull request starts from a strong baseline and keeps humans focused on nuance rather than nitpicks.
Optimizing CI really was about optimizing learning. The faster your system taught your engineers what was broken, the faster they can build things.
- Layer AI system review. Use automated reviewers to flag policy violations, architectural drifts, and flaky patterns before humans even open the diff.
- Shorten review queues. Standardize severity labels and routing so PRs never stall while people debate ownership.
- Adopt multi-tier CI. Follow the Twitter pattern by running only the subset of tests that matter for a single PR, then run the exhaustive suite once changes land on main.
- Enforce minimum viable tests. Borrow Rippling's rule that no test suite can exceed ten minutes to discourage bloated pipelines.
PR composition: balance feature work and maintenance
When Tony joined Rippling, the team spent most cycles fixing bugs without realizing it. Tagging every PR as a feature, fix, or refactor rewired the conversation and bent the incoming support curve even as usage grew.
- Tag every PR. Require authors to label their change as feature, fix, or refactor so analytics stay current.
- Act on spikes. When the bug-fix ratio jumps, dig into the root causes, not just the symptom list.
- Set composition goals. Define target ratios for each team per quarter so you can allocate time intentionally.
- Automate classification. Use tools like Propel Code that read titles, diffs, and linked issues to categorize work in real time.
Run Tony's productivity audit
Capture the baseline
Pull the last 30 days of onboarding, merge, and composition data so debates start from facts.
Eliminate the biggest onboarding blocker
Fix the longest setup wait time, whether it is access approvals, container builds, or missing docs.
Compress review cycles
Add AI reviewers, enforce severity labels, and trim CI to only the tests that teach engineers fastest.
Inspect PR mix weekly
Tag PRs, highlight ratio drift in planning meetings, and dedicate time to bend the support curve.
Stay hands-on
Leaders keep a local checkout, scan architecture docs, and drop into design reviews so the metrics never lose context.
The leadership habit that ties it all together
Metrics only matter when leaders stay close enough to the code to interpret them. Tony keeps the repo cloned locally, skims design docs, and joins reviews even when he is not writing features. That context sharpens prioritization and makes feedback land.
- Clone the primary repos locally and keep them building so you can spot drift firsthand.
- Skim key architecture docs and design reviews weekly, even as an observer, to maintain intuition about dependencies.
- Pair with teams on critical launches just long enough to understand their workflows and unblock them.
It is not about writing code. It is about keeping context.
"Fast onboarding builds confidence. Fast merges keep the flow. Balanced composition keeps progress compounding."
Frequently Asked Questions
Automate productivity insights with Propel
Propel Code keeps standards in your repo, auto-classifies pull requests, and highlights where review or CI debt is slowing 100+ engineer teams.
