Systems

Opening signal

You sign a new client. You sit down and write the welcome email: what happens next, what you need, when the first meeting is, where the files will live, who is responsible for what. It takes you forty minutes, because you want it to be good.

That was the twenty-first time. Every time from scratch, every time slightly differently, every time something missing — and in three weeks that same client will ask about the one thing you happened to leave out.

Nobody calls this a problem, because it does not hurt. A breakdown hurts; this is a cost spread thin: forty minutes times twenty-one is almost two working days spent writing twenty-one versions of the same document. On top of that comes the invisible cost — uneven quality. Client number seven got a better start than client number twelve, because you signed the seventh on a Wednesday morning and the twelfth on a Friday evening.

This chapter is about the moment when you stop being a craftsman who answers every situation afresh and become someone who answered once — well — and now uses that answer. This is not a move towards corporate life. It is a move to protect attention: a system exists so that you have something left to think with for the things that genuinely require thought.

One misunderstanding is worth setting aside at once, because it makes many people skip this chapter. A system does not mean more tools, more tables, more process. On the contrary — a well-made system is usually one page and one recurring reminder. I know studios with elaborate knowledge bases where nobody can say what happens in the first week of a new project, and I know one-person businesses with three email templates where nothing goes missing. The difference does not lie in the size of the tool, but in whether the answer has been given once.

Motivation comes and goes. The system stays.

Source

The closest figure is the Great Work — magnum opus — in the version historians have returned to the laboratory. It was not a metaphor for inner development but a procedure: a staged operation on a starting material, tracked by changes of colour — nigredo, albedo, citrinitas, rubedo. The scheme is ancient, already traditional in Zosimos of Panopolis (c. 300 CE), who himself attributes it to Mary the Jewess. The reading that “it was really inner work” is nineteenth-century (Atwood, Hitchcock), popularised by Jung; Lawrence Principe and William Newman have shown that recipes from the period can be repeated in glassware, because they encode real chemistry.

More important than the scheme itself is what the sources do not contain: a single standard procedure. George Ripley counted twelve gates, Thomas Norton fourteen. After the fifteenth century most authors quietly abandoned citrinitas, absorbing it into rubedo — a whole stage of a supposedly timeless system dropped out of use. The literature was genuinely inconsistent, and every infographic promising “THE seven steps of alchemy” misrepresents it.

From the Emerald Tablet comes a second figure: the instruction to separate the subtle from the gross, “gently and with great care”.

The modern counterpart of the same intuition is better documented. The WHO study of the surgical safety checklist (Haynes et al., 2009; eight hospitals on four continents) showed a fall in complications and mortality after the introduction of a sheet with a dozen or so items. Later implementations — in the province of Ontario in 2014, among others — did not reproduce the effect where the checklist was introduced formally, without a change in the way people worked. Taken together, the conclusion from both studies is more cautious than from either alone: the procedure does not work. A procedure that is used works.

Our reading

This is our position, not the content of the sources. We read the Great Work as the work of procedure rather than inspiration: the same person, the same material, a repeatable sequence, an observable indicator of progress. The change of colour in the vessel is exactly what proof of operation is in a system — a checkable sign that a stage has been completed. The alchemist did not ask himself whether it seemed to be going well. He looked at the colour.

Hence the principle of this chapter: if a problem keeps coming back, do not solve it by hand every time — turn it into a system, a tool, a ritual or an asset. The threshold is practical: three times. The first time is an event, the second may be coincidence, the third is a declaration that it is going to stay with you.

A system — as we understand it — has four features:

• A trigger — it is known what sets it off. Not “when needed”, but “when a client signs the contract”.
• A procedure — steps written down concretely enough that someone who does not live inside your head can carry them out.
• An owner — one person or one machine. Not “the team”.
• Proof of operation — a trace by which you know the system has worked.

Without the fourth point you have hope, not a system. From the inconsistency of the old treatises and from the uneven results of the checklist we draw the same conclusion: the system that saves you is yours, not universal. And the first move is to separate the subtle from the gross — to separate, within a repeatable process, what requires judgement from what is merely execution. Judgement you keep. Execution you hand to the procedure.

