Governance Without the Monolith

Published on Jul 8, 2026

Governance Without the Monolith

Governance is not the enemy. Bad governance is the enemy.

Governance is not the villain. But monolithic governance can be more than villainous in the wrong environment.

Let’s get something out of the way early:

Governance is not the villain.

I know. That sentence probably caused a bunch of young agile coaches to clutch their sustainably sourced notebooks and stare into the middle distance.

But it’s true.

Governance is not the problem.

Rather, BAD governance is the problem.

The kind that:

• shows up late.
• asks for evidence nobody captured.
• treats every change like it has the same risk profile.
• turns release readiness into a theatrical performance where everyone says “green” while quietly hoping nobody asks a follow-up question.
• believes control is something you add to delivery after the fact, like a compliance garnish sprinkled over a plate of operational chaos.

That, my friends, is not governance.

That is ceremony with a clipboard.

And regulated industries — especially Financial Services — cannot afford that nonsense.

They need ACTUAL governance.

They need traceability, testing evidence, release discipline, and operational resilience.

They need accountability.

And they need someone, somewhere, to be able to answer one very simple question with something better than vibes:

What changed, why did it change, how was it tested, who approved it, what risk remains, and why is it safe to release?

That machine-gun rapid-fire six-question burst is not anti-agile.

Those questions are about giving agile a little more adult supervision.

The problem is, most governance models in hybrid delivery are either too heavy to be useful or too weak to be trusted.

And somehow, both versions still manage to waste everyone’s time.

The goal is not less governance. The goal is better governance…with less drag.

The Short Version

If you only remember four things from this article, make them these:

• Regulated delivery does not need governance theater. It needs decision-useful governance.
• The best governance models increase confidence without strangling flow.
• Risk, evidence, readiness, and release posture should be visible continuously, not reconstructed in panic near the end.
• Hybrid delivery needs governance designed for hybrid delivery, not waterfall controls stapled onto agile teams.

Why Governance Comes Next in This Series

In the first article, I argued that Financial Services will not become pure agile, at least not any time soon.

This is not because people are lazy.

Nor is it because transformation failed.

Things are this way because the constraints are real.

In the second article, I argued that the handoff problem is not really a communication problem.

It is a system design problem.

This article goes after the next ugly truth:

Most organizations know they need governance, but they have not designed governance for the hybrid delivery model they are actually running.

So they improvise…

• They keep the old gates.
• They add agile ceremonies.
• They create new dashboards.
• They build release checklists.
• They ask teams for more evidence.
• They hold more readiness meetings.
• They build more reports to explain the reports.

Then, everyone acts surprised when delivery starts moving like a parade float stuck in wet cement.

Governance matters. It has to.

But the way most organizations implement it is a mess.

The problem is not that governance exists. The problem is that it was designed for a different delivery reality.

The Lie We Tell About Governance

The popular story is that governance slows everything down.

That is the easy complaint.

It is also incomplete.

Bad governance slows everything down, for sure.

But good governance should:

• accelerate the right decisions.
• make risk visible earlier.
• clarify readiness.
• reduce late surprises.

It should help teams understand what matters, what does not, what needs evidence, what needs approval, and what can move without organizing a constitutional convention.

The purpose of governance is not to make delivery slower.

The purpose of governance is to make delivery safer, clearer, more accountable, and more predictable.

Those are good things.

The problem is that many governance models confuse control activity with control value.

A meeting is not governance.

A checklist is not governance.

A dashboard is not governance.

A signature is not governance.

Those things might support governance.

But only if they help people make better decisions.

If they do not, they are just artifacts.

And enterprises love artifacts.

In fact, some organizations produce artifacts the way pigeons produce consequences.

Regulated Delivery Actually Does Need Governance

Let’s not pretend otherwise.

Financial Services environments operate under real expectations around technology risk, operational resilience, security, third-party risk, auditability, continuity, and evidence.

— DORA establishes a digital operational resilience framework for EU financial entities and focuses on ICT risk management, incident handling, resilience testing, third-party oversight, and the ability to withstand and recover from disruptions. source

— FFIEC guidance for financial institutions includes examiner focus areas around architecture, infrastructure, operations, development, acquisition, maintenance, governance of technology risk, and change control processes. source

— NIST’s Secure Software Development Framework makes the same broad point from a security angle: secure development practices need to be integrated into the SDLC rather than treated as a detachable afterthought. source

So no, you cannot run a serious regulated technology organization on team autonomy, sprint demos, and motivational posters about empowerment.

That is not a delivery model.

That is wishful thinking with a Jira board.

