Operating for return: adoption, the business number, the next brief
We operate what we build with the telemetry we built in: adoption and the business number, watched weekly and reported until they move. What people use, and what they route around, writes the next turn of the loop.
What we watch, week by week
- Who uses it, and who stopped.
- Where the workarounds are.
- Whether the number has moved.
Where this fits
A new problem starts the loop. What you learn running the software feeds the next turn.
Why the return on software is decided after go-live
Everything before go-live is cost. The return, the settled claim, the shipped order, the signed contract, happens while the software is operated, or it doesn't happen. Yet this is the stage most engagements treat as an afterthought: the build team disperses, the context leaves with it, and the software is handed to people who are meeting it for the first time.
Operating well means knowing, week by week, whether people use the thing, where they route around it, and whether the metric the whole engagement was priced on has moved. Uptime is table stakes; it isn't the number.
Why software that acts needs supervision, not just monitoring
Monitoring was built for software that records: is it up, is it fast, did it error. Software that acts raises a different question: is it doing the right things, within the bounds we set, and how would we know? That's supervision, and it only works when every action passes through one gateway where it can be seen, governed and replayed.
The other change: the map has to stay true. Agents are only as smart as the map they're given, and a map that drifts from reality makes them confidently wrong. Keeping the process model current is now an operating duty, as routine as patching.
We operate on two questions
01
Functionally: is it working for the business?
Customer behaviour, read from telemetry and heard anecdotally. What people use, avoid and route around decides how the UX, the features and the processes improve.
02
Non-functionally: is it holding?
Performance and bugs, found and fixed proactively — the degradation is caught by us before anyone files a ticket, not reported by your users.
The weekly routine that answers them:
01 · Watch adoption, not just uptime
Who uses it, who stopped, where the workarounds are. A green dashboard over an unused system is the most expensive kind of healthy.
02 · Report against the number
The metric from Strategize, its movement, and what's blocking it, on a standing cadence, to the person who owns it. You see where things stand the day it happens, not in a Friday summary.
03 · Keep the builders close
The people and agents who built the software fix and extend it. Context stays next to the code, in the map, so a change request doesn't start with archaeology.
04 · Let use write the backlog
What's adopted gets deepened, what's routed around gets rethought, what's ignored gets retired. Ranked by expected movement in the number, that list is the next turn's brief.
The steering call: one standing hour that runs the loop
Operating is not a dashboard you are given a login for. It is a standing call with the people and agents who built the software, where the week's numbers are read, the gaps are named, and what gets built or improved next is decided while the context is still warm.
The report
01The number, read
The steering call opens on the KPI report: the metric from Strategize against its baseline, functional and non-functional, no anecdotes.
YouEngineerYou hold: the scoreboard, current to the week
The reading
02The gaps, named
Who uses it, who stopped, and where people route around it. Workarounds are treated as findings, not complaints.
EngineerYou hold: the adoption picture, honestly told
The decision
03Deepen, rethink, or retire
Each candidate move is ranked by its expected movement in the number. You make the call; the reasoning is recorded with it.
YouEngineerYou hold: the ranked next moves, with reasons
The next turn
04The loop, fed
Decisions become Blueprint revisions and tasks before the call ends. Nothing waits for a quarterly review to become work.
StrategistDamco agentYou hold: the next turn's brief, already moving
One standing call, every week — how the software is doing, and what that decides.
What the weekly reports carry
Home shows these artifacts cycling; this is what they hold. The functional number against its target, the platform stated in words rather than colours, and the ranked list that becomes the next turn's brief.
KPI · functional
weekly · wk 12
Adoption, against target
issued to the person who owns the number
KPI · non-functional
weekly · wk 12
the platform holding, in words not colours
The ranked next moves
written by use
the next Strategize starts from this list
The four deliverables Operate hands back to Strategize
This is where the loop closes: two of the four rows are consumed by the next turn.
| Deliverable | What it is | Who takes it up |
|---|---|---|
| The number, reported | The metric against its baseline, on a standing cadence. The engagement's scoreboard. | You; and our case studies, once it's earned |
| The ranked next moves | The use-written backlog: deepen, rethink, retire, ordered by expected movement in the number. | The next Strategize starts here |
| The Blueprint, revision up | The plan updated to what stands and what's proposed next. The revision number is the point. | The next turn of the loop |
| The map, kept true | The process model, current with reality. It makes every turn cheaper and every agent smarter. | Everything that follows |
The destination: self-improving enterprise software
The end state we operate toward is software that does not wait for a change request. The telemetry is laid in to signal whether the software is being used the way it was intended — and when it is not, the gap becomes a proposed enhancement instead of a slow-burning complaint. Two parts of this are genuinely hard, and they are where the work is:
01
What telemetry to lay in
Choosing the signals is design work, done at build time. Every workflow ships with events that reveal intent: what was started and abandoned, what was exported to a spreadsheet instead of finished in the system, where the workaround begins. Uptime tells you none of this.
02
How to interpret what it says
Signals do not rank themselves. The readings have to become a prioritized list of enhancements and suggestions, each ordered by its expected movement in the business number — not by who complained loudest.
AI agents work both stages: they watch the telemetry for the pattern breaks, draft what the readings mean, and propose the enhancement candidates with the evidence attached. People judge that list on the steering call, and the accepted rows enter the factory as tasks. The same system that built the software keeps improving it — which is what the factory means when it promises that the system builds itself. The full mechanism: self-improving software →
How Damco runs the operate stage
Telemetry is flowing when Operate begins, because Build shipped it as a deliverable. Day one starts with eyes open, not with an instrumentation project.
The team that operates is the team that built: the same people, the same agents, the same map. And the arrangement is yours to choose. Operate it with us, or take it and fly.We set up the human plus AI system so you don't have to invest in building it; if you take it in-house, the handover includes the system itself: telemetry, runbook, map and tooling.
Who's watching your number after go-live?