The Decisionless Stack

A delivery director I can picture clearly, though she is a composite of a dozen real ones, spent a Thursday afternoon trying to answer a single question: why had the firm agreed to run a client programme at a price that, eighteen months on, was plainly losing money.

She was thorough. She started in the CRM, because that is where deals live. The record was all there: the account, the contacts, the opportunity, the stages it had passed through, the close date, the signed value. What the CRM did not tell her was why the number was the number. She moved to the finance system and found the invoices, the revenue recognised, the costs booked against the programme, the margin sliding quietly from healthy to thin to red. The finance system knew exactly how much money had been lost. It had no opinion on why anyone had thought the price was a good idea.

She tried the project tool. Tasks, milestones, a burndown, a list of who had touched what and when. She tried the resourcing system and saw who had been staffed, at what grade, for how many hours. She opened her inbox and searched for the client's name, then searched the chat tool, and found four hundred messages, a handful of which were clearly about the pricing, none of which was the decision.

By the end of the afternoon she had reconstructed almost everything about the programme except the one thing she had come to find. She knew what had been sold, what had been staffed, what had been delivered, what had been billed, and what had been lost. She did not know why the firm had decided to sell it that way, who had made the call, what they had weighed, what they had rejected, or what they had been afraid of. That knowledge had lived in the head of a sales lead who had since left, and in a meeting eighteen months ago that nobody had minuted.

She had nine systems. Not one of them held the decision.

The question the software cannot answer

There is a particular kind of frustration that everyone who has run a people business knows, and almost nobody has a name for. It is the frustration of a firm that can tell you everything about what it did and nothing about why it decided to.

Ask your systems what happened and they will bury you in answer. Ask them why it was chosen, and they go quiet.

We tend to blame this on discipline. If only people wrote things down. And discipline is part of it. But if the problem were only discipline, thirty years of process improvement would have fixed it, and it has not, not anywhere, not in the best-run firms in the world. The problem is deeper than habit. It is architectural. The systems we bought to run our businesses were never designed to hold a decision in the first place. They were designed to hold something else, and they hold it superbly, and the decision was simply never in scope.

This chapter is about that absence and where it comes from. It is not an attack on enterprise software, which has earned its place and does extraordinary work. It is an attempt to say, precisely and fairly, what that software was built to do, what it was never built to do, and why the difference is the most expensive blind spot in the modern firm. The name for the whole estate, seen through this lens, is the one this book will use from here on: the decisionless stack.

A tour of the estate

Walk the stack honestly, system by system, and a pattern appears that is hard to unsee. Each system was built around a noun. And each does it well.

The CRM was built around the customer and the sales pipeline: who the account is, who the contacts are, which deals are open, what stage they sit in, what they are worth, when they might close. What it records is the state of a deal. What it does not record is the reasoning inside the deal: why this opportunity was pursued and that one dropped, why the discount was given, why the firm believed it could win. The stage moved from "proposal" to "closed won." The judgement that moved it is nowhere on the record.

The ERP grew out of the need to record transactions and coordinate resources: orders, inventory, purchasing, the operational backbone of a company that makes and moves things. It is a masterpiece of recording, every transaction and movement captured and reconciled. But an ERP records that a resource was allocated, not why that allocation was the right call over the three others available. It holds the transaction, not the trade-off behind it.

The finance system records money: the ledger, the invoices, the costs, the revenue, the margin. It is the most trusted record in the building, because money is the one thing a business is legally obliged to account for precisely. And it is the purest example of the whole problem. It tells you, to the penny, what a decision cost, and nothing about the decision. It is the scoreboard, not the game.

The HRIS records people: who is employed, in what role, at what grade, at what cost, since when. It knows that someone was promoted, hired, or moved. It does not know why one candidate was chosen over another, why a team was restructured, why a good performer was allowed to leave. The people are recorded. The decisions about the people are not.

The ATS records candidates: applications, stages, interviews, offers, tracking a person through a pipeline the way the CRM tracks a deal. It captures that a candidate was rejected at the second stage. The judgement that rejected them, the specific read on fit or risk or timing, survives, if at all, in a one-line note or a conversation nobody kept.

