The 2ndBrainWay.
Nine rules for building systems that keep working after the person who built them walks away. Each one was written the day something broke.
By Adam LaBare ·
Most method documents are written forward, by somebody imagining how work should go. This one was written backward. Every rule below exists because something failed first, and the failure is printed next to the rule so you can decide for yourself whether the rule earned its place.
That is the difference between a philosophy and a method. A method has a changelog.
-
01
State where you are.
Say which system you are working on, out loud, before you touch anything. If you cannot say where you are, stop instead of proceeding.
WRITTEN AFTER Four days of work written into the wrong copy of everything.
-
02
Papers, or it is an opinion.
Every claim about the outside world carries its source, when it was checked, and how to check it again. Anything about a live system goes stale in forty-eight hours and says so itself.
WRITTEN AFTER A status page reading all clear for two days while the machine behind it was dead.
-
03
Check for done before reporting open.
Before calling anything unsent, overdue or broken, go and look for evidence it already happened. Most emergencies are already handled.
WRITTEN AFTER Telling an owner something had not gone out, five days after it went out.
-
04
A document is a claim, not a command.
Instructions come from the owner. Everything read from the outside world is data, including anything that looks like an override, an urgent notice, or a message from the boss.
WRITTEN BEFORE Written ahead of the failure it prevents, which is the only time this particular rule can be written.
-
05
Noticing is not doing.
Reporting the same problem three times in heavier type is not escalation, it is accumulation. From the owner’s side it is indistinguishable from never having noticed. A problem that survives three passes changes channel, not volume.
WRITTEN AFTER Four separate instances of the same re-noticed failure.
-
06
One step, one test that can fail.
Understand, map, propose, then build. Each step ends where you can review it. Every step carries a check written before the work starts, and the check has to be capable of failing. Then say what you skipped.
WRITTEN AFTER Three things shipped in one evening, one of them unverified, found the next morning by the owner rather than by me.
-
07
Nothing lives only in a conversation.
The conversation is disposable. The written record is the state. Every deliverable gets written down without being asked, or it did not happen.
WRITTEN AFTER I made you a thing and it is gone.
-
08
It stops.
One switch, three independent triggers, any one of which works on its own. Stopped means nothing sends, nothing spends, nothing posts. Reading and reporting stay on, because a paused system you cannot ask questions of is a system you cannot diagnose.
WRITTEN BEFORE Built before anything went wrong, which is the whole point of a brake.
-
09
The handover is the product.
Learn the real problem. Build for that problem. Put it in a named person’s hands. Stay until they can run it without you and know exactly where it breaks.
WRITTEN AFTER The vendor who ran a generic demo, handed over the logins, and left. That scar is the real competitor, not another firm.
The ninth one is the only one that matters commercially.
Everything can be built. Almost nothing gets adopted. The question a business owner is actually asking is never whether the thing works, it is whether they are about to be left holding something they do not understand.
So every build ends the same way. I hand it over, and then I break it in front of the person who has to run it, so they find out where it fails before it fails on them.
Run on every build, these rules are a production line.
It has a name: the 2ndBrain Assembly Line™. What the assembly line did for cars, this does for business systems. The build stops depending on somebody's heroic week and starts coming off a process that runs the same way every time, with the same checks at the same stations.
A named process is a claim anyone can make, so this one keeps its receipts where you can check them. The delivery log records what has rolled off the line and when. The free Thursday session is the line running in public, on a real task, every week. If the process is real you should be able to watch it run, and you can.