Operational translation

Systems are built in layers. The order matters, because each successive layer is more expensive and less reversible than the last — and most people begin with the most expensive one.

Four layers

• Checklist. The cheapest thing there is. A sheet of paper or a note with the steps. It solves not a problem of skill but a problem of memory under load. Always start here.
• Template. A ready form to fill in: welcome email, structure of a proposal, scope of work, brief. A template is a checklist that has already done half the job for you.
• Automation. Something that happens without you: a form that creates the project folder; a payment reminder sent on the seventh day after the due date; a weekly report assembled from data that exists anyway.
• Handover. The highest layer: someone else runs the procedure. Only possible once the first three work — because you cannot hand over what you cannot describe.

What suits this, and what does not

Suitable: entering a project and leaving it, handing over files, pricing a repeatable type of work, collecting materials from the client, the weekly status, payment reminders, publishing, backups, the first week of a new person on the team. These are all things where inventiveness adds nothing and irregularity takes something away.

Not suitable: deciding whether to take a job, a conversation about price on an unusual project, a conflict in the team, the choice of a creative direction, the moment of telling a client that we are going no further. These are places for judgement, and a list of prompting questions is enough for them.

Three ways systems break

The theatre system. An elaborate space in a note-taking tool, twelve databases, handsome views — and all the real work still happens in email and in your head. You recognise it because nobody ever goes in there under time pressure. What you do not use in the worst week of the month is not your system.

The ownerless system. The procedure is written, the trigger is clear, but the person responsible is “someone”. In practice this means it is carried out by whoever is most bothered by its absence — which is usually the same, already overloaded person. That is not a system, it is a quiet tax levied on the most conscientious person on the team.

The unreviewed system. Built for conditions that no longer exist. A procedure from the time when there were three clients starts doing harm at twelve. Every system needs a review date — quarterly or half-yearly — and it needs the right to be deleted.

The rule of size

A system should be the smallest one possible. Not the most complete — the smallest that still works. Excess procedure costs exactly where it was meant to save: in attention. A good measure: if describing the system takes more than one page, you are probably trying to systematise two different things at once.

The right to delete

A procedure that has stopped matching reality is not neutral — it costs attention at every contact and quietly teaches the team that written rules are approximate. One system deliberately deleted is worth more than three kept out of habit. So it is worth recording two dates with every system: when it was created and when it will be reviewed. Without that second date nobody ever makes the decision to throw it out, because nobody has either the mandate or the moment.

Embodied check

A system promises something that can be checked physically: less held in the head. Working memory is narrow and expensive, and overloading it does not announce itself as the thought “I am holding too much” — it announces itself as tension in the shoulders, shallow breathing, and that particular irritability that arrives when someone asks you a simple question at the wrong moment.

Hence the first reading. Choose a recurring task and notice what happens in the body at the moment it begins. Pressure in the solar plexus? Held breath? The reflex to put it off? This is not a lack of character — it is a signal that the task requires reconstruction from scratch every time. A well-built system should lower that reaction within two or three repetitions. If after a month the tension is the same, the system is too big or it is not yours.

The second reading is less comfortable, because it concerns motive. Putting things in order can be a way of regulating anxiety. You recognise it by the asymmetry: building the system brings relief immediately, and using it never happens. If after a weekend spent rebuilding a tool you feel calm, but on Monday you do not open it, that was not a system — it was a soothing activity. No reproach in that; it is only worth naming, because otherwise it comes back every quarter.

The third reading is simple and decisive: test your system in the worst week, not the best. What you reach for when you are tired is the system. The rest is decoration.

The body is the first system that requires alignment.

Practice

A seven-day experiment: one system, one proof

We are not building a map of everything. For a week you take one thing from chaos to a trace — and check whether the trace appears at all.

Day 1 — inventory. Twenty minutes. Write out everything that came back at least three times in the last quarter. For each item, three columns: problem (one sentence in the language of facts, not judgements), trigger (an event or a date — if you cannot point to one, you have nothing to build yet), cost (hours or money per quarter, roughly, but as a number). The cost column decides the order.

