01Illustrative scenario
Start with the coffee
Start by defining the need: two coffees each morning, little space and a modest budget. That changes how we judge the available solutions, even when each was built with a different method
Technology is never the starting point
Sixteen illustrated cases from history, business and technology, exploring the assumptions behind our decisions and the consequences that follow
Chapter 1/ 4 stories
Understand the problem before choosing a solution
Tools and convincing answers can feel like progress before the need is clear. We start by examining what we are trying to achieve and what the evidence actually establishes
02History and interpretation
An answer still needs judgment
The correct answers persuaded spectators that Hans could calculate, until controlled tests revealed the cues behind his performance. With AI, an answer can arrive before we have understood the problem; our judgment determines what it is useful for
03Illustrative scenario
Understand how the information will be used
A team celebrates its BI platform, yet its most requested feature is exporting to Excel. Before adding another dashboard, it is worth asking what people actually need to do with the data
04Feynman’s analogy
The form does not explain the result
Feynman described people reproducing the visible parts of an airstrip without the conditions that made aircraft arrive. Organizations do something similar when they copy meetings, rituals and tools without asking what made the original method work
SourceChapter 2/ 4 stories
Choices depend on conditions that can change
Once we choose a solution, its usefulness depends on costs, definitions and conditions that may change. These stories examine what we take for granted when we expect a technology to keep working for the business
05Historical account
The plan outlived its technology
Sweden planted oaks for future warships, and by the time the first trees were ready in 1975, naval construction had moved to metal. We make a similar bet when we expect a chosen tool to keep meeting the business’s needs throughout our plans
Source06Historical account
It worked in another context
Ariane 5 reused software proven on Ariane 4, but its different flight conditions exceeded an assumption built into the code. Both inertial reference systems failed. Reusing something that worked requires checking whether its assumptions still hold
Source07Security by design
Security belongs in the first conversation
What must be protected, who should have access and what could go wrong help define the solution from the start. Security requirements shape a process change, a policy or a new system, and need a place in the first conversation about the problem
08Illustrative scenario
Complexity needs a reason
A request for a simple calculator becomes an application with services, infrastructure and dozens of files, each adding work to understand, operate and maintain. Faster code generation makes it even more important to decide which complexity the problem actually requires
Chapter 3/ 5 stories
Success goes beyond delivery
A launch can satisfy a plan while leaving difficult questions about risk, people and continuity. The result includes the capacity to operate, recover and keep moving after the project team has finished
09Historical account
Warnings have to change decisions
The Vasa's stability test was stopped after the ship showed signs of rolling dangerously. Pressure to sail prevailed, and it sank on its maiden voyage. The warning was there; the decision did not change
Source10Satire
The shortcuts become the system
The checklist turns familiar shortcuts into a deliberately bad project plan: unclear ownership, inherited processes, dirty data and exceptions that accumulate. Each workaround can keep progress moving while increasing what the organization will depend on afterward
11Historical account
Count what the victory consumed
Pyrrhus’s victory came with losses his army could not easily replace, reducing its capacity for the battles ahead. In a project, the cost of delivery includes the strength, trust and capacity that remain in the organization afterward
Source12Historical account
Evaluate the whole journey
Amundsen and Scott both planned to reach the South Pole and return. Amundsen's team came back; the five men in Scott's polar party died on the return journey. Reaching the milestone was only part of the plan
Source13Illustrative scenario
The work has to resume
The studio’s work becomes unavailable and its backup cannot restore a usable project, until a separate copy helps the team resume production. Recovery testing should demonstrate that people can continue the work before that capability is urgently needed
Chapter 4/ 3 stories
Start with the value the business needs
The final stories bring the decision back to what people need and the outcomes that matter. Technology can change as the business develops new products, capabilities and ways to create value
14Business history
The business can evolve
Nintendo began with playing cards and moved through toys, electronic games and consoles as technologies changed. The products changed repeatedly; the ability to create experiences people wanted kept opening new possibilities
Source15Leadership reflection
What remains after you leave
While you hold a role, people attend meetings and follow direction. Some do it because they trust you; others because the organization requires it. Years after you leave, the former colleagues who still call, share achievements and grow into leaders themselves show what remains when authority is gone
16Business framework
Define the value before the technology
Efficiency, trust and growth describe outcomes that matter to the business, with measures such as cost, speed, risk, customer experience and revenue. The next technology decision begins by choosing what needs to improve, who benefits and how the improvement will be assessed