Skip to the page

Plainly Put

One sentence about building things, taken apart

Execution

Do the least that gets the job done, and be exact about the job

The first half of the advice is easy to follow. Everything depends on the second half: knowing what actually has to get done.

Reduce. Do as little as possible to get what you have to get done.

Joshua Schachter

Delicious, the bookmarking service Joshua Schachter built in his spare time and sold to Yahoo in 2005, was small by design. It saved a link, let the user add a few tags, and made the list public. There was almost nothing else. That smallness made it fast, easy to understand and cheap to run, and it let one person keep up with a service used by millions.

The line is advice about where effort goes. Every feature, process and meeting has a cost that continues after it is created. A team that does only what the goal requires keeps its costs low and its attention free. A team that does everything that seems useful spends more and more of its time maintaining what it already built.

The hard part is the phrase “what you have to get done.” Minimalism only works when the goal is stated precisely. A vague goal, such as making users happy, invites endless additions, and it also allows the opposite mistake: skipping work that is genuinely required because it looks like extra. Security, backups, clear billing and a way for users to get help are examples. Doing as little as possible there creates problems that eventually cost far more than doing them properly.

The first word of the line is worth reading on its own. “Reduce” applies to steps as much as to features. A sign-up form with nine fields can usually lose six. A weekly report that nobody reads can simply stop. A two-person company can answer support by email for a long time before it needs a ticketing system, and the time saved goes into the product.

There is a reason the advice is easier to give than to take. Adding things feels like progress and is easy to justify one at a time. Removing things feels like loss, and someone usually objects. Teams that stay small tend to have a habit of asking, before each addition, what it will cost to keep, and of deleting what has stopped earning its place.

So the advice has an order. First write down exactly what must be achieved. Then cut everything that does not serve it, and keep everything that does, even when it is dull.