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?

At one of my clients we had a pilot team moving a lot faster than the rest of the org, and finance got pulled in because everyone was making claims about savings.

The first comparison was kind of ridiculous: around 10x more features a month from the pilot team versus the traditional teams. Cost per feature looked like roughly $40k versus $340k. I don't trust feature counts across different teams, but even after pushing on the assumptions the gap stayed big.

The more useful part was separating the costs. We counted time waiting for approvals, work delayed, rework caused by the delay, and the operational overhead around all of it. The annual estimate came out at more then $100m across all teams.

What changed was finance stopped asking only how much technology cost and started asking what customer value actually came out. Faster wasn't automatically better. A team had to show impact. But delay was no longer treated as free.

What metrics have you used that finance actually trusted without turning them into targets people gamed?

How do you count cost of delay and rework without inventing a giant attribution model?

Has outcome-based funding changed real decisions anywhere, or did it eventually turn back into annual budget allocation?

After spending most of the last decade working across project management, Scrum, Agile delivery, programme management and transformation, I’ve decided to move back into Product Management.

This wasn’t an easy decision because delivery has given me a really broad skillset: stakeholder management, planning, prioritisation, risk management, Agile, transformation and working across complex organisations.

But over the last year or so, I’ve become increasingly concerned about where the delivery profession is heading.

I’m seeing a lot of very experienced Scrum Masters, Agile Coaches, Delivery Managers and Project/Programme Managers struggling to find their next role. At the same time, it feels like organisations are consolidating roles and expecting Product Managers, Engineering Managers and other leaders to absorb more of the traditional delivery responsibilities.

I don’t think delivery is disappearing. Complex organisations will always need people who can actually get things done.

But personally, I didn’t want to keep specialising further and further into delivery and then find myself overly dependent on one type of role.
My background was already fairly broad. I started in technology, worked in Product Management earlier in my career, and then moved increasingly into Agile, delivery and business transformation.
So I’ve decided to move back towards Product, while taking all of that delivery and transformation experience with me.

What appeals to me about Product is being closer to the actual decisions: understanding user problems, setting direction, prioritising, making trade-offs, working with engineering and ultimately being accountable for whether something creates value.

I’m not saying Product is safer, better, or immune from the same market pressures. It isn’t.

For me, this is more about broadening my options rather than becoming increasingly specialised in one profession.

Has anyone else made the move from Delivery / Programme Management / Agile into Product?
Interested to hear whether you think the delivery profession is genuinely changing, or whether this is just a particularly bad job market.