Leadership | Roy Gabriel

When Management Layers Become Latency

Sat, 24 Jan 2026 10:30:00 -0500

Note on examples: The scenarios below are anonymized composites. This isn’t “management bad.” Good management is an accelerator. The problem is when management becomes layers of translation between reality and decisions.

Why this matters

In production systems, adding hops between a request and a response increases latency, failure modes, and debugging time.

Organizations behave the same way.

When engineering work flows through too many intermediary layers - tech leads, scrum masters, managers, senior managers, project managers, directors, senior directors, VPs, and beyond - the organization starts to exhibit the same symptoms as an over-proxied network:

long lead times
lost context (“telephone game” requirements)
local optimization (everyone looks busy; value doesn’t move)
coordination overhead that scales faster than delivery
engineers feeling like nothing they build reaches production

The painful part is that the org can look healthy on paper (status is green, roadmaps are full) while the product fails to meet real expectations.

This article is about the mechanics behind that failure - and the replacement patterns that restore flow.

TL;DR

Layers create handoffs. Handoffs create queues. Queues create lead time.
More roles don’t automatically increase throughput; coordination cost can dominate (Brooks’s Law). [6]
Fast flow requires end-to-end ownership with minimal handoffs (stream-aligned teams). [3][4]
Measure outcomes at the system level (DORA metrics), not “activity” (story points, number of meetings). [1]
Don’t turn metrics into targets (Goodhart’s Law). [7]
Burnout often rises when delivery is painful and risky; improving delivery capability predicts lower burnout. [2][8]

Pattern 1: Translation layers replace direct truth
Pattern 2: Status becomes the work
Pattern 3: “More people” is treated like a throughput solution
Pattern 4: Projectization and temporary teams
Pattern 5: Governance by meeting instead of guardrail
Pattern 6: Metrics as targets
Pattern 7: Engineers are abstracted away from production
Replacement patterns that work
Verification: how you know the org is healing
A practical checklist
References

Pattern 1: Translation layers replace direct truth

What it looks like

A customer need or operational pain moves through a chain:

customer -> product -> program -> project -> delivery manager -> engineering manager -> tech lead -> engineers

By the time it arrives at the team, it’s been translated multiple times and often loses:

the actual user story
the constraints
the real priority
the “why”

Why it exists

Layering feels safe:

fewer people “bother” engineers
leaders get curated information
decision makers see clean narratives

The hidden tax

Misalignment becomes normal.
Engineers build the wrong thing efficiently.
Product expectations aren’t met, not because engineers can’t build - but because the input signal is degraded.

The replacement pattern

Shorten the feedback loop.

Ensure teams have direct access to:
customer signals (support tickets, usage, interviews)
operational signals (incidents, latency, error budgets)
Make the “why” non-optional: put it in the ticket, the PRD, and the kickoff.

If a team can’t explain “why this exists,” it shouldn’t ship yet.

Pattern 2: Status becomes the work

What it looks like

Organizations that struggle to ship often compensate with:

more meetings
more dashboards
more decks
more “alignment sessions”

The output looks like progress, but the production system doesn’t change.

Why it exists

When uncertainty is high, visibility is comforting.

The hidden tax

Attention becomes scarce.
Engineers fragment into “meeting responders.”
Work becomes multi-tasked across too many initiatives (WIP explosion).

The replacement pattern

Reduce status overhead by making the system visible:

CI/CD dashboards
production telemetry
an engineering scorecard based on system outcomes (not activity)

DORA’s metrics are widely used as system-level indicators for delivery performance: deployment frequency, lead time, change failure rate, and time to restore service. [1]

Pattern 3: “More people” is treated like a throughput solution

What it looks like

A late initiative triggers:

new managers
new project managers
new engineers
more coordination rituals

Why it exists

It’s intuitive: more people should mean more output.

The hidden tax

Software delivery has a coordination component. Adding people increases communication paths, onboarding, and synchronization.

