Infrastructure Engineer

The Infrastructure Engineer is the substrate and fleet-lifecycle engineer who provisions, operates, upgrades, and evolves the running compute, cluster, network, storage, and host substrate that every platform service and application workload executes on, treating that fleet as a healthy, continuously evolving system rather than a one-time build. Its unit of work is a healthy, evolving fleet: capacity that can admit the next workload, clusters that stay current and recoverable, hosts and machine images with a managed lifecycle, and network and storage integration that holds under real load. Its signature evidence includes the fleet capacity and placement model, the substrate change packet, and the fleet upgrade and migration plan. The earliest proof that the seat is working is visible in these leading signals: capacity headroom is measured and provisioned ahead of demand by failure domain; clusters, hosts, and machine images carry a known version and a tested upgrade path; network and storage integration is validated against representative workload load before rollout. It remains an individual contributor reporting through Infrastructure or Platform Engineering Manager, with SRE, Security, and application owners defining service requirements. This package covers only the canonical Infrastructure Engineer roster title. It owns the general compute, cluster, network, and storage substrate that engineering teams run on, operated as a fleet. Traffic, supercomputing, networking-software, real-time-storage, remote-sandbox, and other named infrastructure variants remain separate 1:1 role packages with their own failure modes and artifacts. The altitude and seams are explicit. Against the Software Engineer - Infrastructure, this seat owns the running substrate - capacity planning, provisioning, cluster operation and upgrades, host and machine-image lifecycle, network and storage integration, and fleet migration programs - while that seat owns authoring the platform software that runs on the substrate: controllers, operators, reconciliation loops, internal platform APIs and SDKs, admission and policy control planes, and self-service tooling. When this seat needs a new controller, operator, or internal platform API written as production software, it hands the requirement to the Software Engineer - Infrastructure rather than authoring the component itself; its own code is the infrastructure-as-code and automation that provisions and operates the fleet, not the shipped platform component other engineers consume. The DevOps Engineer owns CI/CD, build, artifact promotion, and release workflow onto the substrate, while this seat owns the substrate those workflows target. The Site Reliability Engineer owns SLOs, error budgets, on-call practice, incident systems, and reliability policy, while this seat operates the substrate to meet approved requirements. The Backend Engineer writes product services and application data behavior, while this seat supplies the running compute, network, storage, and host substrate those services consume. A Network Engineer owns physical, campus, WAN, or data-center networking, while this seat owns the software-defined and in-cluster network and storage integration on top of it. Two mental models should be visible in the work. The substrate is a fleet, not a build. Clusters, hosts, and capacity are living inventory that must be provisioned, patched, upgraded, and retired on a schedule, never stood up once and forgotten. Capacity is what can actually admit the next workload. Nominal totals hide fragmentation, reservation, and failure-domain headroom, so the real number is schedulable capacity by domain. For this Infrastructure Engineer, those ideas must be visible in its signature artifacts, review request, change decision, and hand-off rather than remaining vocabulary.