As an engineering manager, you need to know which metrics to use and how to connect them. Data is easy to find. Deciding which signals matter is harder. A good metric helps you spot risks, inform decisions, or start a conversation with your team. A metric that only tracks activity generates noise and can push you toward the wrong conclusions.

I use three groups of metrics in my daily work:

  • Delivery metrics
  • Backlog health metrics
  • Product and platform health metrics

Together, they help me understand whether the team is delivering predictably, whether work is becoming blocked or outdated, and whether the product remains reliable.

Delivery Metrics

Postponed Deliveries

Track items that have already passed their target dates.

The number alone is not enough. Look at why the work was postponed. Common causes include unclear requirements, underestimated complexity, external dependencies, changing priorities, and insufficient capacity. Raise those topics during the next retrospective.

Deliverables at Risk

Track in-progress work approaching its deadline to identify risks and communicate proactively with stakeholders. A deliverable due in three days is at risk if development is incomplete, the review has not started, or an external dependency is unresolved.

Work in Progress

Track the number of tasks that are currently active.

Each team has a practical limit on how much work it can handle at the same time. When too many items are in progress, delivery slows down, context switching increases, and work remains unfinished for a longer period.

Define a healthy range for your team and analyze when work in progress moves outside it.

Burndown Chart

A burndown chart shows the planned scope, the expected path toward completion, and the remaining work over the course of a release.

It is most useful during release execution because it helps you see whether the team is moving toward the target or whether the remaining scope is no longer realistic.

Workload Distribution

Track how responsibilities and active work are distributed across the team.

Do not use this to compare developers by counting tickets or story points. Use it to identify overload, uneven ownership, and situations where too much knowledge or responsibility depends on one person.

This can also reveal team members who have the capacity to support additional work.

Release Capacity

Estimate how much capacity the team realistically has for a release or milestone.

Do not calculate capacity by multiplying the number of developers by the number of working days. Account for vacations, public holidays, support requests, maintenance, reviews, meetings, onboarding, and other recurring responsibilities.

The result will be different for every release. The calculation does not need to be perfect, but it should reflect the way the team actually works.

Where possible, automate this calculation using internal tools that already track absences and availability.

Release Issue-Type Ratio

Track the percentage of work assigned to different issue types.

For example, a release may contain:

  • 60% features
  • 30% bug fixes
  • 10% technical debt

This helps people understand that engineering work is not limited to visible features. It also includes reliability, product quality, and long-term investment.

I track this ratio across the last 10 releases. It gives me a clear view of how the balance of work changes over time.

Velocity Across Recent Releases

Track the number of story points completed during each release cycle.

The trend matters more than the number from a single release. I also look at the average across the last three releases to reduce the effect of unusually large or small delivery cycles.

Velocity should support planning within the same team. It should not be used to compare teams or individual developers.

Open Merge Requests

Track:

  • The number of open merge requests
  • Their average age
  • Merge requests older than an agreed threshold

These metrics can reveal review bottlenecks, unclear ownership, and merge requests that have been forgotten.

The total number of merge requests created is much less useful than understanding why important changes remain open.

AI Adoption

Most teams are still learning how to use AI well.

One useful metric is the percentage of team members who use approved AI tools during a development cycle. This can be compared with changes in delivery speed, review time, defect rates, or other relevant outcomes.

For example, three out of five developers may have used AI regularly during a release. You can then examine whether any meaningful changes appeared in delivery or quality.

This comparison does not prove that AI caused an improvement. Release complexity, team composition, technical debt, and scope quality may also influence the result. However, it gives managers a useful starting point for evaluating where AI helps and where it does not.

This should not be confused with maximizing token usage. More tokens do not automatically create more value.

Our industry is full of claims about “10x AI engineers.” Real project data provides a better basis for deciding whether AI tools are useful and whether their cost is justified.

Backlog Health Metrics

Backlog Graveyard

Track items that have not been updated for a defined period.

The threshold depends on the product. For a fast-moving startup or greenfield project, it might be 90 days. For a large corporate platform, it could be 365 days or longer.

