On Friction

Move fast and break things.

An early Facebook motto

No product is made perfect right away, it requires iterating and trying out different things. Everyone starts with something broken and keeps trying until it's fixed. Who gets things fixed the fastest - wins.

The key component to succeed in iterating is to minimize friction, so the workflow is smooth and the team gets things done instead of waiting, synchronizing, and wasting time on irrelevant stuff. This has to be considered on any level, from a single individual to the whole organization.

Examples of friction on the organizational level:

1. Having more than one goal at a time. It applies to any level, from a single individual to the whole organization.
2. Accumulating work-in-progress items.
3. Requiring approvals for everything instead of assigning a quota. Not just in budgets, the freedom to make decisions can be a subject of quotas too, for anyone in the team.
4. Synchronizing the communication that can be async.
5. Keeping the discussion async when it has to become synchronous.¹

In software engineering:

1. Runtime errors that could be compile errors.
2. Reproducing bugs in runtime instead of tests.
3. Routinely performing a sequence of actions instead of calling a single script (env setup, builds, deploys, etc.).
4. Requiring more than one commit to perform a single change.
5. Premature optimization in any possible sense.

For any activity, you have to ask from time to time: what's the friction coefficient here? What can be done to reduce it? Then things start to roll.

1. Re #4 and #5: any textual information exchange has to be considered async, instant messaging is poison. If you need to have a discussion, make a call. ↩