Engineering productivity metrics are useful only when they help a team make a better decision. The moment they become a shortcut for judging individual engineers, they often stop measuring progress and start rewarding performative work.

That is the central tension raised in a recent r/SaaS discussion: commit totals, pull request counts, lines changed, tickets closed, and hours online may describe activity, but they are weak evidence of whether engineering is making the product, platform, or customer experience better. The original post argues for a simpler test: attach every metric to a named decision. If no decision changes when the number moves, the dashboard may be reporting theater rather than management information. (reddit.com)

For founders, engineering leaders, and operators, this is not an abstract argument about dashboards. It affects hiring, performance reviews, release practices, incident response, AI-tool adoption, and whether high-performing engineers stay on the team. A metric can surface a bottleneck worth investigating. It cannot, by itself, explain why the bottleneck exists or identify who deserves credit or blame.

The line between useful visibility and surveillance

There is nothing inherently wrong with measuring work. Teams need visibility into delivery, operational reliability, customer impact, and internal friction. A startup that cannot see how long important changes take to reach production, how often releases fail, or where incidents consume attention is operating from anecdotes.

The failure begins when measurement changes its purpose. Useful visibility asks whether the system enables good work. Surveillance asks whether an individual appears busy enough. Those are fundamentally different management questions, even if both pull data from Git, an issue tracker, CI, observability tools, or calendars.

The r/SaaS post frames this distinction as activity versus engineering effectiveness. That is a practical starting point:

Activity metrics record observable events: commits, comments, pull requests opened, story points completed, tickets moved, messages sent, or hours connected.
System metrics show the behavior of the work system: delivery time, recovery time, release quality, build latency, review latency, or recurring operational toil.
Outcome metrics show whether the work mattered: activation, retention, conversion, support-contact rate, infrastructure cost, security risk reduction, or a customer-facing reliability target.

Activity data has diagnostic value. A sharp fall in merged pull requests may point to a blocked build pipeline, an overloaded reviewer, a difficult release, a major migration, or simply a week spent resolving a severe incident. It becomes misleading when the organization treats the same decline as proof that a particular engineer was unproductive.

That difference matters because software development is collaborative and non-linear. A developer who removes 2,000 lines of obsolete code, unblocks a migration, improves a deployment pipeline, mentors a new teammate, prevents an incident, or clarifies a flawed product requirement may create more durable value than someone who produces a stream of small visible changes. None of those contributions map neatly to an individual commit leaderboard.

Why individual activity metrics are so easy to game

Every target changes behavior. When a number is presented as a personal score, people naturally optimize for the measurement method, especially when compensation, promotion, layoffs, or manager approval seem connected to it.

Consider a few familiar examples. A pull-request target can encourage engineers to slice straightforward changes into unnecessarily tiny submissions, while a lines-of-code target can favor adding code over simplifying it. A tickets-closed target can steer a team toward easy tasks, leaving thorny reliability work, discovery, documentation, accessibility, or architectural cleanup behind.

The issue is not that engineers are uniquely prone to gaming. It is that the metric has created an incentive to maximize an observable proxy rather than the result the organization actually wants. The proxy becomes especially fragile when it ignores task difficulty, risk, collaboration, and the value of saying no to unnecessary work.

What gets distorted when volume becomes a score

Individual activity targets can create second-order effects that are more damaging than the dashboard suggests:

Code fragmentation: Engineers may split work primarily to increase review or commit volume rather than to improve deployability and comprehension.
Shallow review: Reviewers can rush comments or approvals to preserve a low turnaround time, even when a risky change needs careful scrutiny.
Local optimization: Teams choose quick wins over foundational work because foundational work produces fewer visible completions in the short term.
Invisible work penalty: Incident coordination, product discovery, mentoring, design, documentation, security review, and cross-team alignment are systematically undervalued.
Reduced candor: Engineers become less likely to surface uncertainty, rework a poor design, or pause a release if those actions look bad in a throughput metric.
Misplaced management attention: Leaders debate who produced the most artifacts instead of fixing the constraints slowing the entire organization.

This is why a number can be accurate and still harmful. A commit counter may accurately report commits. It does not establish that more commits equals more customer value, better engineering judgment, or a healthier delivery system.

Engineering productivity metrics need a decision owner

The strongest idea in the original r/SaaS post is not simply “do not rank engineers.” It is the operating rule behind it: every metric should have a named decision attached.

That rule forces a dashboard author to answer four questions before adding a chart:

What decision will this metric inform?
Who is responsible for making that decision?
What threshold, trend, or comparison would trigger action?
What qualitative context must be reviewed before acting?

