Functional Safety Lead

Who we are  Atoms is building the machines that power the next era of progress. Over the last decade, software has transformed the digital world. But the physical world, where food is made, minerals are mined, goods are moved, and industries are run, remains far less intelligent, far less efficient, and far more constrained. We’re changing that. Atoms builds Physical AI— real-world robots for the industries that move civilization forward, starting with food, mining, and transport. Our systems are designed to understand, predict, and control the real world with precision, turning complex physical operations into something more reliable, more scalable, and more productive. This work requires more than robotics. It requires deep integration across hardware, software, AI, operations, manufacturing, and real estate. We don’t just build machines in a lab. We deploy them into real environments, operate them, learn from them, and improve them until they work at scale. We are roboticists, engineers, operators, and builders. We believe the next great technology companies will not only transform information, but the physical systems that shape everyday life. If you want to work on hard problems with real-world impact, join us. About the role This role owns the functional safety analysis of our automated vehicle platform and its sensor suite: what can fail, how it manifests, what the system does about it, and whether that response is good enough. You will do the analysis yourself, and your assessment informs releases. It also owns something that often goes unowned — determining the safety impact of change. We move constantly, and someone has to be able to say quickly and credibly what a given change does to the safety argument. That is this role. The third part is leverage. The safety case engineers work from your method: the analysis structures they adapt to their own scope, the library of platform-level safety items they reference instead of re-deriving, and the traceability they query. The job is not finished when your analysis is correct — it is finished when the method is executable by someone who is not you. What you’ll do Own hazard analysis and risk assessment for the platform — derive safety goals and requirements, drive them into the architecture, and maintain the traceability from hazard to requirement to verification evidence. Lead fault and failure analysis across the platform — compute, power and actuation interfaces — and across the sensor suite, covering both hard faults and degraded modes. Own sensor suite safety: sensing sufficiency and degradation — what coverage exists, how it erodes under adverse conditions, and how faults are detected and handled. Determine the safety impact of change. Hardware revisions, sensor swaps, software releases, new platform variants and changes to the operating domain all move the safety argument, and you decide what each one costs. Own change impact assessment — what triggers an assessment, what depth each class of change warrants, what evidence clears it, and what escalates — and keep it fast enough to stay on the critical path. Own the method the safety case engineers work from: reusable analysis structures they adapt to their own scope, a library of platform-level safety items they reference instead of re-deriving, and queryable hazard-to-evidence traceability. Ship tooling they run themselves rather than analysis you run for them — change-impact triage that flags which arguments a given change touches, automated traceability checks, and detection of where an argument has gone stale. Working AI-native We expect this role to be materially more productive than the same role was three years ago, and we expect AI tooling to be the reason. We are adopting systems purpose-built to accelerate safety analysis — failure mode generation, gap checking across large analyses, and interrogation of large requirements and standards corpora — and this role is expected to put them to work and shape what they become. Use them as a working instrument in the analysis itself: generating and stress-testing failure mode candidates, cross-checking analyses for gaps, interrogating large requirement and standards corpora, and first-pass triage across a large change surface. Build your own tooling rather than filing tickets for it, and keep it running once other people depend on it. Be rigorous about the boundary. A generated failure mode list is a hypothesis to verify, never evidence. Safety claims require human judgment and traceable justification. We would rather hire a strong functional safety engineer who is curious and moving fast on AI tooling than someone who has the vocabulary but not the practice. Be prepared to show us how you actually work. What we’re looking for 8+ years in functional safety for automotive, automated vehicles, aerospace, industrial automation, or another safety-critical hardware domain, with deep hands-on analysis experience rather than process oversight alone. Demonstrated ownership of HARA, FMEA, and FTA on real systems that shipped. We will go deep on specific analyses you have authored. Strong standards fluency: ISO 26262, ISO 21448 (SOTIF), and UL 4600 — with the judgment to apply them proportionately rather than performing compliance theater. Experience making release-gating safety calls under time pressure with incomplete information, and the ability to explain both your framework and a time you got it wrong. Real hardware and electrical depth: sensors, actuation interfaces, power and grounding, wiring, EMC, redundancy architecture. You are comfortable at the vehicle with a schematic and a scope. Programming ability — Python or similar — sufficient to analyze field data, build your own tooling, and work fluently with an AI coding assistant. You have built something other engineers used — a tool, script, template or pipeline that colleagues adopted because it beat what th