If an item has not been discussed, updated, or worked on for a long time, it may no longer represent an important product need.

The team can then reject it, rewrite it, reprioritize it, or move it out of the active backlog.

A smaller and more relevant backlog is easier to understand and manage.

Average Age by Issue Type

Track the average age of each type of backlog item separately.

This may include:

  • Bugs
  • Product stories
  • Technical evaluations
  • Support requests
  • Technical debt
  • Security issues

A single average across the entire backlog can hide important problems.

For example, product stories may move normally while support requests remain unresolved for months. If the average age of one issue type keeps increasing, it usually means the team is not allocating enough attention to it.

Average Time in Status

Track how long work remains in each workflow status.

This helps identify where delays originate.

Implementation may be fast while review takes several days. Work may remain blocked by another team. Requirements may spend too long waiting for clarification. Testing may become a bottleneck near the end of every release.

This metric helps managers improve the process rather than asking the team to work faster.

Created Versus Resolved

Compare the number of items created with the number resolved during the same period.

If the team consistently creates more work than it completes, the backlog will continue to grow.

That does not always mean the team is underperforming. It may indicate increasing customer demand, poor issue filtering, recurring product defects, or insufficient capacity.

The value of the metric is that it makes the trend visible.

Product and Platform Health Metrics

Delivery metrics show whether work is moving. Technical metrics show whether the product is healthy.

Both perspectives are necessary. A team can deliver a release on time while reliability, latency, or customer experience continues to decline.

Service-Level Indicators

Availability

Track the percentage of time the product or service is available and operating as expected.

The definition of “available” should reflect the customer experience, not only whether the infrastructure is running.

Error Rate

Track the number or percentage of failed operations.

Not every 4xx response represents a product failure. Some may be expected results of invalid requests or authorization rules. Define which responses indicate actual customer or service problems.

Latency

Measure response times across relevant percentiles, such as P50, P95, and P99.

Averages can hide poor experiences for a smaller group of users. Percentiles provide a more complete view of performance.

Throughput

Track the number of requests, transactions, messages, or operations processed during a defined period.

Throughput becomes most useful when reviewed together with latency, error rate, and infrastructure capacity.

Operational Health Metrics

Alert Quality

Track the number of alerts, the percentage that require action, and the number of repeated or ignored alerts.

A large alert volume does not mean strong monitoring. It may indicate that the team is overwhelmed by noise.

Track incidents by severity, affected service, cause, and customer impact.

Useful supporting metrics include:

  • Mean time to detect
  • Mean time to restore
  • Number of repeated incidents
  • Number of incidents by severity
  • Percentage of incidents with completed follow-up actions

The goal is not only to reduce the incident count. It is also to improve detection, response, learning, and prevention.

Log Signals

Logs are a source of operational information rather than a metric by themselves.

Useful measures may include error volume, repeated exception types, sudden increases in warning logs, or the percentage of requests with sufficient diagnostic context.

Good logging should help the team understand what happened without creating unnecessary noise or cost.

Metrics That Should Not Be Used as Productivity Measures

Some metrics show activity but say very little about customer value or engineering effectiveness.

Commits per Developer

The number of commits depends heavily on working style, task structure, and repository conventions.

More commits do not mean more useful work.

Merge Requests Created

Managers should care about merge requests waiting for review, remaining open for too long, or becoming blocked.

The total number created is not a meaningful measure of individual performance.

AI Tokens Used

Token consumption shows usage and cost. It does not show whether AI improved delivery, quality, or decision-making.

Lines of Code

Lines of code may occasionally help estimate the size of a migration or codebase, but they should not be used as a productivity metric.

A developer who removes unnecessary code may create more value than someone who adds thousands of new lines.

Metrics Should Lead to Decisions

I use these metrics to understand delivery risks, process bottlenecks, overloaded areas, backlog problems, and changes in product health.

However, no dashboard can replace conversations with the team.

Metrics tell you where to look. They do not always tell you why something is happening.

The goal is not to collect as much data as possible. The goal is to notice problems earlier, make better decisions, and help the team deliver reliable value to customers.