看板 — Signboard
Kanban (看板) is Japanese. The characters break down as: 看 (kan), to watch, to see, & 板 (ban): board, plank, sign. Together: a visual signal board.
The word predates the management system by centuries. Every shop in Edo-period Japan had a kanban: a wooden sign outside announcing what was sold inside. The visual signal was the advertisement, the inventory indicator, & the reorder trigger all at once.
Taiichi Ohno's Supermarket Insight
In the 1950s, Toyota engineer Taiichi Ohno visited American supermarkets. What he saw changed manufacturing history.
In a traditional factory, the push model, production ran on a schedule. A forecast said "we will need 500 units next month," so the factory made 500 units & pushed them to a shelf. If demand was wrong, the shelf overflowed. If demand exceeded the forecast, the shelf was empty. Either way, someone was wrong.
Supermarkets worked differently. Shelves held a fixed quantity of each item. When a customer took the last jar of peanut butter, the empty slot was itself the reorder signal. Stock workers didn't need a manager to tell them to reorder: the shelf told them. This is the pull model: downstream demand signals upstream replenishment.
Ohno brought this insight back to Toyota. The physical card (kanban) attached to a bin of parts became the signal: "this bin is empty: produce more." No forecast needed. No central planner. The work pulled itself forward.
Push vs. Pull
The push/pull distinction is the foundation of everything that follows.
Columns as States
A kanban board makes work visible. Every piece of work is a card. Cards move left to right through columns that represent states.
The classic columns are: Backlog → Selected → In Progress → Review → Done
But the exact columns don't matter. What matters is that every card has exactly one current state, & that state is visible to everyone who works in that system.
What a card represents
A card represents a unit of work that can be independently completed. Not a project. Not a goal. A specific, scoped thing with a clear definition of done.
Good card: Rotate SSH keys on prod servers: done when all servers show new key in authorized_keys & old key is removed.
Bad card: Improve security. (This is a project, not a task. Break it down.)
WIP limits
The In Progress column in the diagram shows a WIP limit: 3. This means no more than three cards can be In Progress at the same time. If you want to pull a fourth card, you must finish one first.
This feels like a constraint. It is: by design. WIP limits force you to finish what you started before starting something new. More on why this matters in a later section.
Scoping Work Cards
The hardest skill in kanban is not drawing the board. It's scoping the cards. Too big & a card sits In Progress for weeks, blocking other work. Too small & the board fills with noise.
Silos Work Fine
Any multi-discipline operation has functional work centers: a bakery has pastry, bread, savory, & front counter. A product studio has design, content, build, & ops. A construction project has framing, plumbing, electrical, & finishing. These centers exist for good reasons: deep specialization requires focused ownership.
Kanban doesn't dissolve these divisions. It makes handoffs between them visible & explicit.
The handoff card
When a unit of work moves from one work center to another, say, a design asset that needs copy written before the builder can assemble the page, a handoff card travels with it. The downstream center sees the card appear in their Backlog. They pull it when they have capacity. No email required. No meeting to coordinate. The card is the signal.
What the diagram shows
The ★ ticket starts in Design (In Progress: visual assets). When Design finishes their part, a handoff card is created & the ★ ticket appears in the Build center's Backlog. Build pulls it. Then Ops pulls it. Each center has its own board. Each board shows only that center's current work. But the ★ travels through all of them, & everyone can see where it is.
This is the supermarket insight applied to organizations: each work center is a shelf. Cards restock downstream shelves only when upstream work is pulled & consumed.
Designing a Handoff
The handoff card is the contract between work centers. It must contain enough context for the receiving team to act without a meeting.
Stop Starting. Start Finishing.
WIP stands for Work In Progress. A WIP limit is a cap on how many cards can be in a given column at once.
This sounds like a restriction. It is. That's the point.
Why limits help
Every time you start a new task without finishing the previous one, you pay a context-switching tax. Your brain loads the context of the new task & partially unloads the old one. When you return to the old task, you reload it. For knowledge work, writing, debugging, designing, reviewing, this reload cost gets measured in hours, not seconds.
WIP limits prevent the accumulation of half-finished work. They also do something more valuable: they surface bottlenecks.
Bottlenecks become visible
If the Review column has a WIP limit of 2 & it's always at 2, that's a signal: review is slower than production. More work is completing In Progress than can be consumed by Review. Without a WIP limit, the board fills with 'done-but-waiting-for-review' cards & the bottleneck is invisible. With a WIP limit, the In Progress column can't accept new cards, & the whole team sees the constraint.
This is not a failure. It's information. The system is telling you to fix Review, hire, pair, reduce batch size, rather than blindly pushing more work through.
Little's Law (informally)
Lead time (how long a card takes from start to done) = Work In Progress ÷ Throughput (cards completed per unit time). If you want shorter lead times without hiring, reduce WIP. Fewer things in flight means each thing finishes faster.
R = (W × C) + T
WIP limits protect three variables. Efficiency consultant Brian Tracy named them in 1986.
R = (W × C) + T
- R: Result: the outcome you want
- W: Clarity of goal: how precisely you know what you want (0–10)
- C: Concentration: intensity of focused effort (0–10)
- T: Time worked without distractions (uninterrupted hours)
Why W & C multiply
Clarity & concentration are not independent. High concentration on a vague goal produces fast movement in the wrong direction. Perfect goal clarity with no concentration produces nothing. They interact: which is why Tracy wrote them as a product, not a sum. A 9/10 on each gives R = 81 + T. A 3/10 on each gives R = 9 + T. The difference is not additive.
Why T adds
Every distraction-free hour adds linearly to the result. T cannot compound W & C: it can only stack on top of the product. This explains why the first move is always to improve W & C, not to work longer hours. More T on a low (W × C) product is still a poor result.
What the kanban board does to each variable
- W: A well-scoped card (clear title, measurable acceptance criteria, single owner) raises W before work starts. Vague cards lower it automatically.
- C: WIP limits force concentration. One card in Active means full attention on one problem. Three cards in Active means C is split three ways.
- T: Pomodoro blocks & calendar protection create the distraction-free hours T measures. The board timer is not decoration: it tracks T in real time.
Tracy claimed any problem could be solved in 30 minutes when W, C, & T are all optimized. The kanban board is the instrument for optimizing all three simultaneously.
Reading the Board
Practice reading bottlenecks from board state.
Not Agile. Not Waterfall.
Agile is a methodology. Waterfall is a methodology. Kanban is a system.
Methodologies prescribe how you work. Systems describe what is true about work. Kanban doesn't tell you to have two-week sprints, daily standups, or retrospectives. It tells you one thing: make work visible, limit WIP, & pull.
The problem with methodologies
Agile works well for teams building products iteratively, software, mostly. Waterfall works well for projects with fixed requirements & known unknowns, construction, hardware manufacturing. Neither maps cleanly onto cross-discipline work where a design task & a fulfillment task have completely different cycle times & definitions of 'done.'
Forcing a design center & an ops center into the same sprint rhythm is a category error. A two-week sprint that works for content creation produces artificial urgency in logistics work. A standup ritual built for co-located teams creates overhead for independent solos.
Find common ground on work to be done
The un approach: find the work that needs doing. Find the people or partners best positioned to do it. Don't impose a process on top of that: let the work surface its own process through a shared visibility system.
This is not the absence of process. It's the right amount of process: enough to coordinate, not enough to create coordination overhead that exceeds the value of the work.
Don't build what you can buy. Don't buy what you can grow.
Before any work card is created, ask: should this exist at all? Every piece of work you build, you own forever. Every SaaS you subscribe to, you depend on forever. Every open-source dependency you fork, you maintain forever.
The decision tree: Can we grow this? A process, a skill, a relationship that produces the capability sustainably, prefer this. If growing isn't viable: Can we buy this? An off-the-shelf tool that solves 80% of the problem without custom work, prefer this. If buying isn't viable: Build it. And build it knowing you now own it.
Most organizations invert this order. They build custom infrastructure for problems that commodity tools solve well, then scramble to maintain what they built. Kanban makes this visible: every card in your Backlog is a thing you chose to build. The honest question is whether it should be there at all.
Build / Buy / Grow
Apply the decision framework.
Design a Board
Put it together. You'll design a kanban system for a specific cross-functional scenario.
Scenario
A small studio is relaunching their product with a new brand. The work involves four centers:
- Design: new logo, visual identity, product photography, page layouts
- Content: rewritten product descriptions, landing page copy, email announcement
- Build: updated website, new checkout flow, redirects from old URLs
- Ops: updated payment processor settings, fulfillment partner briefing, analytics reconfiguration
The relaunch has a hard deadline: a trade show in 45 days where the new brand goes public.
Solos Stay Silos
In most organizations, kanban exists to make work visible across a management hierarchy. Managers coordinate between silos. Kanban reduces the coordination overhead.
In the un model, there are no managers. There are solos. A solo operates an enterprise independently: a designer solo, a builder solo, a writer solo, an ops solo. Each solo is, by definition, a silo. There is no org chart connecting them. No reporting relationship. No manager to force coordination.
Kanban becomes the coordination layer. Not by flattening silos, solos remain fully independent, but by making the handoffs between them visible & explicit. A solo doesn't send an email or schedule a meeting to hand off work. They put a card on a shared board. The receiving solo pulls it when they have capacity.
This explains why kanban fits the un model better than agile or waterfall: it requires no shared cadence, no joint retros, no synchronized planning. Each solo sets their own WIP limits, their own cycle time, their own definition of done. Coordination happens at the card level, not the process level.