03. Constraints Rule the System

Effort Is Rarely the Limiting Factor

By the time organisations start talking seriously about DevOps, most teams are already working hard. Often too hard.

People stay late.
Backlogs grow.
Incidents feel more frequent.
Contexts switch too frequently.
And delivery still feels slow.

At JPSoftWorks, this is usually where we say the uncomfortable thing out loud:
if everyone is working diligently, effort is no longer the variable.

The system is.
And more specifically: the constraint is.

Systems Thinking: We Are All Slaves to Constraints

There's a simple rule in systems thinking that never stops being true:

A system can only move as fast as its most limiting constraint.

You can optimise everything else. You can hire more people. You can buy better tools. If the constraint doesn't move, neither does the output.

This applies to:

• Feature delivery
• Incident recovery
• Security remediation
• Platform reliability

Constraints are not optional. They are structural realities. The only real choice is whether we acknowledge them: or suffer around them.

The Factory Analogy (Still Uncomfortably Accurate)

In a factory, if one station can only process 10 units per hour and upstream produces 20, inventory piles up. The fix is never to yell at upstream workers.

You either:

• Add people at the bottleneck
• Add machines (automation)
• Redesign the process
• Or reduce incoming work

Software delivery works the same way: even if the work is cognitive and less visible.

Rushing development when testing, security, or operations are constrained doesn't increase throughput. It just increases Work in Progress, which we already know is the enemy of completion.

Constraints Hide...Until They Hurt

Constraints often operate quietly at first:

• A manual security review queue
• A single database expert approving every change
• Slow or flaky test environments
• Fragile pipelines
• Incident response owned by too few people, or only by "DevOps"

Then suddenly:

• SLOs start getting missed
• MTTR creeps up
• On‑call load spikes
• Releases get "paused for stability"

None of this is sudden. The constraint was there all along. We just weren't listening to the signals.

SLOs and SLAs: Constraints With a Stopwatch

This is where SLOs and SLAs earn their keep.

At JPSoftWorks, we treat SLO violations as system telemetry, not as failure reports.

Missed SLOs tell us:

• Capacity is exhausted somewhere
• Recovery paths are brittle
• Human load has exceeded sustainable limits
• Automation is missing at a critical point

And frequency matters more than absolutes.

A single miss might be noise.
A pattern of near‑misses is a warning.
A sustained breach means the constraint has shifted or worsened.

This applies to both:

• Product delivery SLOs (lead time, deployment frequency)
• System SLOs (availability, latency, error budgets)

Feature velocity without SLO health is borrowed time!

Governance Implications: Targets Reveal Reality

Governance without targets is opinion.
Targets without learning are punishment.

SLOs and SLAs give governance something concrete:

• Are we operating within agreed risk?
• Are we consuming error budgets faster than expected?
• Are teams compensating manually for systemic gaps?

When SLOs degrade, governance shouldn't ask "Who failed?"
It should ask "What constraint just became visible?"

That's how accountability stays blameless and effective.

Security as a Constraint (Measured, Not Assumed)

Security is often accused of being the bottleneck. In reality, it's usually an unmeasured one.

Once security activities are tied to observable signals:

• Time to remediate critical vulnerabilities
• Identity/key rotation SLAs
• Mean time to contain incidents

Patterns emerge quickly.

If security SLOs are consistently missed, the response isn't pressure: it's system redesign:

• Earlier controls
• Better automation
• Clearer ownership
• Smaller batches

Security becomes part of the flow instead of a wall at the end. This is in essence, SecDevOps, in a nutshell. Simple (but not easy)

Automation: Exploit the Constraint, Not Everything Else

Here's the rule we repeat relentlessly:

Don't automate what's easy. Automate where it hurts.

If SLOs show that recovery is slow, invest in:

• Runbooks as code
• Automated rollback
• Safer deploy patterns

If delivery SLOs degrade due to review queues:

• Policy‑as‑code
• Pre‑approved patterns
• Continuous validation

Automating outside the constraint feels productive and changes nothing.
Automating at the constraint shifts the entire system.

The WIP Connection (Again, Because It's Always There)

Unmanaged constraints create predictable behaviour:

• Work piles up in front of the bottleneck
• Teams start more work to stay "productive"
• Context switching explodes
• SLOs degrade further

Limiting WIP isn't about slowing teams down. It's about protecting the constraint so recovery and delivery remain possible.

This is where flow, WIP limits, and SLOs reinforce each other.

Failure Modes and Anti‑Patterns

We see these repeatedly:

• Treating missed SLAs as individual failure
• Chasing feature output while error budgets burn
• Optimising teams instead of flow
• Automating everywhere except the bottleneck
• Adding urgency instead of capacity

If SLOs degrade while effort increases, the system is screaming about a constraint.

Cultural Impact: Calm Through Clarity

Naming constraints: and tying them to real signals: changes culture.

Teams stop arguing opinions.
Leadership stops guessing.
Incidents stop being moral failures.

Instead, conversations shift to:

• What broke the system?
• Where is recovery slow?
• What should we automate next?

That's not bureaucracy. That's professional engineering.

Concrete Implementation Angle

What this looks like in practice:

• Define delivery and reliability SLOs together
• Track SLO breaches alongside flow metrics
• Use error budgets as prioritisation inputs
• Map SLO degradation to pipeline stages
• Review constraints explicitly in retrospectives

Important work habits to address:

• Stop treating SLOs as ops‑only concerns
• Make product and platform targets shared
• Invest improvement effort where SLOs point

Subtle collaboration issues:

• Feature teams consuming reliability silently
• Ops absorbing load without visibility
• Security carrying implicit SLAs no one agreed to

Closing Insight

Constraints are not failures. They are signals.

SLOs and SLAs turn those signals into data.
Data turns frustration into focus.
Focus turns effort into results.

At JPSoftWorks, we don't push teams harder when delivery or reliability slips. We look for the constraint that just became visible: and then decide whether to automate it, staff it, redesign it, or protect it.

If your teams are exhausted and your SLOs are drifting, let's talk. The system is telling you something important.

Links & References