Senior Site Reliability & Software Engineering Manager

We need to output HTML fragment with sections: headings

for sections like About the role, Responsibilities, Requirements, Qualifications, Skills, Benefits, Pay, Schedule. We must include only sections that have real specific content. We must not repeat job title. Must not include Job ID etc. Must preserve all substantive info, no summarizing away detail. Remove boilerplate like cookie/navigation/legal/EEO etc. Also remove application instructions. We need to parse the posting. Key sections: - About the role? There's a description: "Built to set the gold standard for integrated AI infrastructure Crux AI is a newly formed...". That's about company and role. Could be "About the role" or "About Crux". The instruction says use headings like About the role, Responsibilities, Requirements, Qualifications, Skills, Benefits, Pay, Schedule. So we need to map content. We have: - What You'll Do (Responsibilities) - In This Role, You Will Build & Lead Senior Engineering Teams: (list of responsibilities) - SIGNALS OF SUCCESS (maybe could be under Responsibilities or Qualifications? It's about success metrics after timeframes. Could be under Responsibilities or maybe under Qualifications? It's more like expectations. Could be under Responsibilities as part of what you'll achieve. But we need to decide. - Experiences (EXPERIENCES, ATTRIBUTES AND MINDSET THAT INDICATE A GOOD MATCH) -> that's Requirements/Qualifications/Skills. - Nice To Have (Preferred, Not Required) -> could be under Qualifications or Skills as "Preferred qualifications". - Salary Range Information -> Pay section. - About Crux (benefits) -> Benefits section. We must not create sections with filler like "commensurate with experience". We have actual salary range? The posting says: "Salary Range Information The annual salary range for this position has been estimated based on market data and other factors. However, a salary higher or lower than this range may be appropriate for a candidate whose qualifications differ meaningfully from those listed in the job description." No actual numbers given. That's vague; it's not a specific range. According to rule: never emit a heading followed by filler/placeholder text (e.g., "commensurate with experience", "not specified", "N/A", "varies", "TBD") and never create Pay/Schedule/Benefits sections unless the posting actually states them. Since the salary range is not specified (no numbers), we should not create a Pay section. So we omit Pay. Schedule: not mentioned. So omit Schedule. Benefits: The posting includes "About Crux We offer generous base, bonus and additional incentive based compensation Health, dental, and vision coverage for you and your dependents Company-paid life insurance and disability Full suite of other optional benefits 401(k) Plan with 4% company match (USA employees)". That's specific benefits. So we can create Benefits section. Now we need to decide sections: About the role (maybe a brief intro), Responsibilities, Requirements (or Qualifications), Skills, Benefits. We must not repeat job title as heading. Use

for each section heading. We need to preserve all substantive information, not invent or summarize away detail. So we need to include the details as lists or paragraphs. We need to use