Regulated delivery needs governance because regulated delivery has consequence.

A defect in a payments flow is not the same as a typo in an internal lunch menu app.

A bad release in a banking, insurance, wealth, claims, ledger, compliance, customer identity, or transaction platform can create customer harm, regulatory exposure, operational disruption, financial loss, reputational damage, and visits from some non-nonsense people wearing expensive shoes.

Governance exists because the blast radius is real.

The trick is designing governance so it protects the enterprise without making delivery teams feel like they are dragging a filing cabinet through a swamp.

Where Governance Goes Wrong

Most governance failures fall into one of three buckets.

1. Governance shows up too late

This is the classic pattern.

Development runs.

Testing catches up.

Release planning gets nervous.

Governance enters the room near the end and asks:

• What changed?
• Where is the evidence?
• Which requirements were tested?
• Which defects remain open?
• Who approved the exception?
• Which dependencies are still exposed?
• Why is this safe to release?

Those are not bad questions.

In fact, they are exactly the right questions.

The problem is timing.

If you ask those questions only at the end, you are not governing delivery.

You are conducting an archaeological dig with executive visibility.

That is how release readiness becomes a scavenger hunt.

And the worst part?

Everyone involved may have been working hard.

The evidence may exist.

The decisions may have happened.

The risks may have been discussed.

But the system did not capture the story as the work moved.

So now everyone gets to reconstruct it under timeline duress and extreme pressure.

That is not governance.

That is punishment, disguised as control.

Evidence captured late is evidence reconstructed under duress.

2. Governance treats every change like the same animal

This is where governance gets vry silly.

Not all changes are equal.

A copy update on a low-risk internal page is not the same as a payment processing change.

A logging enhancement is not the same as a customer authentication change.

A backend configuration adjustment is not the same as a cross-platform release touching policy, billing, claims, data feeds, and downstream reporting.

And yet, plenty of organizations govern work as if every change deserves the same path through the same gates, the same meetings, the same reviews, and the same evidence burden.

That is lazy control design.

Risk-based governance is not optional in a mature hybrid delivery model.

It is the only sane way to avoid turning governance into a factory that produces resentment.

A good governance model should ask:

• What is the blast radius?
• What customer or operational impact is possible?
• What regulatory or compliance exposure exists?
• What systems are touched?
• What dependencies are involved?
• What evidence is required?
• What level of approval is appropriate?
• What can move quickly because risk is low?

That is governance with judgment.

The alternative is governance by template.

And governance by template is how low-risk work gets dragged through high-friction processes while high-risk work still manages to hide in plain sight.

Impressive, in the worst possible way.

3. Governance measures activity instead of readiness

This one is everywhere.

Teams complete checklists.

Status remains green.

Meetings happen.

Documents are uploaded.

Approvals are collected.

Dashboards glow.

And somehow, nobody can confidently answer whether the release is actually ready.

That happens because many governance models measure activity instead of readiness.

They track whether the process happened, not whether the process produced confidence.

There is a difference.

A release readiness review that confirms ten artifacts exist is not the same thing as a release readiness review that explains whether the integrated release is safe.

A dashboard that says testing is 92% complete is not the same thing as knowing whether high-risk capabilities are validated.

A control approval is not the same thing as understanding residual risk.

This is why governance needs better signal design.

DORA software delivery metrics are useful here because they frame delivery performance around both throughput and stability, including change lead time, deployment frequency, failed deployment recovery time, and change fail rate. source

Governance has to care about that same balance.

Not just “did the gate happen?”

But:

• Is work flowing?
• Is risk visible?
• Is evidence current?
• Are dependencies controlled?
• Are defects understood?
• Is release confidence improving?
• Are we making better decisions earlier?

That is a much better conversation.

Also, it has the minor benefit of actually being useful.

Activity tells you the process moved. Readiness tells you whether the release can proceed.

Governance Theater

Let’s call this what it is.

Governance theater is what happens when an organization performs control without actually improving decision quality.

Governance theater looks mature right up until reality walks on stage.

It looks like maturity.

It feels like discipline.

It produces a lot of artifacts.

But underneath, the same risks keep showing up late, the same dependencies keep surprising people, the same environments keep colliding, and the same release conversations keep turning into emergency group therapy.

Governance theater usually has a few recognizable symptoms:

• meetings that exist because nobody trusts the data
• dashboards that report status but not truth
• gates that ask for evidence after the evidence should have been captured
• controls that apply equally to trivial and high-risk changes
• approvals that prove attendance more than judgment
• red risks that stay red until someone finds language clever enough to make them amber
• teams that spend more time reporting on delivery than improving delivery

