← Rajat Paliwal

On Building Slowly

Every company I have worked inside believed it was moving too slowly, and almost every one of them was wrong about which part was slow. The part that felt slow was the visible part: the review that took three days, the launch that slipped a week, the meeting that should have been a message. The part that was actually slow was invisible and structural — a decision made two years earlier that quietly taxed every decision made after it.

This is the odd thing about speed in building anything. It is not a property of how fast people work. It is a property of how much of the past you have to carry while you work. Two teams with identical talent, identical hours and identical funding will diverge enormously over a decade, and the divergence will have almost nothing to do with either team's sense of urgency.

The interest rate on shortcuts

A shortcut is a loan. You get something now and agree to pay later, and like most loans, the trouble is not the principal but the rate. A small hack in a small system is a cheap loan: the surface it touches is tiny, so the interest is tiny. The same hack in a system that thirty people depend on is a different instrument entirely. Every future change now has to be compatible with it, reason around it, or pay to remove it.

What makes this hard to see is that the payment never arrives as a bill. It arrives as a mood. Estimates get longer for no visible reason. Good engineers start saying "it depends" more often. New hires take a quarter to become useful instead of a month.1 Nobody writes any of this down as the cost of a decision made in a hurry two years ago, because by then the decision has no author — it has become the way things are.

Two kinds of slow

It helps to separate them, because they look identical from the outside and they respond to opposite treatments.

Pushing on deliberation when the problem is drag is how organizations end up exhausted and stationary. Everyone works faster, ships more, and moves less, because the additional output arrives as additional weight. You can watch the cycle run for years in a company that is genuinely full of good people.

Speed you can feel is deliberation. Speed that matters is the absence of drag.

What building slowly actually means

Building slowly is not working fewer hours or shipping less. It is an unglamorous discipline of refusing to convert time pressure into structural debt. In practice it comes down to a handful of habits that all feel like costs in the moment and only look like investments in retrospect.

Decide late, but decide once

Most decisions are cheaper to defer than to make badly, but only if deferring is a deliberate act rather than a failure to notice. The useful version is to name the decision, name what evidence would settle it, and then carry on building the parts that do not depend on the answer. The useless version is to leave it undecided in six places at once, which is how you end up with three half-answers instead of one.

Keep the number of things small

Nearly every complexity problem I have watched up close was really a count problem: too many services, too many surfaces, too many concurrent bets, too many metrics that someone is accountable for. The count is a choice, and it is almost always made implicitly — nobody decides to run eleven priorities, they decide eight separate times to add one.

Write things down before they are settled

The cheapest tool for reducing future drag is a page explaining why something is the way it is. Not a specification — those describe the world as someone hoped it would be — but a short record of the constraint that forced the shape. Two years later that page is the difference between a change that takes an afternoon and a change nobody is willing to attempt.2


The part that is genuinely hard

None of this is difficult to understand, and all of it is difficult to do, for one structural reason: the costs of building slowly are paid by whoever is present, and the benefits are collected by whoever is present later. Very few incentive systems reward that trade honestly. A person who spends a quarter removing drag has a quarter with nothing to show, and a person who adds drag while shipping visibly has a good quarter and a promotion.

So the real work is not convincing yourself. It is building a way of accounting — even a crude one — that makes drag visible enough to argue about. Time from idea to production. Time for a new person to ship something real. The number of people who have to agree before a small change can happen. None of these are good metrics. All of them are better than the alternative, which is a room full of people who feel slow and reach for the accelerator.

The companies that seem to move impossibly fast, late, are rarely the ones that moved fast early. They are the ones that spent their early years refusing to borrow, and arrived at year six owing nothing to their own past.

  1. I now treat onboarding time as the single most honest measure of accumulated drag. It is hard to game and it cannot be argued with.
  2. The best version of this I have seen was a single directory of dated pages, each one a paragraph long, each one explaining a constraint rather than a plan.