Organisations love to admire speed, from a safe distance. We point to Spotify, Tesla, or the latest startup myth and conclude that velocity is a luxury item, something you earn after talent, capital, and luck have aligned.
For most organisations, the assumption is comforting: we’re slow because we’re serious.
That assumption is wrong.
Speed is not a personality trait of companies, nor is it a matter of typing faster, working longer hours, or exhorting people to “hustle.” Speed is an emergent property of how human cognition, learning, and coordination actually work. Once you understand those constraints, the principles in the FAST infographic, “Few, Small, Together”, stop looking like managerial fashion and start looking like applied cognitive science.
The infographic does not propose novelty. It proposes alignment with reality.
From Code to Organizations: Make It Run, Make It Right, Make It Fast
Software engineers have long internalised a deceptively simple rule:
make it run, make it right, make it fast.
Popularised in Extreme Programming, the mantra is often misunderstood as a sequencing trick. It is, in fact, a theory of learning.
- “Make it run” means produce something that exists in the world and can be tested.
- “Make it right” means refine it based on feedback and understanding.
- “Make it fast” means optimise after the nature of the problem is known.
What FAST does is to apply this logic at the organisational level.
Organisations routinely attempt the inverse: they try to make it right (through analysis, alignment, and planning) and make it fast (through scaling, tooling, and pressure) before anything has been allowed to run. The result is predictable: polished uncertainty, followed by expensive corrections.
Working FAST (Few things, in Small steps, Together) forces the organisation to run first. Speed here is not recklessness; it is epistemic humility.
Why Speed Matters More Than We Admit
Most organisations implicitly believe that doing the right thing and doing it right must come before doing it fast. Speed is treated as a risky afterthought, something you optimise once certainty has been achieved.
But this ordering reverses how learning actually happens.
In the real world, especially in markets, technology, and complex systems, there is rarely a single correct answer waiting to be discovered through analysis. Instead, there are hypotheses that must be tested against reality. Delay does not buy certainty; it buys ignorance with confidence.
Working fast is not the enemy of quality or correctness. On the contrary, working fast is what allows you to discover what “right” even means.
Few: Why the Brain Hates Multitasking
Few, the first principle, is not about discipline or virtue. It is about attention.
Human cognition did not evolve to juggle ten priorities at once. Context switching carries a measurable cognitive cost: every time attention shifts, working memory must be reconstructed. Productivity doesn’t degrade linearly; it collapses.
This is why monotasking is fastest, and why even a small rotating set of tasks beats a large one. The infographic’s advice to limit work-in-progress is simply an acknowledgement of cognitive bottlenecks.
In uncertain or novel situations, the problem deepens. You cannot plan your way to clarity because the information required to plan does not yet exist. Here, the hypothesis–try–follow-up–conclude loop (a complexity-aware version of PDCA) becomes essential. Timeboxing replaces prediction. Learning replaces speculation.
Fewer things, pursued seriously, outperform many things pursued optimistically.
Small: Why Progress Comes in Cheap Experiments
Large tasks feel efficient because they appear to amortise effort. In practice, they do the opposite.
Big batches delay feedback, magnify risk, and make error correction expensive. Small steps, completed in hours or days, reverse this equation. They produce rapid feedback, preserve momentum, and allow learning to compound.
This is where the old engineering rule KISS (Keep It Simple) reveals its real meaning. Simplicity is not aesthetic minimalism; it is cognitive economy. Every additional feature, requirement, or dependency increases the surface area for misunderstanding and failure.
The Agile Manifesto captures this insight bluntly: maximise the amount of work not done. This is not an exhortation to laziness. It is a recognition that most work does not create proportional value, especially before feedback has clarified what matters.
FAST operationalises this principle. By insisting on small, finished steps, it forces teams to ask not “what could we build?” but “what is the smallest thing that will teach us something real?”
Together: Why Collective Intelligence Isn’t Automatic
If few and small respect the limits of individual cognition, Together addresses the limits of individual intelligence.
Collaboration is not merely additive. When people work simultaneously on the same problem, learning propagates instantly. Assumptions are challenged early. Errors are caught before they harden. Context becomes shared rather than narrated after the fact.
But the infographic is careful here: bigger is not better. Small groups outperform large ones in complex work because coordination costs scale faster than insight. Two to three people (or three to seven without AI) maximise learning while minimising drag.
Psychological safety matters, but not because conflict should disappear. Teams fail when they prefer being “wrong together” over “right alone.” FAST teams institutionalise dissent, curiosity, and correction—not harmony.
From FAST to FASTER: When Work Becomes Familiar
As work stabilises, something important happens. Tasks migrate from the complex domain into the ordered one. Here, optimisation becomes possible—but only here.
This mirrors the XP mantra again. Once something reliably runs and is sufficiently right, it becomes sensible to make it fast. Premature optimisation at the organisational level is just as harmful as it is in code.
The infographic’s FASTER layer recognises this transition. Engagement becomes the limiting factor. Short-term feedback sustains focus; long-term motivation depends on purpose, mastery, and autonomy. Neglecting any one of these cannot be compensated for by excess in another.
Roles emerge to support clarity and coordination, but rigidity is a risk. Over-specified roles block learning and diffuse responsibility. Leaders, in this model, are not controllers. They are mentors, boundary managers, and stewards of the political and psychological environment. Responsibility for failure flows upward by design.
Flow: Seeing the System, Not Just the Tasks
FAST is not an endpoint. It is a local behaviour that enables global optimisation.
Once teams learn to work FAST, organisations must learn to see flow. Visualisation tools such as Kanban boards, process maps, and shared metrics externalise cognition. They create a shared mental model of reality, making bottlenecks visible and improvement tractable.
Crucially, the system must keep experimenting—not only in what it delivers, but in how it works. Systems stagnate not because they stop optimising, but because they stop questioning what should be optimised at all.
The Central Insight
The FAST model does not promise speed for its own sake.
It promises learning at the speed reality allows.
Few respects attention.
Small respects feedback.
Together respects intelligence.
Or, in the language engineers already understand:
Make it run.
Make it right.
Then, and only then, make it fast.
When organisations internalise this, speed stops being a gamble. It becomes a consequence. They become harder to surprise—and that, in a complex world, is the only durable advantage.
If you liked this article I recommend Jan Grape blog posts about “What makes an organization slow and how to fix it” for more ideas on moving faster.
