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

Why can I design ordinary devices but not the safety-critical or novel ones?

You have built competence. That is not nothing — most never reach it. But competence is a trained reflex, and reflexes fail exactly where there is no precedent to trigger them. A safety-critical design has no room for your reflex to be almost right. A novel one has no precedent at all. Both strip away the comfort of pattern-matching and leave you with only your reasoning. This is not a skill gap you can read your way out of. Notice what you actually fear. It is not the math. It is being wrong in a way that harms someone, or being wrong in public because no one has solved this before you. Name that plainly to your team instead of dressing it up as a technical gap. A team that pretends the fear is only technical will keep assigning technical fixes to a human problem. You are not alone in this room. Use that. The work of finding every way a system can fail, or reasoning through unmapped territory, is heavier than one mind should carry — and it was never meant to be carried by one mind. Choose to make the failure analysis a shared, structured act, not a private test of your competence.

◆ 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
Safety-critical and novel design require real technical method (failure-mode reasoning, first-principles frameworks) plus the courage work of owning irreducible uncertainty with a team, so knowledge leads slightly.
How the two dials adapt to you →
What’s really going on

The ordinary ones defeat habit, not judgment. The safety-critical and novel ones defeat you because no precedent carries the weight — you must reason from first principles and own the consequence alone. Stop looking for the missing technique. Choose the harder discipline: define the failure modes before you define the solution.

🔒 What you’ll build togetherUnlock by starting
A moveBefore any solution, write down every way the device could fail and who it harms — do this with your team, out loud, not alone in your head.
A moveWhen a problem is novel, say so plainly to your pod: 'there is no precedent here.' Stop searching for one that doesn't exist.
A moveAssign one person in your pod to argue against the design every session. Rotate the role so no one person carries the suspicion alone.
A moveSeparate the fear of being wrong from the work of checking your work. Do the checking regardless of how you feel that day.
A moveAfter each safety-critical decision, write the reasoning down in one page, as if explaining it to someone who will be harmed if you're wrong. Share it with the team before you act on it.
PractiseFailure-First Review · a Pod of 4 · 30 min

What changes unlock by starting

  • A shared, repeatable method for mapping failure modes before designing a solution
  • Less private dread around novel problems, because the uncertainty is now named and shared
  • A team habit of structured disagreement instead of silent doubt
  • Written reasoning you and your pod can stand behind, not just a design that happens to work
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.