When Work Becomes a Capability

Understanding the distance between policy and operations

Abstract

Most operational capabilities are built on purpose. A few are not. This paper examines a kind of work that many organizations perform every day, often carefully, without ever having decided to make it a capability — and asks why such work can stay undesigned for decades after it has stopped being incidental. Responding to requests from authorities — police, prosecutors, financial-intelligence units, regulators — is the motivating case. The explanation we arrive at is less a matter of oversight than of incentives: organizations rationally underinvest in recurring work whose value is external and preventative while its costs are internal and concentrated, and the resulting neglect is self-reinforcing rather than accidental. None of the underlying ideas are ours; the economics of externalities, collective action and preventative investment are well established. Our contribution, if there is one, is to apply them together to a single operational phenomenon, and to notice that the phenomenon now appears to be changing. It is offered as a way of seeing, not a law, and the paper marks clearly where established theory ends and our own observation begins.

"This is not our core business."

That sentence explains more than it first appears to. By the end of this paper it will have explained most of what we set out to understand.

Banks do not exist to answer police requests. Telecom operators do not exist to preserve evidence. Crypto exchanges do not exist to prepare case material for prosecutors. And yet, every day, inside each of these organizations, people do precisely that.

The work is easy to picture. A request arrives — usually by email, into a shared mailbox that a handful of people watch. Before anyone can answer it, someone has to work out what is actually being asked, whether the person asking is who they claim to be, what may lawfully be disclosed, where the relevant data lives, and how to assemble and return it without making a mistake that cannot be taken back. The work arrived gradually, and capable people absorbed it. A shared mailbox appeared, then a checklist, then the quiet expertise of a few individuals who simply know how it is done. Our own data hints at how informal the arrangement remains: in the adjacent case of institution-to-institution fraud response, we find that roughly a third of such messages in Sweden are sent outside working hours — evenings, nights, weekends — into inboxes no managed process is watching. That is an observation, not a proof, but it is the texture of work that is being done rather than run.

It helps to remember that organizations are not designed around work. They are designed around a mission. A bank is organized around banking, a telecom operator around telecommunications, a hospital around care. Everything else — everything necessary but off-mission — begins life as incidental work, absorbed at the edges by whoever is nearest. Some incidental work quietly grows into a recognized operational capability. Most of it never does. The question this paper is really asking is what decides which path a piece of work takes. Authority-request handling turns out to be an unusually clear specimen, because it has existed for decades and, in many organizations, still has not made the crossing.

The puzzle

This is not a story about incompetence. The work is frequently done with real care, by people who take it seriously and who have developed genuine judgement about hard cases. Processes exist. Knowledge exists.

And yet, measured by the ordinary standards an organization applies to its other operations, something is missing. Ask how many requests arrived last quarter, which authorities generate the most work, how long the organization takes to respond, what the work costs, or where it most often breaks — and the honest answer is, surprisingly often, we don't really know.

The contrast is sharpest against the capabilities an organization does build deliberately. Incident management, availability, information security, customer support, quality: each has an owner, a budget, a dashboard, and a place in someone's objectives. Authority-request handling has the work but rarely the apparatus. The apparatus never came — and the reason it never came is the sentence we started with. It is not the core business, so it was never anyone's job to make it one. So the puzzle is not that the work is done badly. It is that work this real, this sensitive, and this recurring is so seldom managed as the thing it has quietly become. Why?

The answer we arrive at is not a lapse but a trap — a self-reinforcing state that keeps the work undesigned no matter how competent the people inside it, and that reappears, later and larger, between organizations as much as within them. Everything that follows — the incentives, the ownership, the visibility, the funding, the fragmentation — is less a list of separate causes than a description of how that trap holds itself shut. The rest of this paper is an attempt to take it apart.

Why the easy answers feel incomplete

Three explanations come quickly, and each is partly true and finally unsatisfying.

The first is that nobody noticed. But the people doing the work noticed long ago; they live its friction every day. The organization is not unaware the work exists.

The second is that it is a tooling problem — the shared mailbox, the spreadsheet, the absence of a system. But tools are downstream. Organizations acquire tools for capabilities they have decided to own; the missing tool is a symptom of a missing decision, not its cause.