Day 2 — one procedure. Take only the item with the highest cost. Write down three to seven steps in the imperative, the owner (a name or the name of a tool, never “the team”) and the proof of operation: the specific trace by which you will know the system has worked. The whole thing has to fit on one page.

Days 3–6 — use. Every time the trigger appears, you run the procedure from the page, even when you know the steps by heart. Note in a single word what chafed: a step too many, a step missing, a step in the wrong order.

Day 7 — reading. Three questions. Does the proof of operation exist for every case from this week? Did you use the system on the worst day of the week, or only on a calm one? What are you crossing out — because there is almost always one step to cross out?

Example. Problem: every new client gets a different start to the project, and some information goes missing. Trigger: a signed contract. Cost: about forty minutes per client plus two rounds of extra questions in the third week. Procedure: create the folder from the template · send the welcome email with the three fields filled in · put the kick-off meeting in the calendar within five days · send the list of materials with a date · mark the start date in the table. Owner: me. Proof: in the client table, every new row has the start date filled in.

What this practice does not promise. It will not make you an organised person — systems do not change character, they only take part of the load off it. It will not help when the problem is overload itself: at forty per cent too much work, a procedure will only mean you drown in an orderly fashion. And it does not work for things done once a year — there the cost of building exceeds the cost of doing it again from scratch.

Limits

There is a list of things we do not systematise, and it is worth having it said out loud, because the temptation always runs in one direction.

Judgement is not systematised. The decision on a large job, on committing to someone for two years, on closing a project. The attempt ends in one of two ways: either in a procedure nobody follows or — worse — in following it at the moment when thinking was required.

Rare and one-off things are not systematised. The cost of building exceeds the gain, and the mere existence of a procedure later suggests that the situation is familiar.

What lives off irregularity is not systematised. Curiosity, friendship, rest without a purpose, a long walk with no route, reading that is not meant to lead anywhere. These are not areas “not yet put in order”. They are areas that procedure simply kills — and without them the work system is left without the thing it works for.

The most serious case is a different one: a system that eats life instead of protecting it. You recognise it by the reversal of purpose. You start servicing your own procedure. The day is a good one because all the boxes are ticked, not because something important moved forward. In the evening you have order and nothing of your own. That is not a system failing — that is a system working too well towards a badly set goal.

And a more general limit, important for this whole book: not every recurring discomfort is a problem to be solved. Some things have to be waited out, some accepted, some left unresolved, because resolving them would cost more than the tension itself.

Not everything requires action. Not everything that can be changed should be changed.

Ethical question

Systems are rarely neutral towards other people, because almost every one of them moves a cost — the only questions are which way, and whether anyone agreed to it.

The first test: whom does this procedure save time, and whom does it cost time? A form that cuts ten minutes from your work and adds twenty to the client’s is an optimisation of your life at someone else’s expense. It can be justified. But it has to be named as such, and it is better said out loud than sold as a courtesy.

The second: is someone getting ownership, or only a duty? An ownerless system does not disappear — it falls on the most conscientious person on the team, quietly and without agreement. If someone is to maintain something, they must also have the right to change it and the right to say that it does not work.

The third concerns the people on the other side of the procedure. A template is honest as long as its recipient is not left believing they received something written for them. A service standard is honest as long as it is not used to avoid hearing a situation that does not fit it. The commonest quiet harm systems do is that the exception starts to be treated as a fault in the user.

And the fourth, the most demanding: does this system increase someone’s agency, or only my predictability? A procedure that takes away another person’s judgement in a matter they are responsible for is a form of exercising power, even when it was conceived as help. The more say you have over someone’s work, the more carefully this has to be checked.

Closing formula

A system is a form of care for your future self — for the version of you that will be tired, in the middle of a difficult week, without the spare attention to reinvent something you have already invented once. You build it today, calmly, for that day.

And so a good test of a system is not whether it looks elegant, but whether it survived the worst week of the quarter — and whether it left you with more life, not less.

The next chapter is about how to arrange time around these systems, so that a plan stops being a wish list and becomes an allocation of energy.