Designing an AI infrastructure team: five functions, one sequence.

Fabric and networking owns the interconnect: topology, congestion, collective-communication performance. Platform engineering owns the internal surface other teams consume: scheduling, tooling, self-service. SRE owns availability as a commitment: error budgets, incident response, observability. MLOps owns the model lifecycle: training pipelines, artifacts, serving. Capacity planning owns the future: power, supply and demand reconciled into a buildable plan.

The functions are not seniority levels and they are not interchangeable. Each draws from a different talent pool, hires on different evidence, and clears at a different comp band. Treating them as one requisition family is the single most expensive mistake in this org design, because it produces a team that all thinks in the same layer while the failure modes live in the layers nobody owns.

• ●Fabric/networking: InfiniBand or RoCE topology, congestion, collectives
• ●Platform: scheduling, developer surface, adoption of internal tooling
• ●SRE: error budgets, incidents, observability under physical failure modes
• ●MLOps: training pipelines, checkpoints, serving latency, GPU utilization
• ●Capacity planning: power- and supply-constrained growth modeling

Sourcing follows the pool, not the title. Fabric depth sits in HPC labs, federal research computing, hyperscale network engineering and the silicon ecosystem, a small, largely non-searching population that responds to specificity about the cluster, not to the word 'exciting'. Platform engineers come out of internal developer platform teams at scaled software companies and convert well, provided the interview tests adoption rather than tool familiarity.

SRE is the deepest pool of the five and the most likely to be miscast: an SRE from a pure-software environment has rarely debugged an incident whose root cause was thermal, electrical or optical. MLOps splits into a research-adjacent half and a serving-adjacent half, and the two are not substitutes. Capacity planning is the thinnest pool of all and often comes from data center development, utility interconnection or supply chain rather than from engineering at all.

• ●Fabric: HPC and research computing, hyperscale networking, silicon ecosystem
• ●Platform: internal developer platform teams at scaled software companies
• ●SRE: broad pool, but screen explicitly for physical failure modes
• ●MLOps: research-adjacent (training) and serving-adjacent (inference) halves
• ●Capacity planning: development, interconnection and supply chain backgrounds

These candidates share vocabulary and tooling, so interviews must test ownership. Ask what they were paged for, what they built that others adopted, and what number moved because of their work. A platform engineer answers in adoption and toil removed; an SRE in incidents and budgets; an MLOps engineer in training throughput and serving latency.

The strongest single question in this whole org is: what did you personally do the last time the cluster was degraded and the cause was not in your layer? A candidate with real fleet exposure describes coordination with facilities, vendors and the network team, and can name the signal that told them where to look. A candidate whose experience is entirely abstracted describes escalating and waiting.

• ●Fabric: which collectives regressed, and what in the topology explained it
• ●Platform: what percentage of teams adopted the surface, and why the rest did not
• ●SRE: the error budget policy they enforced and the release it stopped
• ●MLOps: checkpoint recovery time and GPU utilization before and after
• ●Capacity planning: the plan they signed that turned out wrong, and why

First cluster landing: one operations-capable engineer and fabric depth. Researchers losing time to infrastructure: platform. Availability in contracts: SRE. Training and serving stabilizing: MLOps. Growth gated by power or supply: capacity planning. Hiring ahead of the constraint burns cash; hiring behind it burns the team's credibility with the people they support.

The sequence matters more than the headcount because each hire changes what the next one can be. A strong fabric engineer hired first makes the platform hire easier to scope and easier to sell, because the candidate can see what is already solid. A platform hire made first into an unstable fleet spends a year on firefighting they were not hired for, and leaves.

• ●Stage 1, hardware landing: fleet and fabric
• ●Stage 2, researchers blocked: platform engineering
• ●Stage 3, external commitments: SRE and on-call structure
• ●Stage 4, pipelines in production: MLOps
• ●Stage 5, power- or supply-limited growth: capacity planning

Almost every troubled AI infrastructure org I look at has one of four shapes. Recognizing yours is faster than re-running the org chart exercise.

• ●Three platform engineers and no fabric owner: everything works until the interconnect degrades, and then nobody can read it.
• ●SRE hired as a title, not a mandate: on-call exists, error budgets do not, and reliability stays a matter of individual heroics.
• ●MLOps absorbed into platform by accident: training pipelines get whatever attention is left after the developer surface, which is none.
• ●Capacity planning owned by finance alone: the model is accurate about money and silent about power, so growth commitments outrun the buildable plan.

Platform and MLOps promote well from strong internal software engineers who already know the workloads, provided someone senior owns the standard. Fabric and capacity planning rarely do: both depend on pattern recognition built over multiple builds and multiple failures, and neither can be learned on your schedule without an expensive teacher already in the building.

That asymmetry should drive the search plan. Spend external search budget on the functions you cannot grow, and spend management attention on the ones you can. Inverting that is how teams end up paying a premium for the easiest hire in the org.

Name the binding constraint in a number before opening any requisition, researcher queue hours, utilization, incident hours, or the gap between contracted and sellable capacity. Scope the first two seats against that number, and write the scorecard in evidence terms rather than tool lists. Then run both searches in parallel rather than in sequence, because the pools do not overlap and competing for them one at a time simply doubles the calendar.

Review the plan at day sixty against the same number you started with. If it has not moved, the problem is usually scope, not sourcing: the seat as written asks for a combination of evidence that fewer than a dozen people in the country hold.