Is diversity in HPC still just a buzzword?

Is diversity in HPC still just a buzzword?

In this blog, Ayesha reflects on how HPC systems thinking can offer a useful lens for understanding inclusion, visibility, and participation in computing communities.

HPC conferences often feel like two realities sharing the same room.

On one side: extreme precision: distributed systems, scalability models, performance graphs, optimisation strategies.
On the other: a quieter imbalance: who is in the room, who speaks, and who is missing.

Everything in HPC is optimised… except the human system behind it.

That contradiction leads to a simple question:

Is diversity in HPC still just a buzzword or the one system we have not learned to optimise?

1. The uncomfortable mirror: systems vs communities

HPC runs on distribution. Problems are split, sent across nodes, and recombined with precision.
Communities mirror this structure.
People are the nodes: students, mentors, researchers, organisers, volunteers.
But disconnected nodes do not fail loudly; they slowly stop mattering.

2. When “efficient” systems still fail

In HPC, a single bottleneck degrades performance.
In communities, bottlenecks look like:

• you had to know someone
• this opportunity was never visible
• mentorship depends on luck

Conferences try to reduce this friction through high-bandwidth interaction, but:

bandwidth is not the problem; access is.

3. Parallel systems, unequal threads

HPC is built on parallelism: many processes, one outcome.
Careers in HPC are also parallel: research, publishing, teaching, networking, surviving.
But human systems do not self-balance.
Instead:

• visibility accelerates some paths
• silence slows others
• momentum compounds where it already exists

And this imbalance is often treated as normal behaviour.

4. When systems start to diverge: a modelling perspective

This intuition can be made more explicit through a simple systems model.
If team composition is interpreted as the number of perspectives in a system, and innovation speedup as output efficiency, two patterns emerge:

Homogeneous systems scale quickly but hit a saturation point where ideas reinforce rather than expand.

Diversity-optimised systems may introduce initial coordination cost but avoid early saturation by expanding the solution space.

The curve shows a clear divergence: homogeneous systems saturate early, while diverse systems continue to grow in effective output.
Homogeneity optimises for alignment. Diversity enables exploration.
This is where “diversity gain” appears, not as a social metric, but as a structural effect: exposing blind spots and avoiding local optima.

5. The myth of self-healing communities

In computing, systems are debugged and redesigned.
In communities, there is often an assumption that inclusion improves naturally.
It does not.
Because real bottlenecks are structural:

• invisible networks
• uneven mentorship scaling
• limited entry points into visibility

And unlike compute systems, these are not logged.
They are visible when people leave.

6. Diversity is a system property

Diversity is not a value layered onto a system.
It behaves like performance:

• shaped by architecture
• constrained by connectivity
• limited by bottlenecks
• amplified by design

If the system is poorly designed, diversity does not fail; it cannot scale.

7. So what does fixing look like?

Not awareness. Not intent.
Design.
The same questions apply as in HPC:

• Where are the bottlenecks?
• What limits scaling?
• Which nodes are isolated?
• Who carries a disproportionate load?

Conferences are network layers.
Mentorship is load balancing.
Visibility is throughput.

8. Final thought

We would not call a system well-designed if it collapses under scale or ignores bottlenecks.

So the question is not whether diversity in HPC is a buzzword.

It is this:
Why are we still treating the human system as if it does not require engineering?

---