The third is that it is a work-environment problem — the stress, the context-switching, the unclear ownership felt by the people at the mailbox. That strain is real, but it is better read as the first place a missing capability becomes painful than as the reason it went missing.

Each explanation describes the situation. None explains why it is so stable, or why capable organizations, aware of the work and able to afford the fix, so consistently leave it undesigned. For that we have to look at the incentives — and once we do, the outcome starts to look less like a lapse and more like something that could hardly have gone otherwise.

The incentive model

Consider what the capabilities an organization does build deliberately have in common: their consequences are felt by the organization itself, and felt visibly. Downtime is immediate and public. An outage reaches revenue and executives within minutes. A breach can threaten the firm's survival. Defects return as complaints and cost. Even when these capabilities are "non-functional" or merely enabling, a manager can explain why they matter, because each is attached to a consequence the organization feels directly.

Authority-request handling is different in a specific and consequential way, and it is different along two axes at once — which is easy to miss if one looks only at where the value goes. The first axis is externality. Much of the value of handling these requests well accrues outside the organization: to an investigation, to a victim, to the public interest, to the authority on the other end. This is the ordinary economics of externalities — benefits that fall largely on parties other than the decision-maker are systematically under-produced. The second axis is prevention. What internal value does exist shows up only as bad things that did not happen: a fine not levied, a reputational incident avoided, a regulatory finding not written. This is the equally ordinary economics of preventative investment, the same reason organizations historically underfunded security and business continuity — value that manifests as an absence is hard to see, easy to defer, and rarely rewarded.

It is worth making the consequence concrete, because it is where the argument becomes hard to argue with. Picture an executive with one unit of budget and four proposals on the desk. One improves availability. One improves customer support. One strengthens incident response. One would properly design the handling of authority requests. Three of the four attach to a consequence the organization feels directly, can measure, and will be asked about. The fourth promises, at best, that something unpleasant will fail to happen, to the benefit largely of someone outside the firm. Almost everyone can predict which three get funded, and they are not wrong to predict it. Nothing in that decision requires anyone to undervalue the public good, or to be short-sighted, or to fail at their job. A conscientious manager, acting entirely reasonably, arrives at the same place. Run that decision across an industry and across two decades, and the surprising thing would be if the capability had been built. The neglect is not a failure of the system. It is what the system, working as designed, produces.

There is a second reason the work stays informal, and it explains why even visible friction rarely forces a fix. The cost is not absent; it is smeared. The small team feels it daily. Platform teams feel it occasionally, as awkward manual extractions they would rather not maintain. Security feels unease about sensitive data moving through informal channels. Compliance often files the whole area under "we are, technically, answering the authorities." Legal engages only on the hard edges. An enterprise architect reading that list will recognize the shape of it: the capability has no home because nothing in the organization's structure corresponds to it — a pattern reminiscent of Conway's Law, where systems and their gaps mirror the org chart that produced them. The consequence is a familiar human dynamic. Nobody experiences enough pain to justify a transformation. Everyone experiences enough pain to quietly work around it. Each unit carries a little; none carries enough, alone, to bear the effort of a fix — a collective-action problem of exactly the kind that leaves shared burdens unattended even when the group as a whole would gain. Collectively the organization carries real operational debt. Individually every unit can tolerate its share. And so the workarounds persist — not because anyone is foolish, but because, for each person, tolerating the work is cheaper than fixing it.

A trap, not merely a tendency

It would be easy to stop there, but while setting the argument down it became clear that this is only half of the mechanism — and the missing half is what makes the situation so durable.

Because the cost is diffuse, no one invests in measuring the work. Because no one measures it, the organization cannot see its true size or cost. Because it cannot see it, no one can build the concentrated case that would justify investment — which keeps the cost diffuse. Invisibility and weak incentives are not two separate problems. They sustain each other.

The capability, in other words, is at once orphaned — no unit owns enough of its cost to sponsor it — and illegible — the organization lacks the numbers it would need to argue for it. Each condition reproduces the other. That is why the state persists for so long, and why it so rarely corrects from the inside. It is a self-reinforcing equilibrium, and equilibria of this kind are usually broken not from within, but by a push from outside.