The service desk and ticketing systems record issues: raised, categorised, assigned, escalated, resolved, closed. This is decision-adjacent territory, closer to the action than most, and still it holds the wrong half. It records that a ticket was escalated at 14:12. It does not record why the person on the desk judged that this one, out of the forty in the queue, was the one that would hurt the client if it slipped. The escalation is a timestamp. The judgement behind it evaporates.

The project and task tools record work items: tasks, owners, statuses, dependencies, dates. They will tell you that a task slipped, that a milestone moved, that scope was added. They will not tell you why the team decided to absorb the extra scope rather than raise a change request, a small, local, unrecorded decision that, multiplied across an engagement, is often the whole difference between a profitable programme and a loss.

The communication tools, email and chat and the meeting itself, record conversation. This is where people always point when you say the decisions are missing. "It is all in the thread," they say, and it is true that the decision often passes through the thread. But a conversation is not a decision, any more than a transcript of a trial is a verdict. The thread holds the debate, the tangents, the person who went quiet, the "let's discuss offline" after which the actual choice was made in a corridor. Somewhere in four hundred messages is the moment it was decided. Good luck finding it in eighteen months, and good luck proving that what you found was the decision and not just the loudest opinion near it.

And the BI system and the data warehouse record history. They pull the records from all the others into one place and turn them into reports, dashboards, trends. This is the system most people believe solves the problem. For now, note only what it is: an aggregation of records. A very good one. Still a record.

That is nine systems. Between them they cost a mid-sized firm a serious fraction of its overhead, and between them they can reconstruct, in forensic detail, almost everything the firm has done.

And the decision, the actual moment of judgement, "we chose to staff it this way, to price it that way, to escalate here, to walk away there, to give this client one more chance," lives in none of them. It lives in someone's head, in a chat thread, in a meeting nobody minuted.

Nine systems of record, and not one of them a system of record for the decision.

The whole estate, and the hole in the middle of it, fits on a single page.

Everything above the line is bought, installed, and maintained at great expense. Everything below it is the business, and it is kept nowhere.

Nouns, not verbs

Why should this be? It is not an accident, and it is not incompetence. It is a consequence of what computers were originally good at and what we therefore asked them to do.

Enterprise software was born to record. The first business computers replaced the ledger and the filing cabinet, and a ledger is a record of things: accounts, balances, transactions. The organising unit of all the software that followed was the same, the record, or in the language of the systems themselves, the entity: a row in a table, with a set of fields, standing for a thing in the world. A customer is an entity. An invoice is an entity. An employee, a candidate, a ticket, a task, a resource, all entities, all rows, all nouns.

This was the right thing to build, and it was built for a good reason. A record is cheap to store, easy to standardise, and simple to reason about. A customer has a name, an address, a status. You can put those in fields. The entire discipline of the relational database, which is the foundation under almost every system named above, is a discipline for storing nouns and the fixed relationships between them. It is a triumph of engineering, and it made the modern enterprise possible.

But a decision is not a noun. A decision is a verb. It is an act of judgement performed by a person at a moment in time, weighing things that are often not in any system, choosing among alternatives that mostly leave no trace, for reasons that live in the head of the person choosing. You cannot easily put a verb in a field. Where would the alternatives go, the ones considered and rejected? In what column does the reasoning sit? Which table holds the thing the decider was worried about but could not prove? The relational model, so good at nouns, has no natural home for any of it. Enterprise software stores nouns. Businesses compete on verbs.

Enterprise software stores nouns. Businesses compete on verbs.

So the industry did the sensible thing. It built around the nouns, which it could store cheaply and precisely, and it left the decisions to the humans, which is to say it left them nowhere. The decision was treated as the messy, unstructured, ephemeral residue of the process, the part that happened in the room and did not need to be kept, because what mattered, surely, was the outcome, and the outcome was a record. The record was the point. The judgement that produced it was assumed to be human overhead, real but unstorable, like the sound of the meeting.

Underneath this there is a second, quieter assumption, and it is the one that has aged worst. Enterprise software was built around transactions, not judgement. A transaction is a settled fact: it happened, it is done, it can be recorded and reconciled. Judgement is unsettled: it is a bet on the future made under uncertainty, and it is only ever provisionally right. Software that records transactions is recording the past, which is safe and knowable. Software that would record judgement has to hold something harder: a claim about what someone believed at the time, why they believed it, and what they chose to do about it. That is a fundamentally different kind of object, and for most of the history of enterprise computing there was neither the storage, nor the interfaces, nor, frankly, the imagination to build for it. So we did not.

