Lead Linux Platform Engineer

We run a fleet of 1000+ high-performance Linux workstations supporting engineering, ML, and research teams, and we’re investing in the platform that provisions, configures, secures, and maintains them ’re looking for a lead engineer to own that platform end to end, technically and architecturally.

This is the first of several planned hires. You won’t just build the system; you’ll define how it’s built, make the foundational tooling decisions, set the engineering standards the rest of the team will work to, and help hire and grow that team. You’ll have significant autonomy and a corresponding level of ownership.

The work spans configuration management (Puppet or a similar configuration management tool), network-based provisioning, fleet inventory, network access control integration, hardware lifecycle, and the security and operational tooling that keeps a large, heterogeneous workstation fleet consistent and reliable. This is a hands‑on lead role: you’ll be in the code and on the architecture, not managing from a distance.

These workstations support active research. Faculty and researchers depend on them for grant‑funded, deadline‑driven work, and they often have specific, non‑negotiable technical requirements. A core part of this role is engaging directly with those researchers: understanding what their work actually needs, translating it into a sustainable platform, and weighing technical decisions against research priorities, funding constraints, and the disruption any change incurs on people with deadlines.

• Technical direction: Set the architecture for fleet management: configuration management, provisioning, inventory, patching, network access, and security. Make and document the build‑vs‑buy and tooling decisions (provisioning platform, secrets management, observability stack), and own the tradeoffs.
• The configuration management platform: Own the Puppet (or Open Vox) codebase: module design, the role‑and‑profile pattern, Hiera data architecture, and the control repository. Establish the patterns the team will follow.
• The provisioning pipeline: Own bare‑metal provisioning from network boot through to a fully configured machine: PXE/iPXE, unattended OS installation, and the handoff into configuration management. Design it to scale and to be operated by a team, not a hero.
• Network access control integration: Partner with the network and security teams to integrate the workstation fleet with NAC (802.1X). Own the endpoint side: supplicant configuration managed through Puppet, device certificate enrollment and lifecycle, and solving the provisioning‑time access problem (provisioning VLANs, MAC Authentication Bypass, or equivalent) so bare machines can be imaged without compromising the access control posture.
• Hardware lifecycle and support: Own the hardware side of the fleet: define and maintain hardware tiers, validate new models and components (CPUs, GPUs, storage, peripherals) for Linux and driver compatibility, and automate firmware and BIOS management age vendor relationships, drive RMA and break‑fix workflows, and own hardware refresh and lifecycle planning.
• Fleet operations: Own inventory and reporting (Puppet
  
  DB), patch management and update orchestration, drift detection, and the day‑to‑day reliability of the fleet. Balance security currency against the reality that these machines have users on them.
• Security and compliance: Own the security posture of the fleet, covering secrets management, host hardening, audit logging, compliance baselines, and the endpoint contribution to network access control, and make sure auditability is designed in rather than retrofitted.
• Engineering standards: Establish infrastructure‑as‑code discipline:
  Git as the single source of truth, change through review, CI/CD for infrastructure code, and no manual changes on hosts. Set the bar the team will hold.
• Researcher engagement and requirements: Work directly with faculty and research staff to understand their technical needs (software stacks, reproducibility requirements, performance characteristics) and turn those into platform capabilities. Translate between research requirements and what the…