I build systems for a living. Infrastructure, automation, the kind of plumbing that only gets noticed when it stops. So when autism arrived in our house, my instinct was the one you would expect: I went looking for the system.

I read the things. I looked at the apps. I found the products with the confident websites and the pricing tiers. And for a while I was quietly certain that somewhere out there was the right combination of tools that would make everything click.

What actually helped was almost aggressively boring, cost nearly nothing, and would make a terrible product page.

The stuff that worked

A laminated card with pictures on it, showing what happens next.

Not an app. A card. Because a card does not need charging, does not update itself into a different layout overnight, and can be held by someone who is not currently able to talk to you. It sits in one place, it always says the same thing, and it survives being thrown.

That was the pattern for nearly everything that ended up mattering. The winning intervention was consistently the low-tech one, and the reason was always the same: it worked when everything else had stopped working. Which, of course, is exactly when you need it.

Other things in the same category. Doing the same thing in the same order every morning, to the point of tedium. Saying what is about to happen before it happens, every time, even when it seems obvious, especially when it seems obvious. Having one bag that is always packed with the same items in the same pockets. Naming the ending of an activity several minutes before it ends rather than at the moment it ends.

None of that is insight. All of it is well-documented, and any occupational therapist would rattle off the same list without pausing. I am not claiming to have discovered anything. I am telling you that I had to learn it slowly, by trying the sophisticated version first and watching it fail.

Why I got it wrong

Here is the professional bias I brought to this, and I suspect I am not alone.

In infrastructure, when something is unreliable, the answer is usually more capability. Better monitoring, more automation, a smarter system that handles more of the edge cases for you. Sophistication is generally the direction of improvement.

That instinct is close to exactly wrong here. In this context, every additional moving part is another thing that can behave unexpectedly at the moment when unexpected behaviour is the entire problem. An app that redesigns its interface in an update has, from a certain point of view, broken a load-bearing part of someone’s day. A routine that depends on a device having charge has a dependency that a laminated card does not.

What you are optimising for is not capability. It is predictability, under conditions where predictability has already collapsed. Those are different goals and they pull in opposite directions.

The most useful reframe I found was this one: I am not building a system that does clever things. I am building a system that does the same thing, forever, including on bad days, including when I am tired and doing it badly.

The failure mode I fell into

For a while I over-engineered the scaffolding, and the scaffolding became its own source of stress.

There is a version of this where you build such an elaborate structure of routines and supports that maintaining the structure is a full-time job, and any deviation from it feels like a failure. I got a decent way down that road. The routine stopped being a support and started being another set of rules that could be broken.

The correction was to have fewer things and hold them harder. Three anchors that never move, and flexibility about everything else. Rather than a comprehensive system that covers every scenario and collapses when reality does not cooperate, a small number of fixed points that survive contact with a bad Tuesday.

That is genuinely a lesson from the day job, oddly enough. The reliable systems are rarely the clever ones. They are the ones with few enough parts that you can hold the whole thing in your head at three in the morning.

What I would say to someone at the start

You will want to solve it. That urge is not a character flaw, it is love with nowhere to go, and it will send you looking for the comprehensive answer.

There is not one. There is a slow accumulation of small things that work, discovered mostly by trying things that do not, and the useful skill is not cleverness but noticing. What actually helped on Tuesday? Do that again on Wednesday. Keep the ones that survive.

Some other things I wish someone had said plainly.

  • The boring intervention is usually the right one. If it seems too simple to be worth doing, that is often the tell that it will hold up.
  • Your consistency matters more than your technique. A mediocre routine applied identically every day beats an excellent one applied unevenly.
  • Write things down. Not for reporting or for anyone else. For you, so that in six months you can see the shape of what changed, because you will not be able to feel it day to day.
  • The system is allowed to be for you too. Some of what we do exists because it makes the day survivable for the adults, and that is a legitimate reason. A parent running on empty is not much use to anyone.

The bit I did not expect

It has made me better at my actual job, and I feel slightly strange saying so, because that is obviously not the point and I would rather have arrived at the insight some other way.

But I am measurably more patient with the slow, unglamorous work now. The documentation nobody reads. The runbook that is boring precisely because it needs to be followable by a tired person at an unreasonable hour. The change that makes a system less clever and more predictable.

I used to think of that kind of work as the tax you pay for the interesting parts. I do not think that any more. I think the unglamorous, repeatable, hold-up-under-pressure stuff is the work, and the clever parts are mostly ornament.

I learned that from a laminated card.