Build vs Buy for Measuring Engineering Productivity Honestly

Deploy frequency and lead time describe how fast and how safely code moves from commit to production across a whole team's system, shaped heavily by tooling, process, and architecture, not any individual's effort or skill. Using DORA metrics to rank individual engineers misapplies a system-level measure to an individual-level question, and it reliably produces the wrong incentives: engineers optimizing for the metric instead of for genuinely useful work.

A common mistake is handing leadership a DORA dashboard with no framing, which invites them to read it as a scoreboard for people. The fix is to state, alongside the numbers, which question they answer (how healthy is the delivery pipeline?) and which they do not (who is productive?). For example, if lead time rises, investigate the pipeline before the people: slow reviews, flaky tests, manual approvals, or a fragile release process are far more likely causes than any one engineer. Framing the metric this way protects the team from misuse and keeps the conversation on things you can actually change.

Lines of code, commit count, and story points closed all correlate weakly with actual value delivered and strongly with gameable behavior: padding commits, splitting work into artificially small tickets, avoiding the hard, slow-to-close problems in favor of easy, fast-to-close ones. Any individual metric that's easy to measure automatically is usually easy to game, and a team that starts optimizing for the number instead of the underlying work will find a way to move it without actually improving anything.

Standard DORA metrics are well covered by existing tooling; building a custom pipeline to recompute deploy frequency and lead time from scratch is rarely worth the maintenance cost. Where building in-house makes more sense is a metric specific to your own product or process that no off-the-shelf tool tracks, time from a specific customer-reported bug to a verified fix, say, where the value comes from the custom definition, not from reinventing a standard metric a platform already handles well.

Tools like ClickUp can automatically compute standard delivery metrics from existing commit and deployment data without a custom pipeline, and a workflow platform like Process Street can enforce and track the process steps, review, testing, deployment checklist, that actually drive change failure rate down, which is a more actionable lever than the failure rate number itself. Teams in the fastest, on-demand deploy cluster recover from failures quickly precisely because those underlying process steps are consistently followed, not because someone is watching a dashboard¹.

A team's DORA numbers can look healthy while morale and code quality are quietly deteriorating, if the metrics are being optimized directly rather than as a side effect of genuinely good practice. Regular, honest qualitative check-ins, what's actually slowing the team down, where technical debt is accumulating, catch problems the quantitative dashboard won't show until they've already become a trend worth worrying about.

Use DORA metrics to assess pipeline and process health at the team or system level, never as an individual performance metric. Build custom measurement only for something genuinely specific to your product that no platform already tracks well. Buy platform support for standard metrics and process enforcement, since that's where an off-the-shelf tool's maintained, battle-tested implementation beats a custom one built and maintained in-house.

Before adopting any engineering metric, run it through these checks:

• Confirm it describes pipeline or team health at the system level, since DORA measures were never designed to rank individual engineers.
• Ask whether it is easy to game; anything simple to compute automatically usually is, and people will optimize the number instead of the work.
• Check whether a platform already computes it from existing commit and deployment data before building a custom pipeline to recompute it.
• Build in-house only when the definition is specific to your product or process, such as time from a customer-reported bug to a verified fix.
• Pair the number with a regular qualitative check-in on what is slowing the team down and where technical debt is piling up.

Say a team starts tracking pull requests merged per week as a productivity signal. Within a month, PR counts rise, but average PR size shrinks sharply and review quality drops, because engineers learned the fastest way to move the number was splitting normal work into smaller, faster-to-approve pieces rather than doing more of it. The metric technically improved. The actual output didn't. That's the pattern worth watching for with any individual metric simple enough to compute automatically: if it's easy to measure, it's usually easy to game.