The reach of an explanation is tested by the awkward cases it can make sense of. In some conversations we have encountered a darker version of the same incentive: the idea that responding slowly might, over time, reduce how often one is asked. Whether it is ever made explicit or remains merely tacit we cannot say; treat it as an anecdote, the weakest tier of evidence. But it is revealing precisely because it is so strange. In a sponsored capability it would be self-evidently absurd — no one proposes making incident management slower so that fewer incidents get reported. That the same move could even appear locally reasonable here is itself the symptom. It is what an organization does when it experiences the work as an external burden to be minimized rather than as a capability it owns. The point is not an ethical one. It is an incentives one — which is the more useful, and the more forgiving, way to read it.

What we are borrowing, and what we are not

It is worth being explicit about where these ideas come from, because almost none of them are ours. The under-provision of goods with external benefits is basic externality economics. The under-provision of preventative measures whose payoff is an avoided loss is a familiar pattern in risk and safety investment. The diffuse-cost, no-champion dynamic is a collective-action problem in the classic sense. The fragmentation an architect will already have recognized is Conway's Law. That capabilities mature through recognizable stages, from ad hoc to managed to optimizing, is the long lineage of capability maturity models.

Our contribution, if there is one, is not any of these ideas. It is the observation that they appear to combine, in this one domain, into a single stable explanation: a capability whose value is both external and preventative, whose cost is diffuse, and whose invisibility and neglect reinforce one another — producing decades of rational underinvestment that looks, from the outside, like an oversight and is really an equilibrium. We put the pieces together and point at a phenomenon. We did not make the pieces.

Why the capability is becoming visible now

A model of this kind would be of historical interest only if nothing were changing. Something is — and here, writing the paper sharpened our own view. We had described the change loosely as "external expectations outgrowing internal structures." That is directionally right but imprecise. The sharper claim is a single idea, and it may be the most useful one in this paper:

For decades the value of this work sat outside the organization, or lay dormant as a rare avoided loss. What is happening now is that a series of forces are converting that external, preventative value into concrete, internal, immediate cost — the one kind of cost that moves a sponsor's own metrics. Request volumes are rising, so the diffuse cost is becoming large enough to see. Digital evidence has moved to the centre of investigations, so the value of prompt, correct handling is no longer marginal. And regulation is attaching prices to what was once discretionary: the EU's e-Evidence Regulation — which applies from August 2026 — sets response deadlines of ten days, and eight hours in emergencies, backed by penalties of up to 2% of worldwide annual turnover; police-led cooperation initiatives introduce explicit expectations about response time and consistency. A deadline with a penalty is precisely the mechanism by which an externality becomes an internal obligation with a cost attached. The world is beginning to say something the sentence we started with never had to answer before: it may not be your core business, but you are now expected to perform it well.

This is the same arc information security and privacy already walked, and the parallel is worth stating plainly because it is the strongest evidence we have. Security did not become a managed capability because organizations grew wiser; it became one when breaches turned into existential internal cost. Privacy did not become a managed capability out of principle; it became one when regulation turned it into a priced obligation. In each case the externality was internalized, and the capability followed. Authority-request handling appears to sit earlier on the very same curve.

The claim has a testable shape, which is the most a working model can offer. If the mechanism is internalization, then investment should track it: capabilities should begin to form exactly where and when the external value becomes concrete internal cost, and orphaning should persist wherever it stays diffuse. It also explains the exceptions any honest model needs. Some organizations did invest early — and, tellingly, they tend to be ones for whom the value was already internal: a firm that took a public reputational hit, or a service provider whose market access depends visibly on cooperating well. Where the externality was already internalized, the capability appeared. That is not a hole in the model; it is the model's own prediction, and its boundary.

The same shape, one level up

The mechanism we have been describing does not stop at the edge of the organization, and on reflection it was never going to. The work itself crosses that edge: an authority request arrives from outside and its answer goes back outside, and what counts as handling it well — what a valid request looks like, which fields it carries, how an ambiguous cross-border case is resolved — is only ever half an internal matter. The rest is a shared convention, something that has to hold across many organizations and many authorities at once or it does not really hold at all. The work is cross-organizational to its core, and so, it turns out, is the capability.