If those questions do not have clear answers, the metric is probably collecting attention without producing learning. It may look sophisticated in a leadership review while adding no operational leverage.

A practical metric contract

Use a short metric contract for every measure that reaches a leadership or team dashboard:

Field	What to define
Decision	The specific choice the data should improve
Scope	Team, service, workflow, or product area being measured
Unit of analysis	A value stream, deployment, incident, or customer journey — not an individual by default
Definition	Exact start and stop points, exclusions, and data source
Expected signal	What a worsening or improvement may indicate
Counter-metrics	What could be harmed if the team optimizes this number alone
Review cadence	Weekly operational review, monthly improvement review, or quarterly planning
Owner	The person accountable for investigating and proposing an action

For example, a team might track median pull-request pickup time. The decision is not “which reviewer is slow?” The decision might be “should we rotate review coverage, reduce work in progress, improve ownership boundaries, or protect focus time?” A companion measure such as post-release defects prevents the team from treating faster review as automatically better.

A metric contract also makes it easier to retire stale charts. If the original decision has disappeared — perhaps the team replaced its CI system, reorganized ownership, or completed a migration — the metric may no longer deserve dashboard space.

DORA metrics are team performance signals, not employee grades

The most widely cited software-delivery measures are DORA metrics: deployment frequency, change lead time, change failure rate, and failed-deployment recovery time. Google Cloud describes the first two as throughput measures and the latter two as stability measures. (cloud.google.com)

They are useful because they move the conversation closer to the delivery system. Instead of asking who typed the most code, a team can ask how rapidly safe changes reach users and how reliably it responds when something goes wrong.

The four measures and the decisions they can support

Metric	What it measures	A useful decision it can inform	A common misuse
Deployment frequency	How often successful production deployments occur	Whether release processes and batch size are creating avoidable delay	Rewarding teams merely for shipping more often
Change lead time	Time from commit to production	Whether work is waiting in review, testing, approval, or release queues	Assuming every long change represents poor execution
Change failure rate	Share of changes that cause a production failure requiring remediation	Whether test strategy, release safeguards, or change design need improvement	Hiding or reclassifying failures to protect a score
Failed-deployment recovery time	Time to recover from a failed deployment or service disruption	Whether rollback, observability, ownership, and incident practices are effective	Treating every incident as comparable regardless of severity

DORA does not solve the interpretation problem by itself. A higher deployment frequency can be good if the team has reduced batch size and improved release safety. It can be meaningless if a pipeline deploys configuration churn or tiny low-risk changes. A long lead time can reveal excessive approval layers, but it can also reflect a prudent rollout of a payment migration, a security remediation, or a high-risk data change.

The point is to use the metrics as prompts for investigation. Teams should segment them by service criticality, change type, and risk where possible, then discuss the work behind the trend. Google’s current deployment guidance still recommends aligning business and technical teams around DORA’s delivery measures, which reinforces their value as cross-functional system signals rather than individual output scores. (docs.cloud.google.com)

Use a balanced scorecard, not one metric that matters

Software engineering is too multi-dimensional for a single productivity number. The SPACE framework — Satisfaction and well-being, Performance, Activity, Communication and collaboration, and Efficiency and flow — was developed specifically to counter the myth that developer productivity can be captured by one simplistic metric. Its authors recommend using multiple measures across dimensions, with at least three dimensions represented. (queue.acm.org)

That does not mean every team needs a 40-chart dashboard. It means a team should deliberately hold important dimensions in tension. Faster delivery is not a win if reliability degrades. Higher output is not a win if burnout rises. Better local flow is not a win if coordination failures cause product work to miss the market.

A lean scorecard for a SaaS engineering team

For many small and mid-sized product organizations, a useful starting scorecard might include six to eight measures:

Flow: Median and 85th-percentile time from work started to customer availability, segmented by work type.
Quality: Customer-impacting defects introduced by changes, plus escaped-defect trends for key workflows.
Reliability: Change failure rate, recovery time, and error-budget or service-level-objective performance for critical services.
Developer friction: Build duration and reliability, local setup time, CI queue time, or a lightweight quarterly developer survey.
Collaboration: Review pickup time, review rework rate, and the number of handoffs required for a typical change.
Product impact: A metric linked to the initiative, such as checkout completion, activation, support tickets per active account, or retained usage.
Capacity health: Interrupt load, on-call pages, operational toil, and planned versus unplanned work.