Brooks’s Law captures this succinctly: adding manpower to a late software project can make it later. [6]

The replacement pattern

Before adding headcount, reduce coordination load:

clarify ownership
shrink scope to a thin vertical slice
eliminate handoffs
stabilize requirements long enough to ship

Then scale with:

duplication (more teams owning similar streams)
platform leverage (paved roads), not more meetings

Pattern 4: Projectization and temporary teams

What it looks like

Engineers are repeatedly reorganized into short-lived “project teams,” and after delivery they are moved again.

Why it exists

Projects are easy to budget, track, and narrate.

The hidden tax

Temporary teams produce:

fragile ownership
weak operability
“throw it over the wall” incentives

Fast flow requires teams that own outcomes end-to-end with minimal handoffs.

Team Topologies describes stream-aligned teams as owning a slice of value end-to-end with no handoffs. [3][4]

The replacement pattern

Prefer stable teams aligned to a value stream (product/service), with:

clear ownership
operational responsibility (“you build it, you run it”)
direct feedback from users and production

Pattern 5: Governance by meeting instead of guardrail

What it looks like

Instead of “how do we make safe delivery easy,” governance becomes:

approval steps
committees
sign-off chains

Why it exists

Risk is real, and leaders want control.

The hidden tax

Humans are expensive control planes:

slow
inconsistent
difficult to audit at scale

The replacement pattern

Convert rules into guardrails:

policy-as-code
templates
paved paths
automated checks in CI/CD

This is how you scale safety without scaling meetings.

Pattern 6: Metrics as targets

What it looks like

Teams are pressured to hit:

story points
“velocity”
number of deployments
“percent complete”
tickets closed

Then behavior adapts to the metric.

Why it exists

Leaders need a dashboard.

The hidden tax

When a measure becomes a target, it can stop being a good measure (Goodhart’s Law). [7]

Examples:

inflate points
ship low-value changes to increase deploy count
avoid hard work because it hurts “throughput”

The replacement pattern

Use metrics diagnostically at the system level (not as individual KPIs).

If you adopt DORA metrics, use them to identify constraints and improve flow - not as quarterly targets for teams. [1][9]

Pattern 7: Engineers are abstracted away from production

What it looks like

A team builds a system, but:

another team deploys it
another team runs it
another team handles incidents
another team owns the roadmap

Engineers eventually conclude: “Nothing I build actually ships.”

Why it exists

Specialization can be useful, but excessive separation breaks feedback loops.

The hidden tax

teams don’t learn from production
quality declines because consequences are indirect
“deployment pain” rises: shipping becomes stressful and disruptive

DORA describes deployment pain as fear/anxiety around deploying and links it to poorer delivery performance and culture. [8] DORA also notes continuous delivery predicts lower levels of burnout and reduces deployment pain. [2]

The replacement pattern

Re-connect engineers to production:

give teams operational ownership for what they build
make telemetry and incident review part of engineering
reduce fear by making releases small, frequent, and observable

Replacement patterns that work

These are the patterns I’ve seen consistently restore delivery flow without chaos.

1) Clarify decision rights (and keep them close to the work)

One accountable owner per initiative (not “everyone is accountable”)
Engineers participate in tradeoff decisions early (scope, sequencing, risk)

2) Design teams for flow (not for org charts)

Organizations build systems that mirror their communication structures (Conway’s Law). [5] If your org is siloed and layered, your architecture often becomes siloed and layered too.

Design teams so the desired architecture is the path of least resistance.

3) Prefer stream-aligned teams + platform leverage

Stream-aligned teams own outcomes end-to-end (no handoffs). [3][4]
Platform teams reduce cognitive load by providing paved roads (auth, telemetry, CI/CD). [4]

4) Replace “alignment meetings” with shared artifacts

one-page decision records
clear “definition of done”
demos that show working software in a real environment

5) Turn delivery into a calm, repeatable process

When delivery is painful, people add layers to manage fear. Fix the source:

tests
automation
progressive delivery
observable releases

