Recognizing an Undesigned Operational Capability

A field guide to the traces left by work that no one owns

Abstract

Working Paper 0001 proposed an explanation for why some recurring operational work — responding to authority requests was the case in point — can remain undesigned as a capability for decades: its value is largely external and preventative, its cost internal and diffuse, and the neglect settles into a self-reinforcing equilibrium rather than a passing oversight. This paper does not re-argue that. It assumes it, provisionally, and asks a more practical question: if that explanation is broadly right, what would such a capability look like from the inside? We never see a capability like this directly — no one drew it, named it, or put it on a chart. We can only read it from the traces it leaves behind. What follows is a field guide to those traces: six recognitions, offered for the shock of the familiar rather than for agreement. We think many will land. We also try to be honest, more than the first paper needed to be, about where recognition ends and diagnosis would have to begin.

A sentence that sounds false and isn't

Start with an observation that sounds like a provocation and is only a description:

It sounds false because the requests plainly get answered — someone reads them, checks them, assembles the data, sends it back. Work is happening. But doing the work and managing the capability are not the same thing, which is where the first paper ended, and once you hold the two apart the sentence resolves from provocation into plain fact. In a great many organizations no one manages this. No one owns it end to end, sets its direction, measures it, or is accountable for whether it is getting better or worse. It is managed the way weather is managed: coped with.

The sentence needs one correction to stay honest, and the correction is the real point. Of course there are managers. They manage people, they carry real responsibility, and they often care about this work more than anyone else in the building. What goes unmanaged is not the people or the tasks — it is the capability: the thing itself, as an owned, designed, measured whole. Everyone in the picture is working inside it. No one is managing it.

If Working Paper 0001 is right about why — that this is what becomes of work whose value is external and preventative and whose cost is diffuse — then this paper is about what that leaves behind. And here is the difficulty, which is also the method: you cannot see an orphaned capability directly. No one drew it. It appears on no map, in no budget, under no title. A capability like this leaves traces before it ever has a name, and the only way to find it is to read them.

One idea runs underneath all six, borrowed gratefully from the Lean tradition's insistence that you cannot improve what you cannot see. An orphaned capability lives in a narrow band of visibility: visible enough to survive, but not visible enough to improve. Visible enough that the requests get answered and the pain never sharpens into a crisis; invisible enough that it never acquires the numbers, the owner, or the attention that would let it get better. Nearly every trace below is a consequence of that band. And nearly every one, followed far enough, ends at the same quiet sentence the people doing the work will give you if you ask why it is like this: because it is not our core business.

We have noticed something small, and at first easy to dismiss. When practitioners describe this work, they tend to open with the same sentence — "this isn't really our core business" — and they say it independently, in different organizations, unprompted. One organization saying it is an anecdote. Many saying it, without having spoken to each other, is a trace.

Recognition 1 — Everybody owns a piece; nobody owns the whole

Ask who owns the handling of authority requests and you will rarely get a name. You will get a map. Legal owns the interpretation of what is lawful. Compliance owns the regulator and the reporting. Fraud owns the cases that arrive through its channel. Security owns the worry about sensitive data leaving through informal paths. Operations owns the day-to-day answering. IT owns the systems the data has to be pulled from. Every answer is correct. Every team owns a real piece. And because every team owns a piece, no team owns the whole.

Legal Compliance Fraud → | shared mailbox | → Security Operations IT

An enterprise architect will recognize this before it is named. Try to place "handling authority requests" on a business capability map and it has no clean home; it cuts across five or six capabilities that each already belong to someone else. The cause is structural — the pattern Conway described half a century ago, in which an organization's systems, and its gaps, mirror its communication structure. There is no owner because there is no box on the chart that corresponds to the capability. It falls, permanently, into the space between boxes. No one decided that. It is what happens to work that arrived after the organization had already been shaped around its mission — work that was, and remained, not the core business.

