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. Monolithic governance, in the wrong environment, can absolutely audition for the role.

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.

Still true.

Governance is needed.

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
• treats control like something you add after delivery, like a compliance garnish sprinkled over a plate of operational chaos

That, my friends, is ceremony with a clipboard.

Regulated industries — especially Financial Services — cannot afford that nonsense.

They need actual governance.

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

They need someone, somewhere, 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 six-question burst is not anti-agile.

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

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

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

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.

People are not lazy.

Transformation did not simply fail.

The constraints are real.

In the second article, I argued that the handoff problem is usually a system design problem dressed up as a communication 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.

The way many organizations implement it, though, 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 absolutely slows everything down.

Good governance should accelerate the right decisions, make risk visible earlier, clarify readiness, and 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 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 when they help people make better decisions.

Without that, they are just artifacts.

And enterprises love artifacts.

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 SDLC implementations rather than treated as detachable afterthoughts. source

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

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 very 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 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 exactly the right questions.

The problem is timing.

If those questions show up only at the end, the organization is not governing delivery. The organization is conducting an archaeological dig with executive visibility.

That is how release readiness becomes a scavenger hunt.

The worst part is that everyone involved may have been working hard.

The evidence may exist.

The decisions may have happened.

The risks may have been discussed.

The system simply did not capture the story as the work moved.

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

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 very silly.

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.

Plenty of organizations still 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 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.

Governance by template drags low-risk work 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.

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 does not necessarily explain whether the integrated release is safe.

A dashboard that says testing is 92% complete does not prove high-risk capabilities are validated.

A control approval is not the same 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.

It also 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 happens when an organization performs control without 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.

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, up to a point.

If the organization never replaces old governance with a better-designed model, the vacuum gets filled by:

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

That is unmanaged variance with better branding.

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 hope team-level agility magically rolls up into enterprise readiness.

Hope is not a control.

Hope also performs poorly under 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.

It is not.

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.

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

They also 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 governance infrastructure.

If evidence matters, 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.

Governance should not slow work down earlier just for the thrill of it.

The point is to help teams solve problems earlier.

Earlier visibility is intelligence.

Earlier bureaucracy is just bureaucracy with a calendar advantage.

5. Protect flow

This is the part governance teams sometimes forget.

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 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 teams already create.

Do not demand fifteen more fields.

Do not create a new process monastery where all delivery truth must be manually entered.

Connect existing signals into a more useful readiness and risk picture.

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

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.

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 merely 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.

Teams spend less time explaining work they already did.

That last one matters. A lot.

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?”

Try this instead:

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 necessary. Governance theater is expensive. Governance gaps are dangerous.

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

Metrics that lie.

If metrics do not connect across the system, governance will never tell the truth.

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

A nice costume, maybe.

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 probably means it is 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.

Teams do not want recklessness.

Teams want to move.

Leaders need truth.

Regulated industries need evidence.

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.

Allergic to theater.

As we get deeper and deeper, this still feels not only fixable, but 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 technology leadership, enterprise SDLC transformation, release management, deployment governance, and delivery optimization for household name Financial Services companies. 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.