That’s how you reduce burnout sustainably. [2][8]

Verification: how you know the org is healing

Don’t rely on vibes. Use evidence.

Delivery outcomes (system-level)

Start with DORA metrics to track flow and stability. [1]

Product outcomes

adoption (are users actually using the thing?)
retention (does usage persist?)
reduced operational toil (do incidents go down?)

Team outcomes

fewer emergency escalations
fewer “status-only” meetings
improved on-call experience (lower deployment pain) [8]

If lead time drops but burnout rises, you probably “optimized the dashboard” instead of the system (see Goodhart). [7]

A practical checklist

If your org feels “management-heavy,” try this in order:

Reduce translation layers

Put engineers in the room (or thread) with real users/operators at least weekly.
Require the “why” to be written and reviewed before build starts.

Reduce handoffs

Map the value stream and count handoffs.
Remove one handoff per quarter; make it a goal.

Reduce WIP

Limit concurrent initiatives per team.
Finish before starting.

Convert meetings into guardrails

Replace approvals with automated checks where possible.
Create paved paths so the safe way is the easy way.

Reconnect teams to production

Teams own what they ship.
Tie incident learning back to design decisions.
Make releases smaller and more frequent.

References

[1] DORA - “DORA’s software delivery performance metrics (guide)”. https://dora.dev/guides/dora-metrics/ [2] DORA - “Capabilities: Continuous delivery” (notes relationship to burnout and deployment pain). https://dora.dev/capabilities/continuous-delivery/ [3] Team Topologies - “Key Concepts” (stream-aligned teams; no handoffs). https://teamtopologies.com/key-concepts [4] IT Revolution - “The Four Team Types from Team Topologies” (stream-aligned teams own end-to-end). https://itrevolution.com/articles/four-team-types/ [5] Splunk - “Conway’s Law Explained” (systems mirror communication structures; includes original quote). https://www.splunk.com/en_us/blog/learn/conways-law.html [6] Brooks’s Law (coined in The Mythical Man-Month): “Adding manpower to a late software project makes it later.” https://en.wikipedia.org/wiki/Brooks%27s_law [7] CNA - “Goodhart’s Law” (when a measure becomes a target, it ceases to be a good measure). https://www.cna.org/analyses/2022/09/goodharts-law [8] DORA - “Capabilities: Well-being” (deployment pain and its relationship to performance/culture). https://dora.dev/capabilities/well-being/ [9] SEI (CMU) - “How to Misuse and Abuse DORA Metrics” (metric anti-patterns). https://www.sei.cmu.edu/library/how-to-misuse-and-abuse-dora-metrics/

Agile Isn't Dead. Agile Compliance Is.

Wed, 31 Dec 2025 12:00:00 -0500

Note on examples: The scenarios below are anonymized composites. This isn’t “Agile bad.” It’s “Agile the brand is often used to justify systems that do the opposite of Agile’s intent.”

Why this matters

Agile isn’t a set of meetings. It’s a physics statement:

Shorter feedback loops reduce risk.

Most enterprises didn’t fail Agile. They replaced Agile with a bureaucracy that uses Agile vocabulary:

“Sprint” becomes a reporting interval
“Velocity” becomes a performance metric
“Planning” becomes a negotiation
“Definition of done” becomes a checklist
“Agile transformation” becomes a multi-year program

The result is predictable:

delivery slows
quality degrades
reliability suffers
engineers burn out
product expectations aren’t met
leadership gets more dashboards and fewer outcomes

This post is a production-first teardown of Agile theater - and a replacement model that actually ships.

TL;DR

Agile is about learning quickly, not predicting perfectly.
Scrum is useful when it reduces uncertainty. It’s harmful when it becomes a compliance system.
If you treat sprints as contracts, you’ll get scrumfall: waterfall dependencies with sprint-shaped reporting.
Replace “Agile compliance” with:
Flow (small batches, limit WIP)
Continuous delivery (safe, frequent releases) [4]
Evidence-based planning (measure outcomes; adjust quickly) [5]
Use system metrics (DORA) to verify improvement: lead time, deploy frequency, change failure rate, MTTR. [6]
Beware Goodhart’s Law: metrics used as targets will be gamed. [7]