The result is a stack that is exhaustively good at the settled and structurally blind to the unsettled.

The record and the decision

Here is the distinction the rest of this book turns on, stated as plainly as it can be. There is a difference between the record and the decision, and the entire enterprise stack is built on one side of it.

A record is the trace a thing leaves in a system. The client exists, so there is a client record. The invoice was raised, so there is an invoice record. A record answers the question what. What is the state of this thing, now and over time.

A decision is something else entirely. A decision is a choice made by an owner, at a moment, on the basis of evidence, among alternatives, in service of an intent, and with a consequence that arrives later. A decision answers the question why. Why did we choose this and not that. And a decision has parts a record does not: an owner (who decided), a rationale (on what grounds), a set of alternatives (what else was on the table), and eventually an outcome (whether it turned out to be right). None of those parts has a home in a system built to store the state of a thing.

Put the two side by side and the gap is obvious. The finance system holds the record that a programme lost two hundred thousand pounds. The decision that led there, "we will hold the price to keep the logo, and absorb the risk because we believe the renewal will more than repay it," is not a smaller version of that record or a softer one. It is a different species of information. It was true, as a statement of intent, at the moment it was made, in a way the eventual loss cannot retroactively erase. The loss is what happened. The decision is what we chose. A system that captures only the first can reconstruct the history of the firm and never once explain it.

A warehouse full of what happened is not a memory of what we decided.

The thing every leader actually needs, and cannot get, is a memory of what we decided, and why, and by whom, and against what alternatives, so that the next time a similar choice arrives, the firm is not starting from nothing.

The notes field is not the decision

At this point a fair objection arrives, because it is the fix every firm reaches for first. "Our systems do have somewhere to put the reasoning," people say. "There is a notes field on the opportunity. There is a comment box on the ticket. We can type the why right there, next to the what." And they are right that the field exists. It is why the field so rarely works that matters.

Look at what that field actually is. It is a patch of free text bolted to the side of a record, optional, unstructured, and unconnected to anything. Because it is optional, it is usually empty, or filled in after the fact by whoever remembers to, which is nobody in the week a deal is closing. Because it is unstructured, it holds a conclusion and almost never the reasoning: "agreed to hold price," not the three alternatives weighed and the fear that drove the choice. Because it is unconnected, it sits beside the state of the deal but has no link to the outcome that will arrive eighteen months later, so even a diligent note can never be compared against what actually happened. And because it is an afterthought in a system built around the noun, it is the first thing to rot: it ages, it contradicts the later record, and no one trusts it enough to read it.

The notes field is the stack's confession. It is the industry half-admitting that the decision matters, and handing you a blank box and no help. A place to type the reason is not a system for capturing decisions, any more than a margin scribbled in a ledger is a system of accounts. The reasoning deserves the same rigour the transaction gets, and in the decisionless stack it gets a text box and a shrug.

What the absence costs

It is tempting to treat this as a philosophical nicety. It is not. The absence of the decision from the stack has a precise and compounding cost, and once you see the mechanism you see it everywhere.

The cost is this: an organisation that records only its records can reconstruct what it did but cannot learn from why it did it, and so every decision is made fresh, from a standing start, as if the firm had never faced anything like it before.

Consider how learning is supposed to work. You make a call. Time passes. The outcome arrives. You compare the outcome to what you expected, and if there is a gap, you look at the reasoning that produced the call and you adjust it. Next time, you decide a little better. That loop, decision to outcome to revised judgement, is how any system, human or organisational, gets smarter. It is the whole of experience.

Now notice what the loop requires. It requires that the decision, and its reasoning, still exist when the outcome arrives, so the two can be compared. And that is exactly the thing the stack does not keep. The outcome is beautifully recorded, in finance, in the warehouse, in the churn report. The decision that produced it is gone, evaporated into a departed colleague and an unminuted meeting. When the firm goes to learn, it finds it has the answer to the exam but not the working, and you cannot mark working you do not have. So the lesson is not learnt. The margin leaks the same way it leaked last year. The pricing mistake is repeated by someone who never knew it was a mistake, because the record of the loss never carried the record of the choice.

