Engineering Beyond Delivery: Shared Responsibility for Outcomes

The Isolation Pattern #

Engineers are trained to execute. You get user stories, requirements, and acceptance criteria, then deliver against them. The system should handle X concurrent users, scale to Y nodes, and respond in under Z milliseconds. Those are real constraints, and meeting them takes serious work.

But here is the question nobody asks enough: how many devices in the field are actually running the latest version, and how many users actively use what we built? What does success look like for the product, not just for the current sprint?

When engineers do see those numbers, the conversation changes immediately. The problem is structural: product owns the outcome metrics, engineering owns the system metrics, and neither dashboard talks to the other. Both sides are working hard, and both believe they delivered. When the outcome disappoints, neither can easily explain why, because success was never defined in the same room.

Arc42 is a widely adopted template for documenting software architecture, structured around twelve sections covering everything from system scope to deployment and quality requirements. Section 1 (Introduction and Goals) asks exactly the right questions—specifically around quality goals and stakeholders¹. But in practice, engineers fill them in based on what they understood from the requirements, not from a joint conversation about what the product needs to achieve. It is not that the framework is missing anything. It is a habit: the sections get written alone, and they stay that way.

Define the Measure Before You Build #

Lean manufacturing solved this decades ago: you cannot inspect quality into a product at the end of the line; you must build it into the process from the start². The same applies to software. Scaling to ten nodes and handling a thousand requests per second is not the same as knowing whether a feature is used, whether it reduced manual work, or whether a device fleet in the field is actually running the latest version. The most common failure mode here is a system that passes every test and hits every SLA, but whose impact is either invisible, because nobody instrumented it, or quietly categorized as a cost by leadership, because the connection to business outcomes was never made explicit. The metrics that prevent this do not need to be complicated: adoption rate, time saved per task, reduction in support tickets, devices successfully updated in the field, active users per feature. Simple, concrete measures that both sides agree on before a ticket is written.

I’ve found Impact Mapping to be the most effective way to stop “feature factory” behavior³, but it is not purely an engineering exercise—it is a product exercise that engineering needs to be part of. Product traces the path from the business goal (Why), to the user (Who), to the desired behavioral change (How). Engineering’s role is to ground that map in technical reality: to validate which deliverables (What) are feasible, where instrumentation is missing, and whether the proposed features can actually be measured once shipped. If a feature cannot be traced back to a behavioral change on that map, it should not reach the backlog.

Once those impacts are mapped jointly, they can be translated into concrete engineering requirements using the Goal-Question-Metric (GQM) framework⁴. The model is simple but forces discipline:

1. Define a Goal (e.g., improve onboarding completion across new device types).
2. Ask the Questions that tell you whether the goal is met (e.g., where do users drop off during provisioning?).
3. Instrument the precise Metrics that answer those questions (e.g., telemetry on step-completion latency per device class).

Telemetry is not an afterthought, if a feature cannot be measured, it is not complete. Arc42 Section 10 (Quality Requirements) is built around concrete Quality Scenarios for exactly this reason. The missing step is including product in that conversation: one focused session before implementation starts, not a new recurring ceremony.

Closing the Loop #

Defining metrics upfront only matters if you come back to them. Once the system is running, use one of the meetings you already have — a retrospective, a quarterly review, whatever fits — and check whether outcomes materialized. Did adoption go up? Did manual steps decrease? This does not need its own ceremony; it just needs someone to bring the numbers.

I learned this the hard way when a technically successful project I led was canceled during a political reshuffle. We had the metrics, but because they weren’t part of the “success” conversation with leadership from day one, our work was viewed solely as a cost center. By the time we presented the value in the post-mortem, the decision was already made. Technical excellence doesn’t save a project if the business doesn’t know how to measure its value.

When closing an iteration, the feature showcase is part of it — but it does not stop there. Alongside what we built, we present what moved: edge devices deployed across fourteen countries, X updates pushed to the fleet, Y bug reports received, deployment time down from X to Y minutes, operator touchpoints cut in half. That context is what turns a status report into a decision. “We closed twelve tickets” tells the room nothing. “We closed twelve tickets, the automation is working, but the failure pattern is still regional” tells the room exactly where to focus next.

To scale this without manual overhead, these checks can be automated in CI pipelines using Architectural Fitness Functions⁵ — ensuring the system continuously validates the quality scenarios and business metrics defined at the start, not just at the end of an iteration.

Conclusion #

The gap between what engineering delivers and what the business values is a coordination problem, and it compounds quietly. The tools to fix it already exist — Arc42 has the sections, Impact Mapping has the structure, GQM has the discipline. What is missing is the habit of using them together, with the right people in the room, before a single ticket is written.

Next sprint: before the backlog is groomed, get product in the room to agree on what success looks like. Write it in Section 1. Define three measurable quality scenarios in Section 10 together. Then close the iteration with those numbers, not a feature list.

That is the difference between engineering as a cost and engineering as an investment. And it is entirely within your control.