If you have seen this movie, you know the ending.

Everyone says the governance model is mature.

Then release week arrives and the whole thing starts making the kind of noises usually associated with farm equipment that has never been maintained.

Governance Gaps

The opposite failure is just as dangerous.

Some organizations reject heavyweight governance so aggressively that they create governance gaps.

They move fast.

They empower teams.

They reduce gates.

They decentralize decisions.

They tell everyone to be agile.

Those are all good ideas, but only up to a point.

If the organization never replaces old governance with a better-designed model, governance aimed purely at speed and empowerment will almost always create a vacuum.

And in large delivery programs at scale and pace, vacuums get filled by:

• inconsistent approvals
• unclear readiness definitions
• undocumented exceptions
• fragmented evidence
• late risk escalation
• uneven testing discipline
• production surprises
• heroic intervention

That is not enterprise agility.

That is unmanaged variance.

Pure agile governance often struggles in environments where integrated releases, shared environments, audit evidence, third-party systems, operational resilience, and regulatory expectations still matter.

Financial Services cannot just hope team-level agility magically rolls up into enterprise readiness.

Hope is not a control.

And it usually performs poorly under the scrutiny of an audit.

Everything is green. Somehow, the release is still on fire.

What Good Governance Should Actually Do

Good governance should do five things.

1. Clarify decision rights

Who can approve what?

Who owns release risk?

Who accepts residual risk?

Who decides whether a dependency is closed?

Who can approve an exception?

Who determines whether evidence is sufficient?

This sounds basic.

In reality, it is far from basic.

Large hybrid programs often have enough ambiguity around decision rights to power a medium-sized consulting engagement just to formalize alignment.

Clear decision rights reduce churn.

They reduce escalation noise.

They reduce fake consensus.

They prevent the situation where everyone is “aligned” until someone has to make an actual decision.

At which point the room suddenly develops the energy of a middle school dance.

2. Define readiness in plain language

Readiness cannot mean whatever each team needs it to mean that week.

A mature governance model needs shared definitions of readiness across the lifecycle:

• ready for development
• ready for integrated testing
• ready for release governance
• ready for deployment
• ready for production support

Those definitions do not need to be gigantic.

They do need to be clear, though.

And they absolutely need to be measurable and understandable by humans who did not help write the 73-slide operating model deck.

Lastly, they need to detect the right risks, as early as possible.

3. Capture evidence continuously

Release evidence should not be recreated at the end.

Testing evidence, approvals, defect disposition, dependency decisions, exception handling, risk acceptance, and release readiness should accumulate as work moves.

— Audit-ready traceability depends on connected relationships between requirements, test cases, execution results, defects, and change history. Without those connections, release decisions rely on fragmented reports and manual updates. source

— In Financial Services, testing evidence itself often becomes part of the audit trail: what ran, against which build, by whom, when, with what result, and under what approval structure. source

That means evidence capture is not clerical work.

It is governance infrastructure.

If evidence matters to you, why not design the system to capture it?

Do not ask people to recreate it later while the release clock is already making everyone sweat.

4. Make risk visible early

Governance should surface risk early enough for people to do something useful with it.

That sounds obvious.

Apparently, it is not.

Too many governance models identify risk at the point where the only available options are:

• delay the release
• accept the risk
• add heroic mitigation
• pretend the problem is smaller than it is
• schedule an “alignment session,” which is enterprise code for “nobody wants to own this yet”

Risk visibility needs to move upstream.

Not so governance can slow work down earlier.

So teams can solve problems earlier.

That distinction matters.

Earlier visibility is not earlier bureaucracy.

It is earlier intelligence.

5. Protect flow

This is the part that governance teams sometimes forget.

The point of governance is not to maximize governance.

The point of governance is to help the delivery system move safely.

If governance creates so much drag that teams spend more energy satisfying the process than managing the actual delivery risk, the model has lost the plot.

Good governance protects flow by:

• scaling controls to risk
• reducing duplicate reporting
• using existing delivery signals
• removing unnecessary approvals
• clarifying decision paths
• preventing late evidence hunts
• making readiness visible without more meetings

Governance should not be a toll booth every team has to crawl through.

It should be a navigation system that helps people avoid driving the release into a ravine.

Good governance does not block flow. It helps teams avoid driving blind.

Risk-Based Governance: The Adult Version

Risk-based governance is one of those phrases everyone likes until they actually have to design it.

Governance should know the difference between a button-copy change and a missile launch.

The concept is simple:

Higher-risk work gets more scrutiny.

Lower-risk work moves with less friction.

The implementation is where things get messy.

A practical model needs to classify work based on factors like:

• customer impact
• regulatory exposure
• data sensitivity
• financial exposure
• operational criticality
• dependency complexity
• production blast radius
• reversibility
• control impact
• third-party involvement
• security relevance
• testing scope

That does not mean building a monstrous scoring calculator that requires a PhD, a legal opinion, and three approvals just to change the text of a button.

It means having enough structure to route work intelligently.

Governance should be able to tell the difference between a BB gun and a missile launch.

If it cannot, the model is not disciplined; it is simply indiscriminate.

And indiscriminate governance gets VERY expensive.

The Governance Data Problem

Here is where governance usually collapses into ritual.

The data needed for good governance exists.

It is just scattered everywhere.

It lives in:

• Jira
• Azure DevOps
• ServiceNow
• Confluence
• SharePoint
• Teams meetings
• test management tools
• CI/CD pipelines
• defect trackers
• dependency logs
• release calendars
• approval workflows
• deployment records
• production incident systems

The truth exists.

It just does not live in one place.

So governance compensates with status meetings.

And more reporting. Slide decks. Spreadsheets.

So many bloody spreadsheets.

And some poor person, usually very competent and quietly dead inside, becomes the human API across all of it.

This is one of the key reasons BRIDGE will matter later in this series.

A better governance model has to use the signals that teams already create.

Not by demanding fifteen more fields.

Not by creating some new process monastery where all delivery truth must be manually entered.

By connecting existing signals into a more useful readiness and risk picture.

Governance should become more signal-driven and less meeting-driven.

That is not a luxury.

That is the only way to scale without exhausting everyone involved.

The truth is usually there. Governance fails when the truth cannot be assembled in time.

The Problem With Governance Dashboards

Dashboards are not bad.

Bad dashboards are bad.

And enterprise delivery is full of them.

Some dashboards are basically decorative lighting for leadership meetings.

They show status.

They show colors.

They show progress bars.

They show percentages with suspicious precision.

They show enough green to make everyone feel briefly comforted, right before someone asks a real question and the whole dashboard starts smelling like smoke.

A useful governance dashboard should not just answer:

Are teams reporting green?

It should answer:

• Which changes carry the highest residual risk?
• Which dependencies threaten release readiness?
• Which evidence is missing?
• Which high-risk requirements lack test coverage?
• Which defects have release impact?
• Which approvals are still pending?
• Which exceptions were accepted?
• Which readiness criteria are trending worse?
• Which signals changed since the last review?

That is decision support.

Everything else is decoration.

BCBS 239 is not about software delivery governance directly, but its emphasis on accurate, comprehensive, timely risk data aggregation and reporting is very relevant to this conversation. Financial Services leaders need governed data that can support decision-making, especially when risk conditions change. source

The same principle applies to delivery governance:

If the data is late, fragmented, incomplete, or unclear, the governance conversation will be late, fragmented, incomplete, or unclear.

Technology leaders should not need a séance to understand release risk.

A dashboard that cannot explain risk is just decorative lighting.

Governance Without the Monolith

This is the central idea.

Organizations do not need a massive new governance monolith.

They need modular governance components that solve specific problems with minimal added burden.

Think smaller.

Sharper.

More targeted.

A better hybrid governance model should include:

1. Risk classification

Classify work intelligently based on impact, complexity, reversibility, regulatory exposure, and blast radius.

2. Readiness definitions

Create shared readiness criteria across development, testing, release governance, deployment, and production support.

3. Evidence mapping

Define what evidence is needed for different risk levels and capture it as work moves.

4. Dependency visibility

Treat dependencies as governed objects, not meeting-note trivia.

5. Exception management

Make exceptions visible, time-bound, owned, and tied to residual risk.

6. Release confidence scoring

Not fake mathematical certainty.

A practical, transparent readiness view built from evidence, risk, dependencies, testing, defects, and operational posture.

7. Governance signal automation

Pull signals from existing tools wherever possible.

Do not make teams carry governance on their backs like a compliance backpack full of bricks.

The future is not less governance. It is lighter, sharper, more useful governance.

What Governance Should Not Become

Let’s be clear about the anti-patterns.

Governance should not become:

• a paperwork tax
• a meeting factory
• a late-stage evidence hunt
• a universal slowdown mechanism
• a way for leaders to outsource judgment to checklists
• a shield for decision avoidance
• a dashboard theater production
• a compliance-themed maze no delivery team can navigate without a guide