Agile the physics vs Agile the bureaucracy
Pattern 1: Sprints as contracts
Pattern 2: Velocity as a performance metric
Pattern 3: Backlog bloat as a museum of anxiety
Pattern 4: Ceremonies become the work
Pattern 5: Dependencies turn Scrum into fiction
Pattern 6: Definition of done without production
Pattern 7: Product ownership by proxy
What’s better: Flow + CD + evidence
Transition plan: 30 days without a revolution
Verification: how you know it’s working
A practical checklist
References

Agile the physics vs Agile the bureaucracy

The Agile Manifesto values working software over comprehensive documentation and emphasizes collaboration and responding to change. [1] One of its principles states that working software is the primary measure of progress. [2]

Those ideas are still correct.

What broke in enterprises is implementation:

Agile became process instead of feedback
agile artifacts became deliverables
teams were optimized for predictability theater instead of throughput and learning

In short: Agile got turned into compliance.

Pattern 1: Sprints as contracts

What it looks like

Sprint planning is treated as a commitment contract.
Changing scope is seen as failure, even when reality changes.
Teams avoid surfacing unknowns because unknowns disrupt “commitment.”

Why it happens

Leaders want predictability. Sprints feel like a way to buy it.

The hidden tax

When you turn sprints into contracts, teams adapt:

reduce exploration
defer integration
accept low-quality shortcuts
split work into artificial “done-looking” chunks

You don’t eliminate uncertainty. You hide it until the end.

The replacement pattern

Use cadence as a heartbeat, not as a contract:

Plan in small chunks.
Commit to outcomes and constraints, not a stack of tickets.
Treat scope as a lever; treat time as a constraint.

Pattern 2: Velocity as a performance metric

What it looks like

Story points become productivity.
Velocity is compared across teams.
Teams feel pressure to “go faster” by increasing points delivered.

Why it happens

Velocity is a number. Numbers are tempting.

The hidden tax

Story points are a local measure with no consistent meaning across teams. When you attach incentives, teams optimize for the metric:

inflate estimates
split work to maximize points
avoid hard, high-leverage work
ship low-value changes

This is a textbook Goodhart’s Law failure mode: when a measure becomes a target, it ceases to be a good measure. [7]

The replacement pattern

Measure the system, not the story:

lead time
cycle time
deploy frequency
change failure rate
MTTR

Use metrics diagnostically, not as quarterly targets.

Pattern 3: Backlog bloat as a museum of anxiety

What it looks like

Thousands of backlog items exist “for visibility.”
Nothing gets deleted.
Refinement happens continuously, but priorities change weekly.

Why it happens

Backlogs feel like control: “We haven’t forgotten.”

The hidden tax

A giant backlog increases planning cost and reduces focus. Teams stop trusting priorities and operate on side-channel requests.

My favorite framing:

If everything is in the backlog, nothing is prioritized. It’s just a museum of anxiety.

The replacement pattern

Adopt a tight horizon model:

Now: what we’re building
Next: what’s likely next
Later: ideas (low-investment capture)

Refine Now/Next. Archive the rest.

Pattern 4: Ceremonies become the work

What it looks like

Standups become status meetings for managers.
Planning takes hours.
Refinement is endless.
Retrospectives generate action items that never get resourced.

Why it happens

Ceremonies are easy to schedule. Delivery capability is harder to build.

The hidden tax

Attention becomes fragmented. Engineers become “meeting responders.” Work gets multi-tasked across initiatives.

This is how you get:

slow delivery
low quality
burnout

The replacement pattern

Keep only the meetings that reduce uncertainty:

shorter planning
true async refinement
standup for coordination within the team (not reporting)
retros with real ownership and budget

