If this body is reduced by 50% through the systematic exclusion of half the population, it loses three distinct things simultaneously.

Numbers: the documented shortage of infrastructure profiles is directly amplified. Fewer engineers capable of falling back means fewer clients capable of negotiating.

A different perspective: women entering technical fields bring statistically a more conservative relationship to risk, a tendency to question implicit assumptions, and stronger resistance to technological fashion effects. This perspective is precisely the one that sets hard limits — and precisely the one that "soft on hard limits" DevOps seeks to replace.

Institutional legitimacy: a 95% male professional body is more easily caricatured, marginalised, and replaced by a generic title ("DevOps engineer") that can be positioned as more modern, more inclusive, more open — while being less competent on the physical layer.

Official IAM examples use a limited set of first names. Female names appear: Jane, Alice, Adele, Patricia, Chloe. Male names appear: John, Bob, David, Jim, Chris, Eli. Apparently balanced — until contexts are examined.

Female names appear systematically in examples of basic user creation and restricted permissions. Male names dominate examples of administrator roles, AssumeRole, advanced permissions, role sessions in CloudTrail.

The canonical example of an IAM security problem features "John Doe" creating the risk — "Jane Doe" inheriting it passively. The woman as a dependent variable of the man's behaviour, in the code example the beginner engineer reads on their first day of AWS training.

While documentation normalises the male profile in advanced administration roles, HR departments seek "DevOps engineers" — a title that, as documented in "The Infrational Crisis", dilutes real operational competences. This DevOps profile is presented as more inclusive, more collaborative, more modern than SRE or systems administrator. It is also structurally less dangerous for hyperscalers — because it does not master the physical layer.

Four mechanisms converge toward the same result without requiring explicit coordination:

— The hostile culture of bare-metal infrastructure teams (documented)
— Masculine normalisation in technical documentation (documented)
— The replacement of SRE by DevOps in HR job titles (documented)
— The devaluation of hard limits as a necessary competence (documented in "The Infrational Crisis")

Four distinct mechanisms, four distinct actors, one unique result: the professional body most dangerous to hyperscalers is amputated by half and marginalised in the public debate on digital infrastructure.

Organisational psychology and risk management studies converge on one finding: mixed groups make better-calibrated risk decisions than homogeneous male groups. Not because women are "less courageous" — but because they statistically have less tendency to follow group effects (groupthink) that push homogeneous teams toward overly aggressive decisions. In infrastructure, refusing groupthink has a name: hard limits. The engineer who says "no, we do not migrate this critical workload to this cloud service before we have an exit plan" is the engineer hyperscalers do not want in the room.

The culture of homogeneous male technical teams is particularly vulnerable to fashion effects — the shiny technology, the quarter's framework, the architecture that fills conferences. This vulnerability is documented and exploited. Hyperscalers have built conferences (re:Invent, Google Next, Microsoft Build) that are machines for producing fashion effects favourable to their services. A more diverse professional body is structurally more resistant to these fashion effects — because diversity of perspective breaks the group dynamics that fuel them.

In a homogeneous team under conformity pressure, the question "but can we do without this cloud service if the relationship with the provider deteriorates?" is hard to ask. It goes against the collective enthusiasm. Mixed teams ask these foundational questions more readily — because diversity of perspective legitimises the questioning of implicit assumptions. This questioning is exactly what the Opération Dindon corpus calls hard limits. And it is exactly what dominant DevOps culture discourages.

Nocturnal on-call in infrastructure is presented as a neutral professional requirement. It is not neutral. In a society where domestic and parental load still falls predominantly on women, uncompensated and unstructured nocturnal on-call is a gendered filter. Women do not "leave" bare-metal because they do not want to. They leave because the infrastructure operational model was not designed to be compatible with a life outside the office. "The Pager and the Body" documented this mechanism without naming its gendered dimension. This study names it.

The progressive replacement of "systems administrator" or "SRE engineer" by "DevOps engineer" in job postings is not trivial for women. The "DevOps" title appeared in a recruitment context that explicitly valued the collaborative, cross-functional profile, less anchored in the server room. This profile was presented as more inclusive — and in image terms, it is. But in terms of expected skills, it erases precisely the physical layer that women could have mastered as well as men. The profession was made "more welcoming" by removing its most strategically important content.

Section 2 documented the bias in AWS example names. The same bias exists in YouTube tutorials, Udemy courses, and the examples in technical reference books. When a young woman learns to configure a Linux server and all the examples show "john@server:~$" in the prompt, she receives a subliminal signal: this console is not for her. This signal is not a prohibition. It is friction. And accumulated frictions discourage without ever formally forbidding.

Companies that want to correct the imbalance in their infrastructure teams do not have to wait for the market to do it. They can sponsor robotics clubs in nearby high schools. They can organise "infrastructure days" for final-year female students. They can mentor women in systems and networking HNC programmes. These actions cost little. They produce results over a 3-to-5-year cycle — not a quarter. They are the only diversity investments that work structurally.

The senior SRE who reads this study and recognises their own team in what it describes has a simple responsibility: make their team visible. Talk about their profession in schools. Invite female students to visit their server room. Share their own beginner struggles — the poorly connected cables, the failed configurations, the on-call nights. Show that this profession is learned, requires no particular gift, and is open to anyone who wants to practise it.