u/mbakbergenov

I think many engineering dashboards mix two very different categories: activity signals and outcome signals.

Commits, pull requests, tickets closed, review time, and deployment frequency can help explain how work moves through a system. But they become dangerous when treated as performance scores. Once a team knows an activity is being judged, the activity can become the target. More output may then look like better engineering even when the product becomes harder to maintain or customers see no meaningful improvement.

A framework I find useful is to separate the conversation into three layers:

Activity: What work happened?

System health: How safely and predictably can the team make changes?

Outcome: What became better for the business, product, or customer?

The first layer is diagnostic. The second shows engineering capability. The third provides direction. None should be read alone.

For example, a rise in pull request volume is not automatically good or bad. It becomes useful only when paired with context: Was important work delivered? Did reliability improve? Did the team reduce recurring operational pain? Are changes becoming easier or more fragile?

The uncomfortable part is that outcome metrics are usually shared across product, engineering, and the business. That makes individual attribution harder, but perhaps that is the point. Software development is a system, not a leaderboard.

How do you distinguish useful operational signals from activity metrics that quietly turn into performance targets?

A useful engineering metric should help a team make a decision. An activity metric usually just makes work look measurable.

Commits, pull requests, tickets closed, review comments, and hours logged can describe activity. They cannot tell you whether the team reduced risk, improved delivery, clarified ownership, or built the right thing. Once these signals become targets, people naturally adapt their behavior to the dashboard.

I find it more useful to separate metrics into three layers:

Activity: What work happened?

Flow: How smoothly did work move through the system?

Outcome: What changed for customers, the product, or operational risk?

Activity can still be useful for diagnosis. A sudden change may reveal a blocked workflow, overloaded reviewers, or fragmented work. The mistake is treating activity as a proxy for individual performance or business impact.

For SaaS leaders, the practical test is simple: what decision would change if this metric moved? If nobody can name the decision, the metric may be reporting theater. If the answer is “we would ask better questions,” it may be a useful diagnostic. If the answer is “we would rank engineers,” it deserves much more scrutiny.

The hard part is that outcome metrics often move slowly and have many owners, while activity metrics are immediate and easy to collect. How have you designed engineering reporting that remains useful to leadership without turning observable activity into a performance score?

Slow delivery is often treated as an execution problem before anyone checks whether the work was executable in the first place.

When a product team feels slow, I use a simple diagnostic built around four layers:

Direction: Can the team explain what outcome matters and why this work comes first? If priorities keep shifting or success is vague, speed inside the sprint will not solve the underlying problem.

Readiness: Was the work sufficiently understood before implementation began? Look for unresolved product decisions, unclear ownership, hidden dependencies, and missing technical context. Work that enters development too early usually creates waiting and rework later.

Flow: Where does work actually stop? Review queues, handoffs, approvals, environment access, and dependency coordination. The useful question is not whether people are busy. It is where an item waits without becoming more valuable.

Feedback: How quickly does the team learn that an assumption, implementation, or release is wrong? Slow review, weak observability, and delayed stakeholder feedback make small mistakes expensive.

I would run this as a short leadership exercise: choose one recently delayed item, reconstruct its path from idea to production, and label each delay by layer. Avoid debating individual performance. The goal is to identify the operating constraint that repeatedly taxes the system.

Only after that would I discuss adding people, changing process, or introducing another tool. Those actions can help, but only when they target the actual constraint.

For engineering leaders here: when delivery slows, which layer tends to be hardest to diagnose in your organization, and what evidence helps you distinguish it from the others?

A founder can watch a product release stall and conclude that engineering is moving slowly. The harder possibility is that engineering is moving, but the founder cannot see what is consuming the effort.

I try to separate delivery problems into three categories:

Visible progress: customer-facing changes are shipping, even if the pace feels uncomfortable.

Invisible progress: the team is removing technical risk, stabilizing systems, improving deployment, or untangling dependencies. The work may be necessary, but its connection to the business is poorly explained.

Unclear progress: activity is high, yet nobody can state what changed, what risk was reduced, or what decision is now possible. This is where concern is justified.

