Talk it through with Aurelius
Library›Aurelius›The problem
Aurelius · Work & Leadership
Knowledge + Guidance

Why does complex automation still trip me up?

You can write a script for one task. You do it well, and you know it. But string ten scripts together, add branches, timing, and other people's inputs, and it breaks. You don't know where. This is not a bigger version of what you already know. Scripting one task tests your syntax. Automation tests your judgment — where can this fail, and how would you know it failed? You are not meant to hold all of this alone. Your pod exists for the parts your own head cannot track. Use it. Do not debug in silence. Name the failure out loud, and let someone else look at it with you.

◆ How this problem reads on the two dials
GuidanceKnowledge
Coaching
More to learn
1:1 with AureliusWith others (a Pod)
Some one-to-one
Practise with peers
The problem needs a real method taught — decomposition and failure-isolation — before coaching on habits will hold any weight.
How the two dials adapt to you →
What’s really going on

You are not failing at automation. You are failing to break it small enough to be sure of. Stop writing the whole script and testing it once. Write the smallest piece that can fail, test it with your pod, confirm it, then add the next piece. Complexity is built one certainty at a time.

🔒 What you’ll build togetherUnlock by starting
A moveTake the automation apart on paper before you touch the keyboard. Name every step that could fail.
A moveBuild one piece, run it alone, and confirm it works before you connect it to the next.
A moveAssign one pod member to try to break each piece before the group moves on.
A moveWhen it fails, find the smallest test that shows exactly where — not the whole pipeline at once.
A moveKeep a shared log of every failure and its cause, so the pod learns it once, not five times.
PractiseBreak the Machine · a Pod of 4 · 30 min

What changes unlock by starting

  • You isolate failures in minutes instead of hours.
  • Your pod builds automations that fail loudly instead of silently.
  • You stop rewriting whole scripts and start replacing single broken pieces.
  • You trust your automations because you tested them piece by piece, not because you hoped.

Related problems

One object, two jobs: a public answer to a real problem, and — the moment you start the chat — Aurelius’s live plan for your version of it.