The mix should change with the company’s strategy. A pre-product-market-fit startup may weigh experiment turnaround and customer-learning loops more heavily. A mature B2B platform handling critical workflows may emphasize reliability, security, recovery, and predictable delivery. A platform team should measure whether internal users can successfully and easily complete developer tasks, not just how many platform tickets it closes.

Context is not an excuse; it is the missing data

Leaders sometimes hear “metrics need context” as a request to avoid accountability. It should mean the opposite: accountable interpretation requires enough information to distinguish a real delivery problem from a number that is behaving normally for the work.

Take cycle time. If a team’s cycle time climbs from five days to 20 days, that absolutely merits attention. But the next question is not “who slowed down?” It is “what changed in the system?”

Possible explanations include:

The team is performing a complex database or infrastructure migration.
A shared dependency or external vendor is blocking delivery.
The work was poorly shaped and grew beyond its original scope.
Review capacity is constrained by incidents or competing priorities.
The test suite has become slow, flaky, or expensive to run.
Releases are bundled into a manual approval window.
The team is intentionally using progressive delivery and longer observation periods for a risky feature.

Each explanation implies a different response. The metric tells the team where to look; it cannot provide a verdict without the work narrative.

This principle also applies to lower activity. A small change volume may mean that a team is stuck. It may also mean the team deleted complexity, consolidated services, addressed technical debt, or avoided a low-value feature. A reduction in production incidents could reflect genuine reliability improvement, reduced traffic, fewer releases, under-reporting, or a narrower incident definition. Good measurement makes these possibilities visible rather than pretending they do not exist.

Measure the constraints that engineers can actually improve

The most actionable engineering metrics often sit at friction points: long builds, flaky tests, slow environments, unclear ownership, brittle release paths, unreliable local setup, excessive handoffs, and repetitive support work. These are systems problems that management can fund and teams can improve.

Research from Google has emphasized the human and sociotechnical nature of developer productivity, while studies of developer experience focus attention on factors such as feedback loops, cognitive load, and the ability to complete work without unnecessary friction. (research.google)

That distinction is operationally important. “Increase individual developer output” is vague and invites activity surveillance. “Cut CI feedback time for the primary service,” “reduce flaky-test retries,” “make staging environments self-serve,” or “eliminate the top three sources of on-call toil” gives a team a concrete improvement target.

Good metric questions for an engineering review

Instead of asking, “Why did this engineer close fewer tickets?” try questions such as:

Where is work spending most of its elapsed time: shaping, implementation, review, testing, approvals, or release?
Which failure modes are creating the largest amount of recovery work?
What percentage of on-call or support load is recurring and preventable?
Which developer journey has the highest friction: local setup, test execution, deployment, observability, or access provisioning?
What types of changes regularly exceed the expected delivery time, and why?
Which product bets have generated measurable customer impact after release?
What improvement would free the most engineering attention next quarter?

These questions produce a healthier type of accountability. They make leaders responsible for removing organizational constraints, while engineers remain responsible for technical judgment, delivery discipline, and transparent learning.

AI makes activity metrics even less reliable

AI-assisted coding raises the stakes of this debate. When an assistant can generate boilerplate, tests, refactors, documentation, or multiple implementation options quickly, raw artifact volume becomes even further detached from value. More code may reflect an AI-generated first draft, not a better design or a more meaningful result.

Current research and practitioner discussion increasingly point to the same conclusion: AI’s impact should not be measured only through speed. A 2026 ACM Queue article examining AI through the SPACE framework reports that developers often perceive benefits in routine work and efficiency, but those benefits vary by task complexity, individual usage, and team-level support; satisfaction and collaboration still matter. (queue.acm.org)

For leaders evaluating AI coding tools, better questions include:

Did lead time improve for a defined class of changes without an increase in failure or rework?
Did developers spend less time on repetitive tasks and more on customer problems, design, quality, or reliability?
Did review burden rise because generated changes were larger, less familiar, or harder to verify?
Did build, test, security, or production-defect signals change after adoption?
Do engineers report that the tool reduces friction, or does it introduce more context switching and verification work?

This is another reason not to individualize dashboard metrics. If one engineer uses AI to write a large amount of code while another prevents a severe production issue by questioning an AI-generated change, a code-volume ranking will misread both contributions.

A safer process for turning metrics into improvement work

A metric program succeeds less because of the specific chart and more because of the review behavior around it. Teams need a repeatable way to move from signal to diagnosis, experiment, and learning.

The decision-first review loop

