Known vs Required Technology
Two technology constraints that look alike and are opposites: what the team already knows, and what the situation imposes. The first is a soft constraint that decides most choices by default; the second is a hard one that has to be understood rather than resented — and the "we must use X" that is neither is the one to challenge.
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.
When should the technology you know decide the design, when should the technology you are told to use, and how do you tell an imposed technology from a preference wearing its clothes?
You know a TypeScript stack well. The founder's contract names a payment provider you have never used. A colleague says the store "has to run on Kubernetes because that is what the company uses". Three technology statements, three different kinds of constraint, and they have all arrived in the same meeting as if they were the same kind.
Treat every technology statement as a requirement. The known stack is used because it is known; the provider is integrated because it is contracted; the cluster is used because someone said so. Each decision closes quickly and the meeting ends.
The known stack is used where it fits and where it does not — a batch reporting job written in the web framework because that is what the team knows, when a scheduled query would have been three lines.
- The known stack is used where it fits and where it does not — a batch reporting job written in the web framework because that is what the team knows, when a scheduled query would have been three lines.
- The contracted provider is integrated by copying its example without understanding its failure model, and the first webhook that arrives out of order breaks the order state machine.
- The cluster costs the first three weeks of a six-week project. Nobody asked what problem it solves for a store with one server's worth of traffic, because "the company uses it" sounded like a hard constraint and was actually a habit.
- The three decisions are indistinguishable in the design record. When one of them turns out wrong, nobody can tell whether it was a preference, a contract or a habit — so nobody can tell which can be changed.
The move
Precisely enough to apply it to a problem you have never seen — not a slogan.
- Sort every technology statement into one of three bins before acting on it. *Known*: the team can build, deploy and debug it today; this is a soft constraint and a strong default, because the time not spent learning is time spent on the problem. *Required*: imposed by a contract, a partner's interface, an existing system that must be integrated with, or a law; this is hard, and the move is to understand it well enough to design around its shape rather than to fight it. *Claimed*: "we must use X" with no contract, no partner and no law behind it — a habit, a preference or a fashion; this is soft, and the move is the why ladder.
- For known technology, ask where it does not fit. A default is not a universal; the team that knows one framework will use it for the web tier well and for the batch job badly. The question is "is this problem the shape the tool is for?" — and if not, whether the gap is small enough to learn or large enough to change tools (Framework Independence).
- For required technology, invest in understanding early, because it will shape the design whether you understand it or not. A contracted payment provider decides how payment states flow, whether checkout is hosted, and how confirmations arrive — those are design inputs, and a spike in the first week finds them while the design is still cheap to change (The Smallest Experiment With a New Technology).
- For claimed technology, climb the ladder: why must we use it, what does that give us, what did we actually need, what is the simpler thing that meets it, and when would the claim have been right. The answer is sometimes "it was right" — the cluster exists, the team runs everything on it, and a store outside it would be the odd one — and the ladder finds that too.
Three bins
The decision is the sort. The criteria are about evidence, not about the technology: the same tool can be known on one team, required on another and claimed on a third, and the response differs each time.
What is the evidence behind "we use X"?
when The team can build, deploy and debug it today, and nothing imposes it — the evidence is the team's experience.
cost A strong default that will be used where it does not fit unless someone names those places; the cost of not learning the better tool for the batch job or the search index.
when A contract, a partner's interface, a system that must be integrated with, a law or a support policy imposes it — the evidence is a document or a person who owns the constraint.
cost Time in the first week understanding its shape — how it fails, how it confirms, what it forbids — because it will shape the design either way.
when "We must use X" with no document and no owner — a habit, a preference, a fashion, or a real requirement that has not been stated yet.
cost A why ladder and a conversation, which finds either the real requirement (and moves the claim to required) or the simpler thing (and drops it, in writing).
The ladder on a claimed technology
The ladder is the tool for the third bin, and the device carries its own honesty: the last field says when the claim was right. In the store's case it was — but as a support-policy requirement, not as a scaling one, and that distinction is what later let the store move.
“The store must be deployed on the company's Kubernetes cluster.”
- ↓Why the cluster? Because that is where the company runs its services.
- ↓Why does it matter that the store is where the others are? So that deployment, monitoring, secrets and on-call are handled the standard way.
- ↓What does the store actually need from "the standard way"? A repeatable deploy, the standard monitoring agent, the standard secret store, and someone who will answer the pager.
- ↓Does any of that require the cluster specifically? The first three do not; the fourth might, if the operations team only supports services on the cluster.
the claim was right when The operations team's support policy covers only the cluster, so a store outside it has nobody on the pager. Then the claim was right, but as a support requirement — and it is recorded as that, so that when the policy changes the store can move.
Known technology, where it fits and where it does not
The pair shows the known-technology default applied once well and once badly. The store's team knows the web framework; the reporting job is the place the default did not fit, and the better version is the one that noticed.
A web-framework background job that loads every order of the day through the ORM, sums them in application code, and writes a report row — because the team knows the framework and it was the obvious place.
A scheduled SQL query that sums the day's orders in the database the team also knows, writing the report row directly; the framework is used for the web tier, where it fits.
The first version does in the application what the database does in one statement, and it will be the first thing to fall over as orders grow; the second uses a known tool for the shape of problem it is for. "Use what you know" chose both; only the second asked where the known tool fits.
How to do it
Most important first.
- List every technology named so far and write its bin beside it: known, required, claimed — with the evidence. A contract number is evidence; "everyone uses it" is not.
- For each known technology, write one place in the store where it is a poor fit and what you will do there instead.
- For each required technology, schedule the spike in the first week and write the three things it must answer: how it fails, how it confirms, what it forbids (Researching an Unknown Technology).
- For each claimed technology, run the why ladder and write the real requirement, the simpler thing and the case where the claim was right (The Why Ladder).
- Record the bin in the decision log, so that when a technology decision is revisited, the first question — "was this a preference, a contract or a habit?" — has an answer.
Worked on a concrete problem
The move has to produce something. This is what it produced.
- The store's three statements, sorted. TypeScript and Postgres: known — both developers can build, deploy and debug them; used as the default, with the batch sales report written as a scheduled SQL query rather than as a web-framework job, because that is where the default did not fit. The payment provider: required — a contract; spiked in week one, which found that confirmations arrive as webhooks that may repeat and may arrive before our own response is processed, and that hosted fields are mandatory for card data. Both facts reshaped the checkout design before it was written. Kubernetes: claimed — no contract, no partner; the ladder ran.
- The ladder on the cluster. Why must the store run on it? Because the company runs its services there. Why does that matter for the store? So that deployment, monitoring and secrets are handled the standard way. What was actually needed? A repeatable deployment with monitoring and secret management that the company's operations people can support. Simpler thing: a single container on a managed host with the company's standard monitoring agent and secret store — reachable in a day. Justified when: the company's operations team will only support services on the cluster, and being the exception means no one answers the pager. That turned out to be the case, which made the claim a real requirement — but a different one from "the store needs a cluster".
- On the AI assistant that answers questions about company documentation, the same sorting: the vector database a colleague insists on is claimed, and the ladder finds the real requirement is "find the relevant paragraph among a few thousand documents", which a text search index the team already knows meets for V1; the identity provider is required, because every internal tool must use it; the language the team knows decides the rest.
- The record afterwards: three decisions, each with its bin and its evidence. When the operations team later offered a managed platform for small services, the store moved in an afternoon — because the cluster decision was recorded as "required by support policy", not as "the store needs Kubernetes", and the policy had changed.
How you know it worked
What now exists that did not before, and what question you can now ask.
- Every technology named in the project has a bin and evidence beside it, and the claimed ones have been through the ladder.
- The required technology was spiked early and produced design inputs — a failure model, a confirmation model, a constraint on hosting — before the design that depends on them was drawn.
- The known technology is used by default and has at least one named place where it was not used because it did not fit.
- At least one claimed technology was either dropped with a written reason or promoted to required with the real requirement written beside it.
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.
- ?Is this technology known, required, or claimed — and what is the evidence for the bin?
- ?Where in this system does the technology I know not fit, and what will I do there?
- ?What does the required technology decide about the design that I need to learn before drawing it?
- ?For the claimed one: why, what did we actually need, what is the simpler thing, and when would the claim have been right?
What can go wrong
- Everything claimed is treated as wrong. The ladder is run to reject, not to find out, and a technology the company genuinely needs the team to use is fought for a week and then adopted anyway, later and with bad feeling.
- Known technology is never questioned. The team uses its one tool for everything and calls the result a constraint; "we know it" is a default, not a design.
- Required technology is integrated late because it was unfamiliar and therefore postponed. The provider's shape then arrives as a surprise in week five, and the checkout is rebuilt around it.
- The bins are not recorded, and a year later nobody can say whether the store is on the cluster because of policy or because of habit — so nobody dares to move it.
- Sorting and laddering every technology statement takes a meeting that the reflex would have skipped; on a team that agrees about its tools, most of the sorting is a formality.
- Spiking required technology early spends the first week on integration rather than on features, which looks slow to anyone counting screens.
- Challenging a claimed technology is a conversation with whoever claimed it, and the ladder can find that they were right — which is a good outcome that some people experience as a lost argument.
- "Use what you know" is a rule. It is a default with a boundary: use what you know where the problem is the shape the tool is for, and learn or change where it is not. A team that only ever uses what it knows never learns the thing the next problem needs.
- "Required technology is a constraint to minimise contact with." It is a design input to understand early. The provider's webhook model is not an annoyance to wrap; it is the shape of your payment states.
- "Claimed technology is always a habit." The ladder finds the case where the claim was right, and it is often a real organisational requirement wearing a technical sentence. The point is to find which requirement, not to win.
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.
- TEAM-SPECIFICFor a solo learner "known" is a small set and the interesting question is what to learn next; on a team inside a company, "required" includes the platform, the identity provider and the operations team's support policy, and "claimed" is usually a colleague's habit — the bins are the same, the contents are entirely different.
- STAGE-SPECIFICOn a greenfield store the known stack is a free choice with a default; in an existing system the current stack is required by the code that already exists, and the move becomes deciding whether a new piece may differ from it and what that costs in operational surface.
- ILLUSTRATIVEThe contracted provider, the cluster policy, the operations team and the afternoon migration are invented to show the three bins; the kinds of evidence are real.
Where the depth lives
This domain asks the question and hands the answer off by name.
- — The technology decision tool at /thinking/decide asks which problem a named technology is solving — the same sort, one technology at a time.