This is why firms with decades of experience so often behave as if they have none. It is not that their people are not clever, or that they do not, individually, remember. It is that the memory lives in people, and people move on, and the systems that were meant to be the institutional memory kept everything except the part worth remembering. A firm can have twenty years of records and no accumulated judgement at all. It knows what it has always done. It has no idea what it has learnt.

This bites hardest in a particular kind of company, and it is the kind this book is written for. In a firm that makes a product, the decisions are important, but they are not the product; the product is the thing on the shelf, and the record of the thing is a reasonable proxy for the value created. In a people business, an agency, a consultancy, a professional services firm, a staffing company, a contact centre, the decisions are the product. What the firm sells is judgement: who to put on the work, how to price the risk, when to escalate, which client to fight for and which to let go. Which means that when the decisions go uncaptured, it is not a supporting document that goes missing. It is the intellectual property itself, the actual thing of value the firm produces, leaking out of the building unrecorded, every day. A manufacturer that lost its inventory records would call it a crisis. A people business loses the record of its judgement continuously and calls it Tuesday.

There is a second cost, subtler and just as real. When decisions are invisible, they cannot be reviewed, and what cannot be reviewed cannot be governed or trusted. A leader who cannot see the decisions being made below them is left managing by proxy: watching the records, the dashboards, the lagging outcomes, and inferring backwards to a set of choices they never saw and cannot examine. This is why so many capable executives run their firms with a permanent low-grade anxiety. They are accountable for a machine whose most important moving parts, the judgements, are the one thing their instruments do not show them. They have a dashboard and a bad feeling, and no way to close the distance between the two.

"That is what BI and the warehouse are for"

The strongest objection to all of this comes quickly, and it comes from the smartest people in the room. "You are describing a solved problem. Fragmented systems, scattered records, no single view, that is precisely what business intelligence, the data warehouse, and the modern data stack were built to fix. We pipe every system into one place, we model it, we report on it, we put it in front of the leadership. The single source of truth exists. We bought it."

This deserves a serious answer, because the objection is half right, and the half it gets right is important. The modern data stack is a genuine achievement. Pulling the records out of nine systems and reconciling them into one coherent, queryable place is hard, valuable work, and a firm that has done it is meaningfully better off than one that has not. If the problem were fragmentation of records, the warehouse would indeed be the cure.

But look closely at what the warehouse actually contains, and the answer becomes clear. It contains records. It is, by construction, an aggregation of the same nouns the source systems were built around: customers, transactions, tickets, tasks, people, money, rolled up, joined, and trended. A data warehouse is the decisionless stack assembled in one building. It consolidates everything except the missing layer, and consolidates it so impressively that the absence becomes harder to notice, not easier.

Ask the warehouse the questions that matter and watch it fall silent. It will tell you, brilliantly, that margin on this client segment fell four points last quarter. It cannot tell you which decisions caused the fall, who made them, what those people were weighing, or what alternatives they turned down. It answers what happened with more power and precision than any technology before it, and it remains, structurally, mute on why we chose.

That is the trap in the phrase "single source of truth." A warehouse is a single source of record, and a firm that mistakes the two will spend heavily to build a perfect memory of its own actions and remain, at the level of judgement, an amnesiac. The decision layer the firm actually needs was never one of the nine systems, so gathering the nine systems together, however elegantly, cannot produce it.

None of which is a reason to tear out the warehouse. The record is worth having; this book is not against records. It is a reason to stop expecting the record to do the decision's job, and to notice that the most important layer of the business has, all this time, been missing from the estate we assumed was complete.

The bridge

So the stack records everything except the decision. That is the first fault, and on its own it would merely be a gap. What makes it dangerous is what the gap does over time.

A firm that never captures its decisions cannot keep them. And a firm that cannot keep its decisions cannot remember them, which means it cannot learn from them, which means it is condemned to make them again, from scratch, forever. The missing record does not just leave a hole in the present. It erases the past. The salesperson who knew why the deal was priced that way leaves, and the reason leaves with her. The delivery team inherits a contract and no context. The hard-won lesson of a bad year is unavailable to the person who needs it the next year, because it was never anywhere but in a mind that has moved on.

That is not a filing problem. It is a memory problem, and it afflicts the whole organisation. It is the subject of the next chapter.