Technology Outcomes Versus Technology Activity

Technology organisations can be extremely busy without creating corresponding value.

That is not a criticism of someone else’s team. It is a structural risk in every technology organisation, including the well-led ones, because activity is visible, measurable and reassuring, while outcomes are slower, messier and harder to attribute.

Activity is easy to count

Deployments per week. Tickets closed. Stories delivered. Meetings held. Migrations started. Tools evaluated. PoCs launched. Every one of those numbers can go up while the things the business actually needs (reliability, speed, security, capability, cost discipline) stay flat or decline.

Activity metrics are not useless. They describe the cost side of technology. The mistake is treating them as the value side.

Outcomes are the point

The outcomes that matter are few, and none of them are about technology for its own sake:

  • Reliability: do systems behave predictably, and recover quickly when they don’t?
  • Customer impact: can the organisation ship what customers need, when they need it?
  • Speed: how long from “we decided” to “it’s live”?
  • Security: is the organisation’s risk position improving, or just being described?
  • Efficiency: is the unit cost of what technology delivers going down over time?
  • Business capability: can the organisation do things this year that it could not do last year?

When a technology function can connect its work to those outcomes, conversations with the business change character. Budget discussions stop being negotiations about headcount and become investment discussions about capability.

Why activity wins by default

If outcomes are the point, why do organisations drift toward measuring activity? Three reasons, in my experience.

Activity is measurable now. An outcome like “improved reliability” needs a baseline, a metric and a quarter. A deployment count needs a dashboard. Under pressure, teams reach for what they can show.

Activity feels like control. Leadership dashboards of busy teams are reassuring. “Ninety percent of the roadmap delivered” sounds like leadership, even when the roadmap was the wrong one.

Outcomes require admitting what doesn’t work. Measuring real outcomes means discovering that some of the busiest work contributed nothing. That is an uncomfortable finding, and organisations develop an immune response to it.

What to do about it

The fix is not to stop measuring activity. It is to make outcomes the primary language and let activity justify itself within it.

Start every initiative with the outcome it exists to move. If nobody can name the outcome, that is the finding. Some work is compliance or hygiene, which is legitimate, but then the outcome is named as such rather than dressed up as transformation.

Measure technology the way the business measures itself. Revenue enablement, cost per transaction, incident cost, time-to-market. The moment technology speaks in business outcomes, it is treated as part of the business.

Stop work that isn’t producing outcomes. Teams notice what leadership tolerates, and a portfolio where nothing ever dies is an organisation that has stopped evaluating.

Watch for the busy-team trap. A team at permanent 100% utilisation has no capacity for improvement, which means next year looks exactly like this year, at higher cost. Sustainable capacity is not slack; it is the resource improvement is made of.

Let simplification be a deliverable. Removing a system, retiring a report, eliminating a process: these are outcome-producing work with no activity footprint. If your planning process can’t credit “we deleted it”, people will keep building instead.

The AI version of the same trap

Organisations are now measuring AI adoption (licences distributed, prompts used, assistants enabled), which is activity. The question that matters is whether AI lets the organisation operate in a better way: faster detection, safer releases, better answers, lower cost per outcome. An organisation full of AI usage and unchanged operating metrics has bought the assistive layer of a transformation and skipped the transformation.

The discipline

Technology leadership is largely the discipline of keeping the organisation pointed at outcomes while the gravitational pull of activity (dashboards, roadmaps, backlogs) tries to reassert itself. It is a permanent negotiation, not a solved problem.

Where that negotiation happens out loud, with metrics that mean something, busy and valuable point in the same direction.

Satish Chandran is a senior technology leader specialising in engineering, cloud infrastructure, DevOps, cybersecurity, data and Artificial Intelligence.

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.