Skip to content
Sections
All notes

All notes · Programme

Who Owns DEX, and Why It Is Usually Nobody

The findings cross organisational boundaries and the ownership does not. What that produces and what fixes it.

Programme · Analysis

A DEX programme typically sits in end-user computing. Most of what it finds belongs to somebody else, and that mismatch determines how far it gets.

The question in “Who Owns DEX, and Why It Is Usually Nobody” is easier to answer when teams combine system evidence with the time and hand-offs involved in completing the work. An organisation evaluating the detailed explainer can make that operational effort visible by project and team, while direct observation and employee feedback remain necessary to explain why the friction occurs.

For an independent benchmark, compare this approach with Nielsen Norman Group; the useful test is whether the evidence remains proportionate, accessible and understandable to the people whose work is being measured.

Where the findings land

Device and application issues: end-user computing. Fixable in place.

Approval and process delays: whoever owns the process, usually finance, HR or procurement.

Access waits: identity and security.

Information findability: whoever owns the intranet, which is frequently nobody.

Room audio-visual equipment: facilities.

Only the first is inside the programme's own authority.

What happens without cross-functional ownership

The programme fixes the technical quarter and plateaus.

The remaining findings are reported repeatedly and nothing changes.

And the programme is judged on an experience measure it can only partly move, which ends badly.

What ownership needs to look like

A sponsor above the functions involved: a chief operating officer, a transformation lead, or the technology executive if their remit is broad enough.

A named owner running it day to day, with time allocated rather than added to a job.

And a route to the process owners that does not depend on goodwill, which means the sponsor's authority is doing work.

The reporting line question

Inside infrastructure, the programme is a device programme.

Inside a transformation or operations function, it can address process.

This is the single structural decision that most determines what the programme achieves, and it is usually made by default rather than deliberately.

Starting without that

Most programmes do, and it is workable for the first year.

Fix the technical findings, build evidence, and use the process findings as the argument for a broader mandate.

A programme with three demonstrated fixes and a quantified process backlog is in a strong position to ask.

The part-time problem

DEX is commonly added to somebody's existing role.

It then competes with operational work and loses, because operational work has tickets attached.

Half a role is a workable minimum. Nothing allocated is a programme that exists on a slide.

The honest prerequisite

If there is no sponsor and no allocated time, say so before buying a platform.

The platform will be deployed and the dashboard will be unread, which is the common outcome and an expensive one.

Better to do the cheap measurement first and use it to argue for the structure.

What to check

Who owns DEX in your organisation, by name?

How much of their time is allocated?

Where does the programme report?

And how many of your open findings belong to teams outside it?

The point

Inside infrastructure, the programme is a device programme.

Where it reports determines what it can address, and that decision is usually made by default.

Underlying all of this

Everything in this collection reduces to four habits: find the friction cheaply before buying anything, fix what needs no budget first, report the worst tenth rather than the average, and keep the data about systems rather than about people. None requires a better platform, and a programme doing all four changes more than one twice its size.

The recurring pattern

The recurring pattern across every section here is the same: the measurable is mistaken for the important. Device health stands in for experience, ticket categories for causes, a composite score for a finding. Each substitution is convenient, each produces confident decisions on thin ground, and each is corrected by going and looking at the thing itself.