Then invest in the thing ceremonies can’t replace: engineering capability (tests, pipelines, observability, automation).

Pattern 5: Dependencies turn Scrum into fiction

What it looks like

Every story depends on another team.
“Blocked” is normal.
Integration is deferred to later sprints.

Why it happens

Organizations are siloed. Systems mirror communication structures (Conway’s Law). [8]

The hidden tax

You get scrumfall: waterfall dependencies, sprint-shaped reporting.

A two-week sprint can’t save a three-month dependency queue.

The replacement pattern

Design for end-to-end ownership and flow:

reduce handoffs
remove or automate cross-team gates
create platform paved roads so teams can self-serve [9]

When dependencies can’t be eliminated, make them explicit and manage them like risk, not like hope.

Pattern 6: Definition of done without production

What it looks like

“Done” means “merged.”
QA is a phase.
Observability is optional.
Releases happen “later.”

Why it happens

Shipping is painful. So teams avoid it.

The hidden tax

If “done” doesn’t include production, you accumulate:

integration debt
release debt
incident debt

Reliability declines because feedback arrives late.

Continuous delivery’s core argument is that keeping software deployable and releasing frequently reduces risk and enables faster feedback. [4]

The replacement pattern

Upgrade your definition of done:

deployed to a real environment
observable (metrics/logs/traces)
rollback path exists
runbook exists for major failure modes

Pattern 7: Product ownership by proxy

What it looks like

Engineers rarely talk to users/operators.
“Product” is a chain of intermediaries.
Requirements arrive as polished tickets without the “why.”

Why it happens

The organization tries to protect engineers from churn.

The hidden tax

This degrades the input signal. Engineers build the wrong thing efficiently - and then everyone is surprised it didn’t land.

The replacement pattern

Bring engineers closer to reality:

listen to customer calls
review usage telemetry
participate in discovery
keep the “why” attached to every build

No one should ship something they can’t explain.

What’s better: Flow + CD + evidence

If Agile compliance is the disease, what’s the cure?

It’s not “a different framework.” It’s an operating model:

1) Flow: small batches, limited WIP

Lean/Kanban concepts focus on limiting work in progress and optimizing for flow. [3]

Finish work, don’t start work.
Reduce batch size.
Make queues visible.

2) Continuous Delivery: make change safe

Continuous delivery is a capability: keep changes small, deployable, and observable so you can release frequently with lower risk. [4]

This includes:

CI
automated testing
progressive delivery (when needed)
rollback/roll-forward discipline
telemetry tied to releases

3) Evidence-based planning: bets, not contracts

Lean Startup’s build-measure-learn loop emphasizes validated learning - ship something real, measure, and adjust. [5]

For enterprises, the translation is simple:

Plan in small bets
Validate early
Use evidence to re-plan, not politics

Transition plan: 30 days without a revolution

You don’t need to burn the framework down. You need to change what you reward and what you ship.

Week 1: Make work visible as flow

Map the value stream from idea -> production.
Count handoffs.
Measure current lead time.

Week 2: Reduce batch size

Pick one initiative.
Cut it to a thin vertical slice that can ship.
Define “done” as “in production, measurable.”

Week 3: Reduce WIP

Stop starting new work.
Finish the slice.
Remove one blocking dependency with a paved path or automation.

Week 4: Close the feedback loop

Ship.
Measure.
Run a retro focused on system constraints (not blame).
Repeat.

If you do this and nothing improves, you learned something valuable: the constraint is elsewhere.

Verification: how you know it’s working

You should see movement in system outcomes:

DORA describes four key delivery performance metrics: lead time for changes, deployment frequency, change failure rate, and time to restore service. [6]

Signs of real improvement:

lead time drops (less queueing and fewer handoffs)
deploy frequency rises (smaller batches, calmer releases)
change failure rate drops (better tests and safer rollouts)
MTTR drops (better observability and operability)

And importantly: teams report less “deployment pain” and less burnout as delivery becomes calmer and more reliable. [10]