In one workshop, almost by accident, we began listing on a whiteboard every kind of authority request a single team handled. It was meant only to frame a discussion. Twenty minutes later the board was full, and something no one had expected had happened: for the first time, the people in the room could see the whole of the work at once. Each had known their own part for years. None had ever seen the shape of it. The capability had existed for a decade. The map had existed for twenty minutes.

Recognition 2 — The mailbox that became an operating system

Now look at how the work is actually coordinated, and notice that you are looking at a shared mailbox doing a job no one ever gave it.

The interesting thing is not that organizations use shared mailboxes. It is what the mailbox silently turns into. It becomes the queue — the list of what is waiting. It becomes the assignment system — who handles what is decided by who opens it first. It becomes case management — the thread is the case history. It becomes the audit trail — what happened is whatever the emails say happened. It becomes prioritization — urgency is whatever floats to the top of the inbox. None of this was designed, and none of it is acknowledged. A tool built to pass messages has quietly become the operating system of an entire capability.

This is not incompetence; it is improvisation, and improvisation is what capable people do when they are handed real work without real tooling. But a Lean practitioner would name the specific problem at once: this is a queue no one can see into. It holds the work-in-progress of a whole capability and exposes almost none of what Lean teaches you to look for — how much is waiting, how long it has waited, where it is stuck, who is drowning. It is good enough to keep the work moving and not good enough to let anyone understand the flow. It is, precisely, visible enough to survive and not visible enough to improve. Once you have seen a shared mailbox this way, it is hard to walk past one again.

Recognition 3 — The capability that lives in people

Ask how a new person learns this work and the answer is a name, not a document. You sit with Anna for a few weeks. Every organization has an Anna: the one who knows which authorities can compel what, what a valid request looks like, how to handle the awkward cross-border one, who to call when something is off. The real operating knowledge lives in a few experienced people, and it was never written down because writing it down was never anyone's job. The checklist, where there is one, holds maybe a third of what Anna actually knows.

This is the invisible work that the field of that name has long described, and it produces a figure worth naming: the heroic operator, whose competence is exactly what keeps the organization from noticing that the capability underneath is undesigned. Here empathy is not a courtesy but the accurate reading. Deming's insight is worth stating plainly for anyone who has not met it: recurring problems usually come from the design of the system, not from the effort or competence of the people working inside it. That inverts the usual view: Anna is not a risk the organization is running, she is the compensation it is unknowingly relying on for a system it never built. The key-person risk is real, but it is a symptom, not a fault. And it points to the quiet error underneath. Seeing a capable person handle the work, the organization concludes the work is handled. It mistakes expertise for capability. ITIL has long kept the two apart — performing a service is not the same as owning it — and what is missing here was never the performance. It was the ownership.

Recognition 4 — The questions no one can answer

A quiet test. Ask four questions. How many authority requests did we receive last quarter? Which authorities generate the most work? How long do we take to respond? What does this cost us? In a managed capability these are trivial. In an orphaned one they produce estimates, caveats, and an honest shrug.

The blank is not carelessness; it is the illegibility half of the equilibrium the first paper described, seen from the floor. And it is often worse than a blank, because the few numbers that do exist understate the work.

In one organization, the operational reporting counted incoming emails. The people doing the work counted something else. A single email often carried a spreadsheet of identifiers, and each identifier was, in practice, its own request. The report said one. The work was fourteen. Both numbers were honest; they were simply counting different things.

Lean's practice of visual management exists to close exactly this gap — to make the true shape and volume of work physically visible so it can be reasoned about — and its absence is the whole point. It is how a real, sizeable, costly operation sits inside a data-rich organization and stays, in the only sense that lets you manage anything, unseen.

Recognition 5 — Everyone improves their part; no one improves the whole

Where improvement does happen, watch where. Legal refines its templates. Fraud tightens its intake. IT scripts a faster extraction. Each is real and sensible, and each makes one team's slice a little better. What almost never happens is improvement of the thing itself — because there is no thing that anyone owns to improve. Every team improves its own work; no team improves the work.

