Business runs on commitments
Not on tasks, and not on documents, and not on information. Every organisation is already a network of promises between people, made in language — asked for, agreed to, delivered, accepted. The tasks are what keeping them takes and the documents are what remembering them takes, and both are downstream of the promise.
The claim is Fernando Flores's and it is forty years old: an organisation runs on a network of commitments rather than being a machine that processes information. That second half is what it is arguing against, and it is worth keeping, because the machine is what almost every system ever built assumes. This is worth spelling out for the same reason: the layer everybody manages is usually the one underneath.
Most of them are never said out loud
The awkward part is that hardly any of these promises are made in the way the word suggests. A few are: a contract, a date given in a meeting, a written objective. The rest are assumed — the report that has always gone out on Fridays, the approval somebody has always given, the handover the other team believes is coming because it came last time. Nobody ever asked, nobody ever agreed, and the work happens anyway, which is what makes it so easy to believe there was an agreement there at all.
Unspoken agreements are not a failure of professionalism. They are how anybody gets through a week; a team that stated every one of them would never finish stating them. The trouble is that an assumption has no terms. Nobody said what would count as done, nobody was in a position to decline, and there is no moment at which somebody says yes, that was it — so when it goes wrong there is nothing to go back to, only two people who each remember a different arrangement.
That is why what breaks is so reliably the part nobody said. Drawing the work as commitments is not an argument for making everything explicit. It is a way of finding out which of the assumptions are load-bearing, so that the two or three worth saying out loud can be said out loud.
You were hired by a promise
Somebody described work that needed doing and asked whether you would do it. You said yes, and in saying yes you took on conditions you both understood: what the job is, what it pays, when it starts, what would count as doing it well. That is a commitment, made in language, between two people. The letter you signed is its record.
And it did not end there. Every objective agreed, every date given in a review, every "can you take this on" answered in a corridor is another loop opened and closed inside the first. Employment is not a state you are in. It is a promise that keeps being renewed, mostly without anybody noticing the renewals.
An offer in the market is a promise made to strangers
A price is a promise. A delivery date is a promise. A specification is a promise about what the thing will do, and a warranty is a promise about what happens when the first promise fails. A company that publishes any of these has made an offer — in the exact sense the notation means, a loop opened from the performer's side, waiting for somebody to accept.
Read a company that way and its departments stop being boxes on a chart. Marketing makes offers. Sales negotiates them, which is to say it does the work of the second moment: agreeing, countering, sometimes declining. Delivery performs. And support is the name for what a company does when a customer has not declared satisfaction — which is why support feels like failure to the people staffing it, and why it is the most honest signal a business has.
Every team is somebody's performer
Inside the walls it is the same shape with the parties renamed. A roadmap is a set of promises to people who are counting on them. A quarter's plan is a promise made in a room, by named people, to other named people. The agreement between a platform team and the teams on top of it is a standing offer with conditions of satisfaction, whether or not anybody wrote a service level into it.
Most of what feels wrong in an organisation, felt closely, is a malformed loop. Work nobody actually asked for. A promise made by somebody who could not have declined it. Work delivered and never reported, so the person waiting is still waiting. Work reported and never accepted, so nobody knows whether it answered the question. None of these are effort problems, and none of them are visible on a board of tasks.
Documents are in support
A contract is not a commitment. It is the record of one, written down because memory is short and because a promise between organisations has to outlive the people who made it. The same is true all the way down: the purchase order, the invoice, the specification, the ticket, the meeting note, the signed-off design. Each of them records, instructs, or evidences a promise. None of them is a promise.
The distinction is not academic. A contract nobody intends to perform is paper. A promise made in a corridor and kept is a commitment with no document at all. When the artefact gets mistaken for the thing it records, an organisation starts producing artefacts and calling it coordination — sign-off becomes the goal, the document is complete, and nothing has been asked of anybody in particular.
Data is the same story in smaller pieces. A status field is a claim about which moment a promise has reached. A due date is a condition of satisfaction with the words taken out. A dashboard is an attempt to see, in aggregate, whether promises are being kept — which is why dashboards feel thin: they are the shadow of the commitments, and the commitments were never written down.
Systems are a layer below
Every tool in the building sits underneath this. A CRM records requests and offers. A ticketing system tracks performance. An ERP keeps the paper straight. Workflow engines route work to queues, and they are genuinely useful — but none of them can make a request, agree to one, or be the person who says this is what I needed. That line, and what it means for anybody designing software, is the subject of what it does to software.
Work is in the future
Every promise is about something that has not happened yet. That is what makes it a promise rather than a report — and it is also why none of it can be predicted. You cannot make an assertion about next Thursday. You can only commit to it, and be held to that.
So a plan is not a description of the future. It is a set of promises, and it holds or fails on whether the people in it can keep them.
What you steer by in between is assessments. Whether the date is still good. Whether the person who agreed still believes it. Whether what would count as done has quietly moved. These are judgements rather than facts — grounded or ungrounded — and making good ones is not a nicety. The alternative is finding out at the handover.
They also go stale. An assessment made in March was grounded in March. Reviewing it is not second-guessing anybody: it is how a promise made months ago stays one somebody would still make today.
What follows from it
If you cannot see the commitments, you will manage the layer you can see, and wonder why the improvements do not add up. So draw the promises first — who asked whom, what would count as done, and where it comes apart. Then ask of each document: which promise does this serve? And of each system: which moment of which loop does it carry?
Most answers are useful. Some are uncomfortable: a form nobody reads, a report nobody acts on, an approval step no person is behind. Those are not inefficiencies. They are places where the organisation is keeping the record of a commitment that nobody is actually making.
Where the distinction comes from, and the objection worth taking seriously, is in Language is how commitments get made.
The fastest way to see whether any of this holds is to look at one drawn: run the example network and watch a single promise go round, from the asking to somebody saying yes, that was it. Run it before anybody lives in it is what that shows, and why it is worth doing before the work is built rather than after it breaks.