The Trade-Off Matrix, Without Fake Precision
A matrix of options against axes is useful for seeing which axis the argument is really about — and dangerous the moment the numbers are added up. Monolith against microservices on simplicity, scale and operational cost, scored as positions rather than measurements, with the caveat the numbers cannot contain.
The situation, the reflex, and why it stalls
Every lesson starts where being stuck starts: someone has a problem, and the first move that comes to mind feels like progress.
A trade-off matrix looks like rigour — when does it actually help, and how do you use one without letting made-up numbers make the decision?
A stakeholder wants "a proper comparison" of building the store as a monolith or as microservices, with numbers. You could produce a table in an hour, and you are uneasy: you know the numbers would be invented, and you know that once they are in a spreadsheet they will be summed.
Produce the table. Seven axes, three options, a score in every cell, a weighted total at the bottom — it is what was asked for, it looks decisive, and the totals will settle the argument in a way an essay would not.
The totals settle the argument for the wrong reason. A 21 against a 19 is a two-point difference made of seven guesses, and nobody can say which guess the decision actually rested on.
- The totals settle the argument for the wrong reason. A 21 against a 19 is a two-point difference made of seven guesses, and nobody can say which guess the decision actually rested on.
- The weights are chosen after the scores, consciously or not, until the total agrees with the author's prior. The matrix is then an argument dressed as a measurement.
- The stakeholder reads the table as data. "Microservices scored 4 on scale" becomes a fact in a slide deck, detached from the caveat that the store has no measured load at all.
- The axis the decision is really about — what this team can operate — is one row among seven, and the six others outvote it.
The move
Precisely enough to apply it to a problem you have never seen — not a slogan.
- Use the matrix for the one thing it is good at: showing which axes the options actually differ on, so the argument can be narrowed to those. Fill it with relative positions — "noticeably better", "about the same", "noticeably worse" — and never with numbers that look like measurements of anything. If a cell can be measured, measure it and cite the measurement; if it cannot, do not give it more decimal places than "better here".
- Never sum a row or a column. A total implies the axes are commensurable and equally weighted, and they are neither: for a team of three with no operations experience, one point of operational cost outweighs any number of points of theoretical scale.
- Attach the caveat as part of the device, not as a footnote: what the numbers cannot say, which axis the requirements weight, and what evidence would change a cell. A matrix without a caveat is a claim that the decision has been computed.
- Read the matrix for the axis that carries the decision, then argue about that axis with evidence — a measured load, a headcount, a deployment history — rather than about the matrix.
Monolith, modular monolith, microservices — as positions
The matrix, on the three axes where the options differ. The scale is coarse on purpose; the notes carry the meaning; the caveat says which row the decision rests on and what would change it.
Notice the scale row. Microservices score highest there, and the caveat says the row is a prediction at this store — which is why it does not carry the decision.
| Option | Simplicity | Cost | Performance | Maintainability | Note |
|---|---|---|---|---|---|
| Monolith | One codebase, one deploy, database transactions across the whole store. Module boundaries exist only by convention, and erode. | ||||
| Modular monolith | One deploy, enforced module boundaries (catalog, cart, checkout, orders, payments). Can be split along those lines later; costs discipline now. | ||||
| Microservices | A service per capability; independent deploy and scale. A network where a function call was; a saga where a transaction was; tracing, discovery and a deploy pipeline per service. |
caveat Positions, not measurements; do not sum them. "Cost" here means operational cost — what it takes to run and deploy — and it is the row the decision rests on for a small team with no operations experience. "Performance" scores the ability to scale one part independently and is a prediction: this store has no measured bottleneck, so the row is hypothetical until one exists. A team with a platform group and a measured hot module would keep the same table and choose differently.
The same table, with and without fake precision
Two presentations of the same comparison. The first is what the stakeholder asked for and what most matrices become; the second is what the matrix can honestly say.
Monolith 31.5, modular monolith 33.0, microservices 28.5 (weights: simplicity 1.5, scale 2.0, ops 1.0). Recommendation: modular monolith.
The options differ on simplicity, operational cost and independent scale. For a three-person team with no operations experience and no measured load, operational cost decides: one deployable. Modular monolith, paying boundary discipline, for a system this team can run — until a measured bottleneck in one module justifies extracting it.
The total hides that the weights were chosen after the scores and that "scale 2.0" weights a hypothetical; the sentence exposes the row the decision rests on, the evidence it lacks, and the condition under which it flips. The stakeholder can argue with the sentence; nobody can argue with 33.0.
From "which architecture?" to a question with evidence
The stakeholder's request, climbed. The vague form asks for a winner; the better form asks for the axes; the best form asks for the one piece of evidence the decision rests on and does not have.
why The best form is answered by evidence we can check (headcount, load measurements, none) and produces a decision with a reversal condition. The vague form produces opinions; the better form produces a matrix that still needs someone to say which row matters.
How to do it
Most important first.
- Choose the axes the options actually differ on, from Trade-Off Dimensions; leave the rest out rather than scoring them the same.
- Score as positions on a coarse scale, and write a note per option saying what the position means in your system's nouns. The note is the content; the score is an index into it.
- Write the caveat before the scores. If you cannot say what the numbers cannot say, you do not yet know what they can.
- Find the axis whose row would flip the decision if it changed, and go and get evidence for that row alone (Questions That Reduce Uncertainty).
- Present the matrix with the caveat on the same page, and refuse the request for a total. Offer the sentence instead: "we take X, paying A, for B, until C."
Worked on a concrete problem
The move has to produce something. This is what it produced.
- The store, three options: a monolith, a modular monolith (one deployable, enforced module boundaries), and microservices. Axes on which they differ: simplicity, operational cost, and the ability to scale parts independently. Axes on which they do not differ enough to score: security (all three need the same checkout protections), and — at a store with no measured load — performance.
- Positions, not measurements. Simplicity: monolith best, modular monolith close, microservices clearly worse (a network between every module, and a distributed transaction where a database transaction used to be). Operational cost: monolith and modular monolith cheap (one thing to deploy, one to watch); microservices expensive (deployment per service, service discovery, tracing across them). Independent scale: microservices best, but with no measured bottleneck the row is scoring a hypothetical; the modular monolith can be split along its module lines later, which is the honest answer to "what if we need it?".
- The caveat that decides it: the team is three people with no operations experience and no load measurements, so the operational-cost row carries the decision on its own, and the scale row is a prediction with nothing behind it. The sentence: "we build a modular monolith, paying some discipline at module boundaries, for one deployable a small team can run — until a measured bottleneck in one module justifies extracting it." No total appears, and the stakeholder gets the reason instead of a number.
How you know it worked
What now exists that did not before, and what question you can now ask.
- The matrix has no total, and nobody has asked for one after reading the caveat.
- Each cell has a note in your system's nouns that says what the position means.
- You can name the one row the decision rests on, and you have gone to get evidence for that row.
- The decision is presented as a sentence with a reversal condition, and the matrix as the thing that found the row.
The questions you can now ask
The field this whole domain exists for. After this lesson, these are the questions to put to an unfamiliar problem.
- ?On which axes do the options actually differ — and which axes am I tempted to score only because they are on the list?
- ?Which cell could be measured rather than guessed, and have I measured it?
- ?Which single row, if it changed, would flip the decision — and what evidence do I have for it?
- ?What is the sentence with the reversal condition, and can I present that instead of a total?
What can go wrong
- Precision creep. A coarse scale becomes 1–10, then decimals, then a weighted sum "just to see", and the matrix that was meant to find the axis is now making the decision.
- Scoring hypotheticals as facts. "Scale: microservices 5" at a store with no load measurement is a guess about a future; the honest score is "unknown, and here is the experiment".
- A matrix for a decision that has one axis. If the options differ only on operational cost, the matrix is a one-row table and the effort of building it was the failure.
- The caveat as a disclaimer. Written last, in small type, saying "these are estimates". The caveat has to say which axis carries the decision and what evidence would change it, or it is a legal notice.
- A matrix without numbers or totals is less persuasive to a stakeholder who asked for numbers; you spend credibility to avoid spending honesty, and sometimes the stakeholder chooses the person who brought a spreadsheet.
- Coarse positions cannot rank options that are close on every axis — and a decision between options that are close on every axis is one where the matrix was never the right tool; a coin and a note may be.
- Measuring the one cell that can be measured takes longer than guessing all of them.
- "Never use numbers." Use measured numbers wherever they exist, cite them, and give the cell the precision of the measurement. The prohibition is on invented numbers dressed as measurements, and on sums.
- "The matrix decided on the modular monolith." The caveat did: a three-person team with no operations experience. A different team — with a platform group and a measured hot module — would keep the same matrix and take a different row.
- "Microservices are the wrong answer." They are the wrong answer *before a bottleneck exists* and for a team that cannot operate them; the scale row is real, and the modular monolith is chosen partly because it keeps the microservices option open (Add Complexity Only When Required).
Where this applies
Problem-solving advice is stated as universal far more often than it is. These labels say what each method is specific to — and where CONTESTED appears, the note gives the strongest form of the opposing view.
- GENERALPositions rather than measurements, no totals, and a caveat that names the deciding row — the discipline applies to any comparison table, from architectures to libraries to candidate algorithms.
- CONTESTEDThe strongest opposing view: weighted scoring models, used honestly, force a team to state its weights *before* scoring and make disagreement legible — "you weight operations at 3 and I weight it at 1, and that is our real argument". Practitioners of structured decision-making argue that refusing totals just moves the weighting into an unstated gut call. The synthesis: state the weights first and in the open if you must sum, and still present the deciding row.
- ILLUSTRATIVEThe three-person team, the absent load measurements and the three-way architecture comparison are invented; the positions in the matrix are for the shape of the argument and a team with a platform group would fill some cells differently.
Where the depth lives
This domain asks the question and hands the answer off by name.