Lean and systems thinking are clear-eyed about why this fails: the sum of locally optimized parts is reliably worse than a designed whole, because the real losses live in the handoffs and queues between the parts — the places no single part owns. The request that waits three days in the gap between Fraud and Legal is invisible on both dashboards; each did its bit promptly. There can be no improvement loop across the capability, because a loop needs measurement to close it and the measurement (Recognition 4) does not exist. Deming would recognize the configuration at a glance: a system optimizing its components while no one is responsible for the system.

Recognition 6 — Success is silence, and no one is looking forward

Finally, notice how the work announces itself, which is to say barely. Done well, nothing visible happens — no revenue, no green dashboard, no grateful customer. Done poorly, often nothing immediate happens either — an authority waits, a finding lands months later, a risk quietly rises. Success is silence, and silence competes badly for attention against the parts of the business that announce themselves.

A capability whose success is invisible is one no one looks at, and one no one looks at has no future tense. A Wardley map would place it, stubbornly, at the earliest and most artisanal stage of evolution — not because it is new, it is decades old, but because nothing has ever pushed it to mature. There is a simpler way to see the same thing. Ask to see the capability's roadmap. There usually isn't one. Not because nobody plans — the organization plans constantly — but because nobody yet believes there is a capability here to plan.

The signature, not a checklist

Set the six side by side and the point is that they are not a list. They are a signature. Each is what you would have predicted, in advance, from a capability that is orphaned, illegible, absorbed by capable people, improvised, locally rational, and silently valued. They co-occur because they share a cause, and that is what makes reading them diagnostic rather than anecdotal: you are not collecting complaints, you are matching a set of traces to the thing that leaves them. What has surprised us, returning to organization after organization, is not any single trace but how reliably they arrive together.

A caution here, firmer than the first paper needed. None of these traces is unique to an orphaned capability. Plenty of young functions, low-priority functions, or merely under-resourced ones will show one or two; a shared mailbox alone proves nothing. What distinguishes the specific condition described here is not any single trace but the combination together with a history: the work is neither new nor small, it has grown for years, and across all that time and growth it still has not matured — no owner, no measure, no design — the way the organization's sponsored capabilities reliably did. A young capability showing these signs is simply young. An old, growing one that still shows all of them is showing you something else. The traces are necessary evidence. They are not, alone, sufficient. Recognition is where a diagnosis starts, not where it ends.

We should be as clear about the standing of the evidence. The mechanism behind these traces is a hypothesis carried from Working Paper 0001. The traces themselves are a mix of direct observation and inference — patterns we have seen, and patterns the model predicts — and they are not a validated instrument; we have not scored organizations against them, established base rates, or tested them against a control. Treat it as a lens for looking, not a test that returns a verdict.

One level up: the observation that never travels

The six traces describe a capability orphaned inside an organization. Late in writing this, a seventh possibility appeared — one we have looked for less than the other six. If the internal capability is orphaned, what about the shared practice it depends on — the practice that has to hold across many organizations and many authorities at once? Does that have an owner?

The immediate answer is that of course it does; the structures are everywhere. Industry associations, standards committees, public–private partnerships, banking-sector working groups, joint task forces, steering groups. Anyone who has worked in this field will name three without pausing. So the recognition here cannot be that no one is talking to anyone. They plainly are.

The recognition is subtler, and it is the same mistake as the internal one, moved up a level. Inside an organization we saw work mistaken for a managed capability — the presence of activity read as the presence of ownership. Across an ecosystem, the parallel error is to read the presence of a forum as the presence of an operational capability to improve shared practice. These are not the same thing, and the difference is not a matter of effort or goodwill. A forum can be busy, well-run, and genuinely valuable and still not be the thing we mean.