Governance should never become a substitute for leadership.

That one is important.

A checklist can tell you whether evidence exists.

It cannot tell you whether the release is a good idea.

A dashboard can show risk indicators.

It cannot carry accountability.

A gate can structure a decision.

It cannot make the decision for you.

Human judgment still matters.

Governance should make that judgment better informed, not magically unnecessary.

The paperwork tax: somehow always due before value ships.

What Good Governance Feels Like

Good governance feels different.

It feels like clarity.

Teams know what evidence matters.

Risks surface earlier.

Dependencies stop hiding in the bushes.

Readiness reviews become shorter because fewer surprises need to be unpacked in public.

Leaders ask better questions.

Release decisions feel less performative.

Approvals have context.

Exceptions have owners.

Metrics connect.

Controls scale to risk.

And teams spend less time explaining work they already did.

That last one matters.

A lot.

Because when governance is designed badly, every team pays the tax.

When governance is designed well, the system gets smarter without making everyone more miserable.

That should be the bar.

Not “did we add control?”

But:

Did we increase confidence without adding unnecessary drag?

Bad governance creates motion. Good governance creates confidence.

Where This Points Next

This article is the third step in the series.

Article 1 established the reality:

Hybrid delivery is not a temporary embarrassment.

Article 2 exposed a symptom:

The handoff problem is really a system design problem.

This article tackled the governance layer:

Governance is not the enemy, but governance theater is expensive and governance gaps are dangerous.

The next article will go after one of my favorite forms of enterprise self-deception:

Metrics that lie.

Because if your metrics do not connect across the system, your governance will never tell the truth.

And if governance cannot tell the truth, release confidence becomes a costume.

A nice costume, maybe.

But still a costume.

After that, we can start introducing BRIDGE more directly.

Not as another giant methodology dropped from the sky.

Not as a shrine to process.

As a lightweight operating model for hybrid delivery that preserves context, captures evidence, surfaces signals, supports governance, and protects flow without crushing the people actually doing the work.

That is where this is heading.

And yes, I am aware that claiming to fix governance without building another governance monster is a dangerous thing to say out loud.

Good.

That means it is probably worth exploring.

BRIDGE starts where governance theater stops: with signals, evidence, flow, and confidence.

Final Thought

Governance is not the problem.

Bad governance is the problem.

Governance that shows up late.

Governance that treats every change the same.

Governance that measures activity instead of readiness.

Governance that asks teams to recreate evidence under deadline pressure.

Governance that creates more drag than confidence.

That is the stuff that needs to go.

Not because teams want to be reckless.

Because teams want to move.

Because leaders need truth.

Because regulated industries need evidence.

Because release decisions should be based on something stronger than green boxes and optimism.

The future of hybrid delivery is not governance-free.

That is fantasy.

The future is governance designed into the flow.

Risk-aware.

Evidence-driven.

Signal-rich.

Lightweight where possible.

Strong where necessary.

And allergic to theater.

As we get deeper and deeper, this still feels not only fixable, but also worth fixing.

Join the Conversation

Where does governance create the most drag in your delivery model?

Release readiness?

Evidence collection?

Dependency decisions?

Risk acceptance?

Approval gates?

Metrics?

Or somewhere else entirely?

I would love to hear the real-world version.

Not the policy-primer answer.

The thing that actually slows teams down, hides risk, or turns release week into organized panic.

About the Author

Joe Mack is a Technology Consulting Senior Principal specializing in enterprise SDLC transformation, release management, deployment governance, and delivery optimization for large-scale Financial Services technology programs. Joe is also a lifelong self-learner and builder of systems, and Free Tier Life is one of the ways he is trying to turn those experiences and instincts into something other people can actually use.

Bibliography

• European Banking Authority. "Digital Operational Resilience Act."
• FDIC / FFIEC. "Updated FFIEC IT Examination Handbook – Development, Acquisition, and Maintenance Booklet."
• FDIC / FFIEC. "Updated FFIEC IT Examination Handbook – Architecture, Infrastructure, and Operations Booklet."
• NIST. "Secure Software Development Framework."
• DORA. "DORA’s software delivery performance metrics."
• Louis Tadman. "Audit-ready traceability in software testing: Reducing release risk and strengthening compliance." Merito, May 22, 2026.
• Chris Faraglia. "Software Testing in Financial Services: Building an Audit-Ready Testing Practice." TestRail, June 25, 2026.
• Basel Committee on Banking Supervision. "Implementation of the Principles for effective risk data aggregation and risk reporting (BCBS 239 Principles)." January 6, 2026.