5 min read

What Elevators Know About Scheduling

Table of Contents

The top of Hacker News today is a page about elevators. An interactive simulator that lets you play god with a bank of cars, crank the passenger flow, and watch wait times pile up. Hundreds of upvotes for the thing everyone has cursed at while holding a coffee.

It’s worth your time for a reason beyond the toy. Buried in the buttons and knobs is a clean lesson about scheduling — one that applies to your team’s work as much as to a lift shaft.

The algorithm you think you’re riding

The simplest elevator algorithm is SCAN, patented in 1961: the car goes to the top, reverses, comes back down, picking everyone up on the way. Nobody wants that. What you expect is LOOK — the car only travels as high as the highest request, then turns around.

With multiple cars, a central scheduler assigns each new call to the nearest car. That feels optimal. It isn’t, and Otis knew it decades ago. Their Relative System Response (RSR) algorithm scores every car for every call: ETA to pickup, plus a penalty if the car is full, plus a penalty if another car is already heading to the same floor in the same direction, minus bonuses for being idle and nearby. Lowest score wins.

The interesting part isn’t the formula. It’s that RSR re-optimizes every five seconds. A call assigned to car A gets silently re-routed to car B when A hits a delay. The plan is disposable; the re-planning is the product.

A buffering spinner — you, waiting for the elevator

You are your p90

How do you measure a good elevator? Not average wait. The simulator plots the full distribution, and the article makes a point every incident review already knows: people don’t remember the average. They remember the time the elevator took forever. The p90 is the experience.

Same for a team. Nobody remembers the sprint that flowed. They remember the PR that sat unreviewed for four days, the deploy blocked on one person’s approval, the task that bounced between three owners. Your process is judged by its tail.

Smarter isn’t always better

Here’s where the simulator earns its upvotes. Crank the passenger flow high enough and the dumb LOOK algorithm starts beating RSR. When every car is always full and stopping on every floor, the clever scoring rules stop mattering. LOOK also wins in small buildings with few cars.

Translation: a sophisticated system can lose to a simple one when the system is saturated. If your team is overloaded, no amount of planning refinement will save you — the fix is fewer requests, not a better queue.

More information made it worse

The best finding in the piece is about destination dispatch — the fancy kiosks where you type your floor before boarding, and the system assigns you a car. Full information up front. Surely that wins?

It doesn’t. For most buildings, the old up-and-down buttons beat the kiosk. The reason is beautiful: the kiosk forces rigidity. You must take your assigned car. But the world changes thirty seconds after you called, and the old system’s five-second re-optimization loop adapts while the kiosk can’t. The loss of flexibility costs more than the extra information buys.

Read that paragraph again and think about your sprint planning meeting. A big upfront commitment ceremony that produces a rigid assignment — versus a system that continuously re-reads the actual state of the work and re-routes. Elevators figured this out. Software teams are still holding the ceremony.

What this has to do with your board

Every standup, every status sync, every “quick check-in” is a kiosk. A point-in-time snapshot that freezes assignments and goes stale within hours. The RSR insight points the other way: keep the assignments loose and re-optimize constantly from live signals — what shipped, what’s blocked, what’s actually moving.

That re-optimizing loop is what we built Kahoona to be. It reads the live state of your GitHub activity — commits, PRs, CI — and keeps the board current next to your tasks, so the plan reflects the world as it is, not as it was when someone scheduled a meeting about it.

👉 Stop scheduling the kiosk — free to start

Related: Standup is a latency problem · How to run async standups from your GitHub activity