System design reviews for small teams

We end up explaining this on discovery calls often enough that it deserved writing down. Most advice about system design reviews assumes a team that does not exist at your size. Here is the version that does not.

The right architecture for a team of three is the wrong one for a team of thirty, and vice versa. The failure mode is not doing it wrong, it is doing it once and assuming it stays done.

What to keep

An hour of review before the build saves weeks of rework. Getting it slightly wrong is survivable. Ignoring it entirely is not. Doing this properly once is usually cheaper than doing it approximately three times.

What to drop

Process that exists to coordinate ten people is overhead when there are two of you. That sounds obvious written down. It is still the thing most often skipped.

The practical version

Invite the person who will be on call for it. Getting it slightly wrong is survivable. Ignoring it entirely is not. The teams that stay on top of it are the ones who put it on a calendar rather than a wish list.

How to tell if yours is fine

Most systems fail at the seams rather than inside any one component. Three things worth confirming about system design reviews before you move on:

• Someone can say what the current setup is without going to look
• Write the design down — and you know whether that is true here
• There is a way to tell whether the last change to this helped

Worth checking on your own setup before it becomes someone else's problem to fix.