Look at that shared layer with the same eyes and the same diagnosis appears. The value of a well-formed common practice is external and diffuse in exactly the way the internal capability's was: everyone benefits a little, no single participant benefits enough to own it, and its cost — the patient, unglamorous work of converging on a shared way of doing things — falls on whoever volunteers. No organization's mission is to improve the ecosystem's shared operational practice. So the capability to evolve that practice is, like its internal cousin, orphaned — only now the orphaning happens between organizations rather than inside one.

Part of what keeps this capability out of sight is that no one is positioned to see it whole. Each participant meets only a fragment. The bank sees requests coming in; the police force sees requests going out; the prosecutor sees evidence; the compliance team sees a legal obligation; the manager sees a staffing line. Every one of these views is real and partial, and none of them is the capability. A thing no single vantage point can see is a thing almost impossible to recognize, let alone own — which is a large part of why it stays undesigned even when everyone touching it is competent and paying attention.

The symmetry also runs further than it first appears, in a way that matters for what follows. The undesign is not only on the responding side. Collecting evidence is unmistakably police work; interviewing a witness is police work; forensic analysis is police work. But issuing tens of thousands of structured digital requests to regulated organizations has, on the authority side too, been treated as work rather than as a capability anyone set out to build. This is not a criticism of either side; it is the same pattern faced from both ends. And it has a consequence. If neither the organizations that answer nor the authorities that ask have intentionally formed the capability, the ecosystem that would have to hold the shared version of it has almost no chance of forming one on its own.

The capability, in other words, is orphaned twice. First inside the organization, where no unit owns it. Then across the ecosystem, where no organization owns the shared practice the internal work quietly depends on. And the two are not independent. An organization struggles to mature internally partly because so much of doing the work well depends on agreements only the ecosystem can supply; the ecosystem struggles to improve partly because the organizations have not yet made their own practice legible enough to contribute. Neither side can fully mature alone. This looks less like a loose coupling than like the same self-reinforcing trap we described inside the organization, now sprung one level up: each layer waits for the other to mature, so neither quite does. How tight the lock is, we have not measured. But it was the first place our own model surprised us — and it is where the third paper in this series goes to work.

Implications

What the model changes is the question an organization should be asking. For years the only question was operational: how do we handle these requests? The more useful question now is a different one: have we crossed the point at which this recurring work has become a capability — whether or not we have ever named it as one?

To answer it honestly is to accept a distinction the preceding pages have been circling. Managing a capability is not the same as performing its work. It means naming an owner, making the volume and cost legible, designing the process rather than inheriting it, and holding it to the same standard of measurement and improvement the organization already applies to everything it has decided to take seriously. Set against that standard, most organizations are not doing this work poorly. They are doing it ownerlessly — which is a different diagnosis, and a more forgiving one.

And so the conclusion is simple, and once seen it is difficult to unsee. The work existed all along. The people existed. The requests, the routines, the quiet expertise — all of it was there. What was missing was never the work. It was the capability.

What remains open. A few questions. Whether "threshold" is too clean a word for something probably gradual and uneven. Whether internalization produces a well-designed capability or merely a compliant one — an organization forced to meet a deadline may build something minimal and brittle, which would be a different and important story. And the second-level claim — that the same capability is orphaned again between organizations, and that the two levels hold each other in place — is the newest here and the least tested. The evidence throughout is established economics applied to a domain where our own data is still field observation rather than measurement. If you have watched a capability emerge this way — or fail to, where the model says it should have — we would like to hear it. The most useful thing a working paper can do is attract the counterexample that improves it.

About Reqport. Reqport studies — and builds infrastructure for — the operational layer where sensitive requests cross organizational boundaries: receiving, verifying, acting on, and accounting for requests from authorities and peer institutions. These Working Papers are part of that inquiry, published on Reqport Insights; they are written to be useful and to be corrected, not to sell. If you have a counterexample, we want it — you'll find us at reqport.com.

Working Paper series · part of an ongoing inquiry into the operational layer between policy and practice. Drafts are revised as the thinking changes; that they change is the point.

Erik Obitz

Solution Architect

Erik works on the technical side of Reqport. He came at it as a solutions architect and found a problem that turned out not to be a technical one at all — how organisations handle the sensitive requests that arrive from police, regulators and each other, and why that work so often lives in a shared mailbox and a few people's heads. He writes here to think it through in the open. Corrections welcome.

LinkedIn