Out of Browser courses

Ship one automation

Take one real process end to end, put it in front of people, and measure what it did for six weeks.

What this is

A capstone, not a course. There is no new technique here — everything you need has been covered somewhere else in the catalogue. What is new is that it has to survive contact with other people for six weeks, and you have to be able to prove what it did.

The output is portfolio-grade on purpose: a running system, a before-and-after with real numbers, an honest list of what it still cannot do, and a peer review from somebody who tried to break it.

What you need before starting

  • A real process somebody actually performs, with volume. Not a hypothetical one.
  • The ability to measure it — you will be asked for a baseline before you build anything.
  • Permission from whoever owns the process. This is the step people skip and regret.

The shape

Three lessons over six weeks: baseline, build and deploy, then measure and hand over. Most of the elapsed time is the system running while you do not touch it.

Module 0 — Choose the process

Most failed automations were doomed at selection, not at implementation. Free, and worth doing even if you never build the thing.

  1. What is actually worth automating — Three shapes that pay, three that punish, and how to tell them apart in ten minutes. (30 min)
  2. The value of a minute — Work out what the process actually costs before you decide it is worth six weeks of yours. (40 min)
  3. Permission, properly — The conversation people skip. It takes twenty minutes and it decides whether this survives. (30 min)
  4. Scope it to something you can finish — The version you can ship in a week beats the version you can describe in a meeting. (30 min)

Module 1 — Measure it before you touch it

A week of watching, which is the week that makes every number after it mean something.

  1. Measure it before you touch it — A week of doing nothing but watching, which is the week that makes everything after it mean something. (30 min)
  2. The distribution, not the average — The average instance is not the one that will break your system. The tail is. (40 min)
  3. The error rate nobody collects — How often the current process gets it wrong. Awkward to measure, and it protects you later. (45 min)
  4. The success condition, agreed and dated — One numeric sentence, signed off before either of you knows the answer. (30 min)

Module 2 — Build the boring version

The system that handles the core case, admits when it cannot, and can be watched. No cleverness until the boring version is beaten.

  1. The version with no model in it — Build the rules-based version first. Often it is enough, and it is always the baseline. (60 min, paid)
  2. Where the model earns its place — Use it for the part that is genuinely judgement, and nowhere else. (60 min, paid)
  3. The exception path is the product — What happens to the instances you cannot handle decides whether anyone trusts the ones you can. (45 min, paid)
  4. Make it observable before it is live — You cannot add monitoring to a system that is already producing wrong answers quietly. (45 min, paid)
  5. Replay last month — Before live inputs, run every instance from a month you already know the answers to. (45 min, paid)

Module 3 — Shadow, then switch

Run it beside the real process without acting on it, understand the disagreements, then take a fraction of the volume.

  1. Shadow, then switch — Build it, run it beside the old process without acting on it, and only then let it do anything. (35 min, paid)
  2. Read every disagreement — The shadow period's output is not a percentage. It is a pile of cases somebody has to read. (90 min, paid)
  3. Is the residual bounded? — The question that decides whether you ship: are your failures a class, or are they scattered? (60 min, paid)
  4. The rollback you actually tested — Written down is not tested. Do it, on a normal afternoon, before you need it. (45 min, paid)

Module 4 — Live

Somebody who is not you now depends on this. Four weeks of running it, watching it, and resisting the urge to keep changing it.

  1. The first week somebody depends on it — Watch, log, and change nothing you do not have to. (60 min, paid)
  2. Your first incident — Something will go wrong. How you handle the first one sets whether this system survives. (60 min, paid)
  3. What it costs to run — The bill, the attention, and the exception queue. Measured on the live system, not estimated. (45 min, paid)
  4. Ramp to full volume — From 10% to everything, in steps, with a reason to proceed at each one. (45 min, paid)

Module 5 — Six weeks later

The measurement that decides whether it worked, the handover that decides whether it survives you, and the write-up that makes it evidence.

  1. Six weeks later — The measurement that decides whether it worked, and the handover that decides whether it survives you. (30 min, paid)
  2. Attribute the change honestly — Something moved. Proving your system moved it is a separate piece of work. (60 min, paid)
  3. The handover that survives you — Somebody else runs it, checks it, stops it and fixes it. You do not touch the keyboard. (60 min, paid)
  4. What it still cannot do — The limitations section is what makes everything else in the write-up believable. (45 min, paid)
  5. The write-up — The portfolio piece. A running system, a defensible number, and an honest account of both. (90 min, paid)

Related writing