• for any list of duties/requirements/benefits, and

  for prose. We must not include boilerplate like cookie/navigation/legal/EEO etc. The posting didn't have those explicitly, but we should ignore any such. We need to output only HTML fragment. Let's extract content. Intro paragraph: "Built to set the gold standard for integrated AI infrastructure Crux AI is a newly formed, U.S.-based integrated AI infrastructure company created to remove the physical and operational constraints on consequential AI ambitions. Crux brings together power, high-density data centers, TPU silicon, networking, orchestration software, and ongoing operations as one integrated system. Crux is being capitalized to plan every layer together, develop each one to demanding standards, and operate the whole system with efficiency and reliability. That gives hyperscalers, frontier AI labs, sovereign customers, enterprises, and AI-native companies greater freedom to pursue the AI they are here to create. Crux AI is led by CEO, Ben Treynor Sloss, who spent over two decades in executive technical leadership at Google and founded the Site Reliability Engineering (SRE) discipline. At Crux AI, we treat operations fundamentally as a software engineering problem." That's about the company and role. Could be "About the role". We'll put that in a

  . Then "What You'll Do" heading? We'll use Responsibilities. Under Responsibilities: list of duties: - We are recruiting founding Senior Site Reliability and Software Engineering Managers to build and lead our initial fleet reliability engineering teams in Palo Alto, CA. - In this organization, there is no separate software development team. Your team owns the software, control plane, telemetry, and automated remediation controllers that keep multi-gigawatt TPU clusters provisioned, resilient, and continuously executing customer AI workloads. - This is a true hands-on, builder seat, not a supervisory position. - In the early days, you will write the first remediation controllers, set reliability baselines, and take initial pages yourself to stay close to the work before expanding your team. - You will lead an elite group of unusually senior software and reliability engineers: engineers with significantly greater technical and software depth than traditional operational SRE orgs. - You must thrive on independence and revel in ambiguity, turning unknowns into concrete engineering priorities in a fast-paced, high-growth environment. - While you will devise and participate in initial on-call rotations, your core mandate is to combine SRE disciplines with extensive AI/ML automation to drive operational pages down to zero. Then "In This Role, You Will Build & Lead Senior Engineering Teams:" with bullet points: - Recruit, lead, and mentor an initial team of senior software and reliability engineers across Palo Alto and Europe as fleet capacity ramps rapidly. - Automate Pages to Zero: Own fleet availability end-to-end; establish on-call rotations while relentlessly developing self-healing systems and predictive remediation to eliminate manual pages. - Embed AI/ML into SRE Disciplines: Apply agentic techniques, machine learning models, and automated diagnostic workflows extensively to telemetry collection, root-cause analysis, and predictive cluster recovery. - Own Bare-Metal & Fleet Lifecycle Software: Drive software engineering for bare-metal node provisioning, firmware deployment, thermal/stress burn-in validation, host/TPU health monitoring, and decommissioning. - Control Plane & Fabric Reliability: Own software reliability for cluster orchestration, scheduling, capacity allocation APIs, and high-performance TPU host/interconnect networks. - Define Observability & SLOs: Establish customer-facing SLIs/SLOs (job goodput, time-to-detect, node availability) and build the telemetry pipelines serving operators, executives, and customers. Then "SIGNALS OF SUCCESS" with timeframes: - After 60 Days In This Role: Baseline reliability framework defined (v1 SLOs, severity structure, change management); first AI/ML-driven automated remediation controller shipped to production; recruiting active for senior engineering hires in Palo Alto. - After 6 Months: First TPU cluster brought online under your team’s automated acceptance criteria; automated remediation pipeline running with pass rates tracked; observability v1 in daily production use; core senior team onboarded. - After 1 Year: TPU fleet operating against published customer SLOs; >90% of node/fabric faults automatically quarantined and remediated without human paging; team scaled ahead of rapid capacity ramps. These could be part of Responsibilities or maybe a separate section like "Success Metrics". But we only have allowed headings; we could put them under Responsibilities as part of what you'll achieve. Or we could create a separate section like "Expectations" but not allowed. So we incorporate into Responsibilities. Now Experiences/Attributes/Mindset: This is requirements. We need to capture: - 10+ years of software or infrastructure engineering experience, with 3+ years managing engineering teams owning direct production SLAs and on-call. - Deep SRE Discipline: Grounded in foundational SRE principles (SLOs, error budgets, blameless postmortems) paired with a strict "code over heroics" mindset. - Hands-On Technical Depth (SRE + SWE): Track record shipping production code in Go, Python, or C++, with hands-on systems expertise across Linux OS kernels, bare-metal provisioning, firmware, and/or high-performance networking fabrics. Extensive experience with distributed systems and open source software. - Extensive AI/ML Adoption: Active utilization of AI agents and automated LLM/ML workflows in modern software engineering and diagnostic operations. - Senior Talent Magnet: Track record of attracting, evaluating, developing and leading unusually senior software engineers who thrive in fast-paced, high-stakes environments. - Attributes: Possess a high tolerance for ambiguity. The first clusters will carry customer workloads while the SLOs are still being defined and the team is still being hired. You absorb that, translate unknowns into concrete near-term priorities, and never manufacture false certainty about reliability the data does not support. - Understands that the customer’s job is the unit of reliability. A node that is “up” while a training run stalls on a flapping link is down. You measure what customers experience — goodput, time-to-recover, lost progress — and hold the whole stack, and Google, to it. - Mindset Builder Mindset & Ambiguity: A true "builder, not supervisory" orientation; comfortable operating with high autonomy, navigating ambiguity, and establishing structure amidst rapid growth. - AI-Agentic First: Fluent with AI agents — or committed to becoming so quickly — and you embed them as first principles in how you and your team work, defaulting to agentic workflows before adding headcount or process. Nice To Have (Preferred, Not Required): - Hyperscaler / Neocloud Scale: SRE or fleet leadership at a hyperscaler (Google, AWS, Meta, MSFT) or neocloud (CoreWeave, Lambda, Nebius, Nscale) during rapid fleet ramps. - Accelerated Compute: Direct TPU experience or large-scale GPU cluster ops (NCCL collective debugging, RDMA/GPU-Direct, Slurm/Kubernetes AI schedulers). - Custom Fleet Tooling: Hands-on experience building custom remediation controllers, event-driven fleet management software (Go, NetBox/DCIM), or OpenTelemetry/Prometheus pipelines. - Facility Telemetry & Thermal Signals: Familiarity with high-density, liquid-cooled environments and integrating facility telemetry (power, thermal, flow) into compute health signals. - Customer SLAs & Reporting: Proven experience constructing customer SLAs/SLOs, credit mechanics, and executive/customer-facing reliability reviews. We could put these under Requirements (or Qualifications) and Skills. The instruction says we can use sections like Requirements, Qualifications, Skills. We need to decide mapping. We could have: - About the role (intro) - Responsibilities (What you'll do + signals of success) - Requirements (Experiences, Attributes, Mindset) - Preferred Qualifications (Nice To Have) - Benefits (About Crux benefits) We must not create sections with filler. All have content. We must not include Pay or Schedule. Now we need to format using

  headings,

  for prose,

  • for lists. We need to preserve all substantive information; do not invent or summarize away detail. So we need to keep the exact phrasing? We can keep the substance but not necessarily verbatim? The instruction: "Preserve ALL substantive information; do NOT invent or summarize away detail." So we should not omit any details. We can rephrase slightly but must keep all info. Safer to keep the original sentences. We'll break into paragraphs where appropriate. Let's craft HTML. Start with

    About the role

    then

    with the intro paragraph(s). Might need to split into multiple

    if needed