A practical checklist

If you’re stuck in Agile theater, try this:

Stop measuring activity

Stop comparing velocity across teams.
Stop treating story points as productivity.

Shrink feedback loops

Ship a thin slice to production early (behind a flag if needed).
Put engineers closer to users/operators.

Reduce handoffs and WIP

Limit concurrent initiatives.
Remove one handoff per quarter.

Invest in delivery capability

CI, tests, deployment automation
observability tied to releases
safer rollouts and rollback paths

Use metrics as signals, not targets

Track DORA metrics at the system level. [6]
Avoid metric gaming (Goodhart). [7]

References

[1] Manifesto for Agile Software Development (values). https://agilemanifesto.org/ [2] Principles behind the Agile Manifesto (“Working software is the primary measure of progress”). https://agilemanifesto.org/principles.html [3] Kanban Guide (principles and practices oriented around flow and WIP). https://kanbanguides.org/english/ [4] Continuous Delivery (concepts; keep software deployable, release frequently). https://continuousdelivery.com/ [5] The Lean Startup - Principles (Build-Measure-Learn; validated learning). https://theleanstartup.com/principles [6] DORA - “DORA’s software delivery performance metrics (guide)”. https://dora.dev/guides/dora-metrics/ [7] CNA - “Goodhart’s Law” (when a measure becomes a target, it ceases to be a good measure). https://www.cna.org/analyses/2022/09/goodharts-law [8] Splunk - “Conway’s Law Explained” (systems mirror communication structures; includes original quote). https://www.splunk.com/en_us/blog/learn/conways-law.html [9] Microsoft Engineering Blog - “Building paved paths: the journey to platform engineering”. https://devblogs.microsoft.com/engineering-at-microsoft/building-paved-paths-the-journey-to-platform-engineering/ [10] DORA - “Capabilities: Well-being” (deployment pain and relationship to performance/culture). https://dora.dev/capabilities/well-being/

Leadership | Roy Gabriel

When Management Layers Become Latency

Why this matters

TL;DR

Contents

Pattern 1: Translation layers replace direct truth

What it looks like

Why it exists

The hidden tax

The replacement pattern

Pattern 2: Status becomes the work

What it looks like

Why it exists

The hidden tax

The replacement pattern

Pattern 3: “More people” is treated like a throughput solution

What it looks like

Why it exists

The hidden tax

The replacement pattern

Pattern 4: Projectization and temporary teams

What it looks like

Why it exists

The hidden tax

The replacement pattern

Pattern 5: Governance by meeting instead of guardrail

What it looks like

Why it exists

The hidden tax

The replacement pattern

Pattern 6: Metrics as targets

What it looks like

Why it exists

The hidden tax

The replacement pattern

Pattern 7: Engineers are abstracted away from production

What it looks like

Why it exists

The hidden tax

The replacement pattern

Replacement patterns that work

1) Clarify decision rights (and keep them close to the work)

2) Design teams for flow (not for org charts)

3) Prefer stream-aligned teams + platform leverage

4) Replace “alignment meetings” with shared artifacts

5) Turn delivery into a calm, repeatable process

Verification: how you know the org is healing

Delivery outcomes (system-level)

Product outcomes

Team outcomes

A practical checklist

Reduce translation layers

Reduce handoffs

Reduce WIP

Convert meetings into guardrails

Reconnect teams to production

References

Agile Isn't Dead. Agile Compliance Is.

Why this matters

TL;DR

Contents

Agile the physics vs Agile the bureaucracy

Pattern 1: Sprints as contracts

What it looks like

Why it happens

The hidden tax

The replacement pattern

Pattern 2: Velocity as a performance metric

What it looks like

Why it happens

The hidden tax

The replacement pattern

Pattern 3: Backlog bloat as a museum of anxiety

What it looks like

Why it happens

The hidden tax

The replacement pattern

Pattern 4: Ceremonies become the work

What it looks like

Why it happens