It is the same trap as Recognition 2, one level up. A shared mailbox does not become an operating capability merely because work passes through it; a forum does not become a collaborative capability merely because organizations meet in it. And the two levels accumulate the same kind of residue. Line up what each collects and the rhyme is hard to miss. An organization accrues shared mailboxes, spreadsheets, tacit knowledge, a few indispensable people, a sediment of workarounds — and reads the pile as a capability. An ecosystem accrues committees, bilateral agreements, standards, conventions, working groups — and reads that pile as one too. In both cases the pile is real and useful. In neither is it, by itself, the thing.

So the diagnostic is not the one people reach for. It is not does a forum exist? — the answer is almost always yes. It is a harder question:

Make it concrete, because the concreteness is the test. A practitioner notices that a common request type is missing a field everyone ends up asking for anyway. Or that two authorities ask for the same thing in two different shapes. Or that a clarification step, repeated a thousand times a year, could disappear entirely if one convention changed. That is exactly the raw material of improvement — a small, true observation from the floor. Now follow it. Is there a path by which it becomes a shared proposal, then a discussion, then an agreement, then an implemented change, then something measured, then refined again? Or does it have nowhere to go — absorbed as a private workaround, or dispatched into a queue that surfaces, if at all, as an agenda item a year from now?

When the path does not exist, it is worth being precise about what is missing, because it is easy to blame the wrong thing. The forums are not failing at their job. Governance, standard-setting, and representation are real functions, and the bodies that perform them are usually doing so about as well as they were designed to. What is missing is a different function these structures were never built to provide: continuous operational learning — the fast, low-ceremony loop that modern engineering organizations rely on, in which many small observations become many small improvements without each having to clear a governance bar. A body optimized for consensus and a body optimized for rapid iteration are not the same body, and asking the first to be the second is a category error, not a failure.

There is a consortium point hiding in here, and it is worth surfacing because the earlier papers, ours included, slid past it. We have mostly described the work as though it were bilateral — a requester on one side, a responder on the other. In practice the challenge is consortium-wide: the same request type ought to look materially similar no matter which authority issues it or which organization receives it, and that similarity, where it exists at all, is a property of the whole ecosystem converging, not of any two parties agreeing. Bilateral fixes do not add up to a shared practice. The convergence is itself a capability, and it is the one we are suggesting may be absent.

This is the least-tested part of the guide. We have watched observations fail to travel; we have not measured how often, or how long the journey takes where it succeeds, or how cleanly an absent learning capability separates from a merely slow one. It is a question to carry into the next forum you sit in: not whether it exists, but whether an observation made in it a year ago has changed anything by now.

Why recognition is the point

A field guide is not there to be admired. It is there to change what you notice.

If the reasoning holds, the valuable outcome is not that a reader agrees with us. It is that a reader walks back into their own organization and sees something they had passed for years. The shared mailbox stops being furniture and becomes the uninstrumented operating system of a whole capability. Anna stops being merely helpful and becomes the visible edge of an undesigned system. The four questions no one can answer stop being an administrative gap and become the reason the capability cannot be steered. Nothing about any of them changed. Only whether they are seen.

That shift — from doing the work to seeing the capability — is the whole ambition of this paper. Recognition solves nothing by itself; it is only the moment a thing becomes available to be managed at all. But nothing can happen before it. And for work that has spent decades in the band that is visible enough to survive and not visible enough to improve, being seen may be the hardest step of all, because it asks you to find, in work you have always treated as incidental, a capability that was quietly there the whole time.

The reason no one had seen it is, in the end, the same reason no one had built it. It was never the core business.

What remains open. Three things. How cleanly these traces separate an orphaned capability from a merely neglected one — the "combination plus failure to mature" test above is our best attempt so far and may need sharpening. Whether recognition leads anywhere — whether seeing the capability makes an organization more likely to manage it, or simply more aware of a discomfort it then re-absorbs. And, newest and least tested, the missing ecosystem learning capability: we cannot yet tell a genuinely absent one from a merely slow one. If you have watched recognition lead somewhere, or nowhere — or an observation travel, or fail to — we would like to hear 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