Choose a business or engineering objective. For example: reduce failed checkout releases, shorten the path for small product experiments, or lower on-call interruptions.
Select one primary system metric and one or two counter-metrics. If the primary measure is lead time, pair it with a quality or reliability signal so speed does not become the only goal.
Set definitions before reading the dashboard. Agree on what counts as a production deployment, a failure, a recovery, a work item, and an excluded outlier.
Review trends at the team or service level. Look for sustained patterns, segments, and changes in distribution rather than reacting to a single weekly movement.
Add qualitative evidence. Ask engineers, incident responders, product managers, and support teams what changed in the work system.
Form a testable hypothesis. Example: “Most delay for small changes occurs in CI queueing, so parallelizing integration tests should reduce the 85th-percentile lead time.”
Run an improvement experiment. Give it an owner, a time horizon, and a specific expected effect.
Review the result and document learning. Keep, adjust, or stop the intervention. Retire metrics that no longer lead to decisions.

The process prevents two common extremes: dashboard nihilism, where teams reject all data because some metrics are bad, and metric absolutism, where leaders treat a graph as a complete explanation.

How to use metrics in performance management without creating fear

Performance management cannot be avoided, but engineering-system telemetry should be a small and carefully interpreted input — not an automatic ranking engine. Promotion and performance decisions require evidence of scope, judgment, collaboration, technical leadership, customer impact, reliability ownership, learning, and sustained contribution over time.

An individual can influence delivery outcomes, but rarely controls them alone. Team topology, roadmap volatility, inherited architecture, incident load, reviewer availability, product ambiguity, staff turnover, and platform quality can all alter output. Measuring someone against raw activity data strips out the conditions under which they worked.

A healthier approach separates two conversations:

System improvement reviews examine aggregate delivery, reliability, quality, and developer-experience data to identify constraints.
Individual growth reviews use calibrated, narrative evidence from goals, project outcomes, peers, managers, and self-reflection — with attention to the context and difficulty of the work.

This separation creates psychological safety. Engineers can report incidents, rework, slips, and quality concerns without fearing that the same information will be mechanically converted into a personal score. It also makes the organization more likely to discover genuine problems early.

What founders and leaders should do next

If your company currently has a dashboard full of commits, pull requests, story points, and ticket closures, do not assume the answer is to delete every chart overnight. Start by changing what those charts mean and how they are used.

First, audit every metric against the decision-first test. Mark any metric that is used to rank individuals, even informally. Then ask whether it can be converted into a team-level diagnostic measure or replaced by a flow, quality, reliability, friction, or product-outcome measure.

Second, choose one constrained value stream to improve. This could be the path from a bug report to a verified fix, from an approved experiment to production, or from an incident alert to restored service. Instrument the path, listen to the people doing the work, and make one focused change.

Third, publish the intent. Tell engineers explicitly that the goal of delivery metrics is to improve the system, not to build a productivity leaderboard. That statement must be backed by behavior: do not use a sudden metric dip as a shortcut for singling out a person before investigating the context.

Finally, remember that the most important number may be the one that proves a metric led to a better decision. A dashboard that helped a team remove a release bottleneck, reduce recovery time, simplify a risky service, or stop building a low-value feature is doing its job. A dashboard that merely creates anxiety and status meetings is not.

FAQ

What are engineering productivity metrics?

Engineering productivity metrics are measures used to understand how effectively a software delivery system creates valuable, reliable outcomes. Strong programs combine flow, quality, reliability, developer-experience, collaboration, and product-impact signals instead of reducing productivity to code or ticket volume.

Are commits and pull requests bad engineering metrics?

Not inherently. They can help diagnose workflow patterns, review load, or a sudden change in activity. They become poor metrics when used as standalone proof of individual performance, because they ignore task complexity, code quality, collaboration, customer value, and invisible work.

Which DORA metrics should a SaaS team track?

Start with deployment frequency, change lead time, change failure rate, and failed-deployment recovery time. Use them at the team, service, or value-stream level; pair throughput measures with stability measures; and define terms consistently before comparing trends. (cloud.google.com)

How many developer productivity metrics should a team use?

Use the smallest set that supports real decisions, but cover multiple dimensions. The SPACE framework recommends measuring several dimensions rather than relying on one number; in practice, a focused scorecard of six to eight measures is often more actionable than a massive dashboard. (queue.acm.org)

How should teams measure AI coding-tool productivity?

Measure the end-to-end effect on a defined workflow: lead time, rework, production quality, review burden, developer friction, and product outcomes. Avoid using generated lines of code, accepted suggestions, or tool usage frequency as evidence that individual engineers are more productive.

Engineering Productivity Metrics: What Teams Should Measure