Systems Process Engineer, Energy Service

What to Expect

Energy Service spends significant bandwidth on process work that is software and systems craft. The internal GUID tool and product self-test scripts dominate field process demand; top Megapack and Supercharger procedures still own more than half of onsite productive steps (Millions of dollars in Y2Y labor in front of those tools). Tens of thousands of hours go to ECU swaps and “improficient” inverter and battery module replacements where time estimate, tooling, and procedure quality never closed the loop. This Systems Process Engineer owns OKRs that free design: service activity specs and first-pass-yield for product self-test scripts and the internal GUID tool, efficiency baseline quality and procedure validation, tooling/BETA process, and data collection via process integration—so field software and support systems carry the load instead of ad-hoc content tickets and heroics. (Mechanical process engineering is owned by a partner team; this role is the software/systems process counterpart.)

What You’ll Do

• Own systems process for product self-test scripts and the internal GUID tool. Write service activity specs and first-pass-yield formulas for top Megapack and Supercharger self-test procedures; audit shapes; release custom SW→HW tools, firmware, and procedure packages; drive internal GUID tool changes to engineering change proactively—and publish self-test health metrics so efficiency is visible, not anecdotal
• Make efficiency baselines and procedures trustworthy. Dynamic time estimates on high-volume self-test routines; deterministic pass/fail; investigate multi-quarter median failures with field tech champions; kill outliers before they become permanent labor
• Industrialize tooling and BETA. BETA tools through procedure + initial field trial; pre-usage inspection as the primary field tooling success metric; own full ecosystem rollout and vendor QC so tools ship ready, not “figure it out on site.”
• Integrate process into collection (signal, high-quality field data, service action symptoms, sensing and connectivity RCA paths)—training and call-center input that feeds OKRs, not one-off design bandwidth
• Drive specs for technician software and support systems that obsolete manual steps—auto-capture, guided workflows, and tooling hooks so the field does not re-enter what the system already knows
• Time-cost and first-pass-yield analysis on every change; fast, controlled releases of process/software packages; user profiles for electricians and service techs so “improficient” hours become first-pass success

What You’ll Bring

• Computer Science, Computer Engineering, or Electrical Engineering background (or equivalent) with real software skills—you treat process as software: versioned, testable, releasable, and owned
• Test automation and software-as-process fluency. You've automated validation, built release gates, and turned tribal field knowledge into deterministic checks (FRT, tooling QC, procedure packages, custom SW→HW tools)
• Software product development instincts. You've shipped user-facing tools or field software—requirements, iteration, launch, and post-launch metrics—not just written docs that sit in a library
• User profile and field behavior literacy. You design for how technicians actually work on hardware under site constraints, and you know when the right fix is software, tooling, training, or deleting the step
• You quantify labor (hours, $/Y2Y, improficient vs. standard), first-pass yield, and ROI—and you use that math to prioritize what ships
• Comfortable with rapid BETA → field trial → global rollout under change control. Bonus: energy storage/charging or embedded/service tooling exposure; cross-functional closer with design, EHS, product, and service