The useful question is not simply, “Why is this taking so long?” It is, “What became easier, safer, or more certain because of the work completed?”

A strong answer should connect engineering effort to an observable outcome without forcing founders to inspect tickets or count commits. A weak answer hides behind complexity. But founders also create the problem when every technical investment must pretend to be an immediate product feature.

I suspect many disagreements about engineering speed are really disagreements about visibility, expected outcomes, and who is responsible for translating technical work into business terms.

Founders and engineering leaders: what evidence do you use to distinguish genuinely slow delivery from important work that is merely difficult to see?

Slow delivery is often discussed as a productivity problem. I find it more useful to treat it as a flow diagnosis.

Start with a recent piece of work that felt unnecessarily slow. Trace its path from the first decision to production, then separate active work from waiting.

Look at four areas:

• Decision latency: Was the goal clear? Who could resolve ambiguity? How long did the team wait for an answer?

• Work shape: Was the change small enough to review, test, and release safely, or did several concerns become one large batch?

• Dependency friction: Did progress depend on another team, environment, approval, or undocumented system?

• Feedback latency: How quickly could engineers learn whether the change worked? Consider local testing, review, deployment, and production signals.

The important part is to avoid turning this into a search for the weakest person. A slow path can make capable engineers look ineffective. I would first identify the longest recurring wait, change that constraint, and observe whether the whole path improves.

This also helps separate visible symptoms from causes. More status meetings may expose delays without removing them. More developers may add coordination to a path already blocked by decisions or dependencies. A new tool matters only if it shortens a specific feedback or waiting loop.

When delivery slows in your organization, which source of delay is hardest to see until you trace one change end to end?

A founder can mistake low visibility for low velocity.

The usual symptoms are familiar: roadmap dates move, updates sound vague, and completed work does not seem proportional to the time spent. The easy conclusion is that engineering is slow. But that conclusion combines several different problems.

I find it more useful to separate delivery into four layers:

• Direction: Does the team know which outcome matters most?
• Flow: Is work moving, or waiting on decisions, reviews, dependencies, and access?
• Load: How much capacity goes to incidents, maintenance, migrations, support, and technical debt?
• Evidence: Can anyone outside engineering see what changed, why it mattered, and what remains uncertain?

If direction is unclear, faster coding will not create faster progress. If flow is blocked, measuring individual output punishes people for system constraints. If operational load is hidden, planned work looks inexplicably slow. If evidence is weak, real progress can appear absent.

Before judging speed, I would ask for a short review of recently finished work, current blocked work, unplanned work, and decisions awaiting leadership. Not as a reporting ritual, but as a way to locate where time actually goes.

The uncomfortable possibility is that engineering may be moving reasonably well while the company has a visibility problem. The opposite is also possible: polished updates can hide poor delivery. That is why status alone is not enough. Founders need to inspect the path from decision to shipped outcome.

What signals have helped you distinguish a genuinely slow engineering system from one whose work is simply hard to see?

A useful engineering metric should help you make a decision. If it only makes activity visible, it is probably an activity metric.

Commits, pull requests, tickets closed, review volume, and coding time can describe how work moves through a team. They can help diagnose a blocked workflow. But they become dangerous when treated as measures of individual or team performance. People adapt to whatever is counted, and visible activity starts replacing valuable outcomes.

I find it more useful to separate metrics into three layers:

Activity: What work is happening?

Flow: Where does work slow down, wait, or get reworked?

Outcome: Did the work improve reliability, customer experience, delivery confidence, or business performance?

The first layer provides context. The second helps operators find constraints. The third tells leadership whether engineering effort is producing something worth having.

The common failure is skipping the question behind the dashboard. A metric should exist because someone has a decision to make. For example: Should we reduce work in progress? Is review capacity limiting delivery? Are incidents consuming planned work? Without a decision attached, dashboards tend to accumulate numbers that are easy to collect and hard to use.

This also changes how metrics should be discussed with engineers. A dashboard used for diagnosis invites honesty. The same dashboard used for ranking invites optimization of the dashboard.

For engineering leaders in SaaS companies, which metrics have genuinely improved a decision you make, and which ones looked useful but mostly measured motion?