Six Engineers Running at the Speed of Twenty

The system’s story closed with the last chapter; the remaining chapters are about the people who built it, and how all of it ended. Start with the most basic question: the system in the previous seventeen chapters — the FSM, three-layer orders, payment fact tables, an empire on one VM — who built it?

On paper: six engineers. The real answer is harsher: the commerce line was four engineers.

The line-up: two lines, seven people

Get the honest part out of the way first: I never really knew the bidding system. It ran independently on one backend, one front end and a dedicated PM, and was almost a separate world from commerce — which is why across seventeen chapters bidding appeared exactly once (the state machine ripped out by the hosts, and that second-hand). A war story only covers the battles you were at, and all I can give this line is a box on an org chart.

On the commerce side the composition is interesting: the CTO wrote no code during the commerce period and worked full-time as a PM. He was the requirements funnel — every want from the business, the hosts and operations passed through his translation before becoming a task. Why did #15‘s midnight calls go to him? The picture is complete now: not only because he was most senior, but because he was the single point of contact for the product, so even a scattered wish had a definite recipient.

So “six engineers running at the speed of twenty”, unpacked, is: two engineers on bidding, four on commerce — four engineers who built everything the previous seventeen chapters describe.

The growth arc: from one person to earning the right to talk process

The team didn’t start out like that. At the very beginning, the backend was just me.

The single-person gap was tourniqueted with outsourcing — and there’s a failure here worth telling in full. We contracted coupons out to a contractor: the module looked cleanly bounded, the spec was writable, textbook “suitable for outsourcing”. Two months later he said he had no more time to continue; I opened the PR and the quality was poor — we abandoned the entire PR, and two months went to zero.

In hindsight the mistake was at step one: coupons look independent and are actually one of the most semantically loaded areas in the whole system — #11 covered how deeply they interlock with the amount columns in carts, orders and payments, and how correctness with money is an accounting property. Functionally independent isn’t semantically independent; measure an outsourcing boundary by semantic coupling, not by feature boundaries. Once other full-timers arrived we never outsourced again.

The day the second backend engineer was hired, I started leading. A lead on a small team has no option to leave the production line — on top of sustaining high output came three checkpoints: technical breakdown of tasks (the entrance to work), review (the exit of code), and technology choices (the system’s boundary). How well the last checkpoint was held has a report card visible across the whole series: #2‘s stack list, five boring components, which never grew in eighteen months — nobody ever smuggled a new toy in.

Process: order the queue, don’t schedule it

The core of the speed isn’t the people (though they matter), it’s the shape of the process. What we ran was internally called Adaptive Agile, and unpacked it looks like this:

A few designs worth magnifying:

Order the queue, don’t schedule it. Tasks live in Notion in order, and engineers pull in order. No estimates, no sprint planning, no demos. Scrum’s rituals buy you prediction — when will it be done, how much does this sprint commit to; we didn’t buy prediction, we just maintained an ordered queue. Prioritisation centralised (ordered through the CTO’s funnel), execution decentralised (engineers pulling for themselves) — for a team of four, prediction’s value approaches zero while ritual’s cost is very real, and that arithmetic was done clearly.

The spec is produced by the implementer. The flow’s first station is “research”: the engineer who takes a task writes the task out fully and designs the solution before building. It isn’t a PM writing a spec and handing it to engineers — the person writing the spec is the person writing the code, so translation loss is zero, and the lead’s breakdown and review are the counterweight to that freedom.

Release is merge. #2‘s CI/CD closes the loop here: a release isn’t an event requiring a meeting, it’s the natural consequence of a merge. Half the rhythm of a dozen features a day comes from that loop.

Fully remote, with three questions daily: what did you do yesterday, what will you do today, what’s blocked. Fully remote was a rare species back then; what held it together was everything above — an ordered queue makes “what to do” unambiguous, fully written tasks put knowledge into text, and the three questions surface what’s stuck.

The quality line: test shape follows architecture

Speed needs brakes. Our testing strategy went through one deliberate turn worth telling:

We started with plenty of unit tests — and then I noticed something was off: too much mocking, and the tests had lost touch with reality. This system’s centre of correctness is in the data (DB-as-validator, fact tables, derive on read), so a unit test that mocks the DB has mocked away the system’s semantics, and a green light like that persuades nobody. The textbook test pyramid was invented for systems whose logic lives in objects; our logic lives in the data, so the centre of gravity of testing should move there too.

So we later added a lot of integration tests: mostly unmocked, asserting directly on what got written to the DB — writing “after this operation, the tables should look like this” as assertions. The most expensive e2e tests bought exactly two paths: payments and invoicing — the places where money crosses the system boundary, with third-party terrain teaching the lesson again: an e2e test sometimes goes red because of the third party itself, but you look at it carefully every single time, because that red light might not be a broken test, it might be the real world talking.

The review gate is simple: unit and integration must pass. Matters of form never reach a human brain — ruff and mypy mechanise style and types, with an AI review added on the front end; humans spend their time only where machines can’t help: semantics. My own reviews have a fixed opening move: read the tests first. A test is a solidified spec — what the research stage wrote as “what this task must achieve” ends up as an assertion; reading the tests first means reading the author’s understanding of correctness first, then checking whether the implementation delivers it.

The rebuild

The process itself barely changes — it’s the prototype I’ve reproduced on every team since. The one thing that genuinely changes is that failed outsourcing: manage contractors with your own process. What the contractor got was “one module, two months, see you then”; a rebuild would require a daily sync, and my involvement at every stage — research, design, build, test — so I know his state at all times rather than finding out two months later. Put plainly, it’s applying #15‘s monitoring philosophy to people: the daily sync is a heartbeat, the stage gates are a pipeline, and knowing the state is observability. What’s cheap about outsourcing is the salary, not the management cost; the management we saved back then was paid back later as two months of sunk cost.

One more bill goes on the tab here: this kind of speed also has a price. A feature wished for at midnight, shipped the following week, and unused for three months — that story, and what it taught me, is saved for the finale.

Reflections

Speed is structural, not heroic. Four engineers shipping features daily didn’t come from overtime, it came from low friction: near-zero ritual, merge equals release, order the queue rather than schedule it, zero translation of specs. To reproduce this team’s speed, don’t look for four superhumans — dismantle those four frictions first. Speed is a function of process shape; people are the coefficient and the shape is the exponent.

The essence of a checkpoint is letting other people go fast. A lead’s three checkpoints — breakdown at the entrance, review at the exit, technology choice at the boundary — look like control and act like liberation: because someone holds the direction at the entrance, catches quality at the exit, and blocks toys at the boundary, everyone in between can run flat out. Good brakes are what let a car be driven fast; good checkpoints are what let a team dare to ship daily.

Seeing your own boundary is a kind of honesty too. Same company, seven people, and to this day I can’t give you details of the bidding line — the walls between bodies of knowledge are far lower and far nearer than you’d think. That looked like a natural division of labour at the time, and now it reads as foreshadowing: how the organisation splits is how the system grows, and where the wall is built is where the split line falls.

And this fast-moving team had one thing nobody saw coming: its end was nearer than anyone thought. Next chapter, the day development paused.