04. Competence Is a System Property

The Comfort of Indispensability

Every organisation has them. And they are hard to get around of.

The guru.
The superhero.
The rock star.

The person everyone "just asks."
The one who always jumps in during incidents.
The one leadership trusts instinctively.

At first glance, these people feel like a gift. At JPSoftWorks, we've worked with many of them. Hell, some of us have been them.

But here's the uncomfortable truth we've learned the hard way:

Indispensable people don't make systems strong. They make them fragile.

And the more DevOps‑minded an organisation claims to be, the more dangerous this fragility becomes.

Systems Thinking: Humans Can Be Constraints Too

In the previous tenet, we talked about constraints: the realities that limit throughput regardless of effort.

Some constraints are obvious:

• Slow test pipelines
• Manual approvals
• Limited environments

Others wear human faces.

If:

• Only one person can deploy safely
• Only one person understands production
• Only one person can handle incidents
• Only one person knows how security really works

Then that person is the constraint.

Not because they're incompetent.
Because the system funnels work through them.

DevOps doesn't eliminate constraints. It makes them visible: including the human ones.

The Bus Factor (Let's Name It)

We don't dance around this at JPSoftWorks. We call it what it is.

Bus factor: the number of people who would need to be hit by a bus before the system stops functioning.

A bus factor of one is not impressive.
It is a risk.

And yet, organisations dress it up with nicer words:

• "Guru"
• "Superhero"
• "Rock star"
• "Key person"

Same problem. Better branding.

Why Hero Culture Feels So Good (At First)

Let's be honest. Hero culture survives because it's rewarded.

For individuals:

• Recognition
• Status
• Job security
• Identity tied to being needed

For managers:

• One neck to choke
• Fewer people to coordinate
• Short‑term delivery optics
• A comforting illusion of control

Everyone wins: until they don't.

Because hero culture optimises for short‑term rescue, not long‑term flow.

The Hidden Costs of the Hero

Over time, the system starts paying interest on that dependency.

You see it as:

• Escalations always going to the same person
• On‑call fatigue concentrated on a few shoulders
• Automation stalling because "only X can touch that"
• Documentation lagging because knowledge lives in heads
• Missed SLOs when the hero is unavailable

And eventually:

• Burnout
• Attrition
• Or worse: silent failure

None of this is malicious. It's structural.

DevOps Means Shared Lifecycle Understanding

Here's where DevOps culture becomes non‑negotiable.

If DevOps is about uniting Dev and Ops, then everyone must understand the lifecycle end‑to‑end:

• How code gets built
• How it gets deployed
• How it fails
• How it's recovered
• How risk is managed

This does not mean everyone does everything.

It means:

• Developers understand operational consequences
• Ops understands development trade‑offs
• Security understands delivery pressure
• Product understands technical risk

Competence overlaps. Responsibilities remain clear.

Tribal Knowledge Is a Governance Risk

Let's talk governance for a moment.

Knowledge locked in someone's head:

• Cannot be audited
• Cannot be tested
• Cannot be transferred reliably
• Cannot be improved systematically

"Just ask Alice" is not a control.
It's a liability.

From a risk perspective, tribal knowledge is indistinguishable from undocumented infrastructure. Regulators, auditors, and CISOs all understand this: even when engineering teams don't.

DevOps maturity means treating knowledge like infrastructure: visible, maintained, and resilient.

Competence Mapping: Making the Invisible Visible

This is where we stop theorising and start engineering.

At JPSoftWorks, we use competence mapping not as an HR exercise, but as a system diagnostic.

The goal is simple:

Expose where the system depends too heavily on too few people.

The Competence Grid (Practical, Not Political)

The grid is intentionally simple.

Rows: Capabilities the system depends on
Columns: Real people
Cells: A 0-9 score representing ability

Not potential. Not titles. Ability to perform safely today.

Scoring Scale

9s are rare. If they aren't, the grid is lying. Try again.

Example Competence Grid

Green where strong. Red where fragile. When average scores are high, and few, you likely have a human constraint.

Reading the Grid (What It Tells You Immediately)

• Alice is a massive constraint
• Incident response has a bus factor of one
• Security depends on a single strong contributor
• Carol and Dave are disconnected from operations

This explains:

• Why incidents escalate
• Why automation stalls
• Why Dev and Ops feel separate
• Why Alice is exhausted

The grid doesn't accuse, but it reveals.

Cultural Rule #1: No Self‑Scoring Alone

This matters.

Scores must be:

• Peer‑reviewed
• Discussed openly
• Adjusted collaboratively

Otherwise the grid becomes political: and useless.

Psychological safety is a prerequisite. Without it, competence mapping will fail.

Closing the Gaps (Design, Not Pressure)

Once gaps are visible, the response is not "work harder."

Effective responses include:

• Pairing on real work
• Rotating on‑call with guardrails
• Writing documentation as work happens
• Automating fragile steps
• Creating paved roads and platforms (here's where all the "platform engineering", we hear about, comes from.

The goal is not to replace experts: it's to multiply and distribute them.

Automation as Knowledge Diffusion

Automation is often misunderstood as a productivity tool.

In this context, it's also a knowledge distribution mechanism.

Every automated step:

• Encodes expertise
• Removes reliance on memory
• Lowers the competence bar for safe operation

Automation doesn't eliminate humans. It frees them from being bottlenecks.

The Manager's Dilemma (And Responsibility)

This is where culture really shows.

Managers must:

• Stop rewarding indispensability
• Stop praising heroics as normal
• Protect people who share knowledge
• Make overlap visible and desirable

This is hard. It feels slower at first. It is slower at first. if it was easy, everyone would do it.

But it's the only path to sustainable delivery.

Failure Modes and Anti‑Patterns

• Promotions tied to being irreplaceable
• Documentation treated as optional
• Training disconnected from real work
• Heroes shielding the system from learning (aka black boxes)
• Silence rewarded over collaboration

Heroics are often a symptom of earlier system failure.

The Cultural Payoff

When competence overlaps:

• Incidents become calmer
• On‑call becomes humane
• Automation accelerates
• Trust improves
• Teams stop fearing absence

This is DevOps as lived experience: not tooling.

Concrete Implementation Angle

What works:

• Quarterly competence mapping
• Tie gaps to training budgets
• Automate where expertise concentrates
• Rotate responsibilities deliberately
• Review bus factor explicitly

Important habit shifts:

• Make knowledge sharing visible work
• Celebrate redundancy
• Treat learning as delivery

Subtle collaboration issues:

• Seniors unconsciously blocking growth
• Juniors afraid to expose gaps
• Managers mistaking calm for stagnation

Closing Insight

DevOps is not about creating heroes.
It's about making them unnecessary.

It's time to see, if your system depends on a few people, it is fragile.
If competence overlaps, it becomes resilient.

At JPSoftWorks, we don't ask who knows the most. We ask where the system is vulnerable: and then design it so no one has to carry it alone. And this is where DevOps becomes SecDevOps.

If all this feels uncomfortable, that's a good sign. It means you're looking at the system honestly.

If you want help mapping competence, reducing bus factor, or redesigning delivery around people instead of heroics, you know where to find us.

Links & References