I love college football, and for years I’ve studied Nick Saban’s coaching philosophy, not just because of what he accomplished on the field, but because of how deliberately he built organizations capable of performing at an incredibly high standard.

I’ve also had the privilege of learning from him directly, and one principle has stayed with me because I see its parallel in business constantly:

Saban built extraordinarily sophisticated football programs. But sophistication wasn’t the starting point. The starting point was clarity.

That distinction matters far beyond football.

Because there is a significant difference between a sophisticated operating system and a complicated one.

I’ve spent more than 20 years building and scaling Marketing Operations, Sales Operations, and Revenue Operations organizations, and one pattern has remained remarkably consistent:

Companies rarely set out to create operational complexity. They accumulate it.

A team needs something, so they buy a tool.

Another team has a slightly different requirement, so they buy another.

Someone discovers a limitation and adds a point solution.

A new executive brings the platform they loved at their last company.

An AI product promises to solve something faster.

Another integration gets built.

Then the person who understood why half of it existed leaves.

Eventually, no one is completely sure why every tool is still there but everyone is afraid to turn anything off.

What started as a technology stack becomes technology sprawl.

Technology sprawl becomes architectural complexity.

And unmanaged complexity becomes technology debt.

But the technology itself usually isn’t the root problem.

There is nothing inherently wrong with having a large technology ecosystem.

Complex businesses often require sophisticated architecture.

The problem begins when sophistication becomes synonymous with accumulation.

Every meaningful component of the operating environment should have a reason for being there.

If I walked into your organization tomorrow and pointed to any strategic platform in your revenue stack, could your leadership team answer:

And perhaps most importantly:

If those questions are difficult to answer, you probably don’t have a technology problem.

You have an operating model problem.

This is why I have never believed transformation should begin with software.

Technology is an accelerator.

It will accelerate a good operating model.

It will also accelerate a bad one.

If Marketing and Sales define a customer differently, another integration won’t resolve the disagreement.

If nobody owns lead management, adding an orchestration platform won’t create accountability.

If lifecycle stages mean different things across your CRM, marketing automation platform, warehouse, BI environment, and engagement tools, connecting those systems does not create a shared data model.

It simply moves inconsistent data faster.

A beautifully automated process operating on bad data is still a bad process.

You can automate routing perfectly and send the lead to the wrong seller because geography was never standardized.

You can automate account matching and create duplicates because company records aren’t governed.

You can deploy AI throughout the revenue cycle and produce unreliable outputs because the underlying data environment remains fragmented.

The fundamentals still have to exist:

People need clear responsibilities.
Processes need accountable owners.
Data needs governance.
Technology needs an architectural purpose.

And all four need to operate as one system.

One of the most important questions an operator can ask is not:

Can this technology do it?

It is:

Those are very different questions.

Modern GTM platforms overlap heavily.

CRMs contain workflow engines. Routing platforms add scheduling. Data platforms add automation. Engagement tools enrich records. AI agents increasingly execute tasks that previously required deterministic workflows.

A platform being technically capable of performing a function does not mean that function belongs there.

Architecture requires deliberate choices.

When organizations skip those decisions, their architecture becomes an accidental consequence of whichever vendor happened to offer the right feature at the right moment.

That isn’t architecture. It’s accumulation.

One of the best examples I experienced firsthand was GitLab.

GitLab didn’t treat documentation as administrative overhead.

The Handbook was part of the operating system of the company.

The important principle wasn’t simply that documentation existed. It was that the documentation and the operating model were expected to remain aligned.

If the way the company operated changed, the source of truth changed with it.

You didn’t make a meaningful process decision in a meeting, announce it in Slack, and assume everyone would absorb the change through osmosis.

You updated the Handbook.

And everyone could (and was expected to) contribute.

That didn’t mean everyone could independently create their own operating model.

People could identify a gap, challenge an assumption, and propose a better way.

There was still ownership.

There was still review.

There was still an accepted source of truth.

That is an important distinction.

That is governance. Not bureaucracy. Because good governance doesn’t slow organizations down.

Ambiguity does.

Think about the organizational energy wasted when five people have five versions of the same process.

Which one is right? More importantly:

Who decides?

Now multiply that across hundreds of fields, integrations, routing rules, lifecycle definitions, scoring models, automations, and applications.

That isn’t agility. That’s operating debt.

This is where the Saban analogy becomes particularly useful.

A football team doesn’t put eleven talented players on the field and tell them to figure it out.

Every position exists for a reason.
Every player has an assignment.
Every assignment connects to what everyone else is doing.

Your technology ecosystem should operate the same way.

Your CRM, marketing automation platform, data layer, enrichment capabilities, orchestration technology, engagement platforms, warehouse, BI environment, and increasingly your AI layer each need a clearly defined role.

The boundaries between them need to be intentional.

Because architecture should not exist exclusively in the head of whoever originally built it.

Someone two or three years from now will have to reverse-engineer why something works the way it does.

Usually while it is already broken.

Specialized technology can create enormous value. Sometimes a dedicated platform is absolutely the right architectural decision.

The mistake is assuming that every local optimization improves the overall system.

Every new application brings more than its license fee.

It introduces another integration, data dependency, security surface, administrative requirement, renewal decision, potential failure point, and potential source of technical debt.

That means the standard cannot simply be:

Does it work?

The better standard is:

Sometimes the answer will be yes.
Sometimes the capability belongs in an existing core platform.
Sometimes two tools should be consolidated.
Sometimes a process should move into the data layer.
Sometimes the workflow itself needs to be redesigned.

And sometimes the answer is simply:

We don’t need this anymore.

That is why architecture requires judgment, not just procurement.

AI has dramatically lowered the friction required to introduce new capability.

Teams can experiment quickly.

Individuals can activate tools independently.

AI agents can operate across systems.

Vendors are expanding their footprints faster than traditional architecture and governance processes were designed to handle.

That makes operating discipline more important.

Not less.

Because AI still has to answer:

The more autonomous technology becomes, the more important the operating standard underneath it becomes.

You want experimentation.

You want Marketing discovering better capabilities.

You want Sales improving workflows.

You want Operations challenging assumptions.

You want employees finding uses for AI that leadership hasn’t considered.

But there must be a distinction between experimentation and infrastructure.

Anyone should be able to identify a gap.
Anyone should be able to propose a solution.
Anyone should be able to challenge the architecture.

But not everyone should independently introduce permanent infrastructure into the operating environment.

That is how you preserve innovation without allowing entropy to become the operating model.

This is the part organizations often underestimate. Governance isn’t an architecture diagram. It isn’t an annual software audit and it isn’t a committee that meets once a quarter and produces slides.

Governance requires decisions.

Sometimes that means saying no.

That does not make Operations the Department of No.

A mature operating organization should be able to say:

That is operational maturity.

Technology decisions are not permanent.

Your business changes.

Your customers change.

Your go-to-market motion changes.

Your platforms evolve.

Capabilities that required standalone software three years ago may now exist inside systems you already own.

Technology that was right for 50 sellers may become a constraint at 500.

And AI will continue changing the capability map.

That is why stack rationalization cannot be a one-time cost-cutting exercise.

It needs to become part of the operating rhythm.

Every strategic platform should periodically have to earn its place against the same standard:

Keep what earns its place.

Consolidate what doesn’t.

Replace what is holding the organization back.

Retire what no longer serves the system.

Invest where a genuine capability gap exists.

It’s the clearest operating system.

I don’t advocate simplicity because simplicity sounds elegant.

Some of the best architectures I’ve helped build have been highly sophisticated.

Sophistication is not the enemy.

Unintentional complexity is.

Mature systems have intentional boundaries.

They have accountable owners.
They have shared definitions.
They have a source of truth.
They have clarity about where business logic belongs.
They have standards for changing the system and mechanisms for challenging those standards when they stop serving the business.

That is what I take from Saban’s Process.

It isn’t about having the smallest playbook.

It is about making sure the fundamentals are sound, everyone understands their assignment, and the organization can execute what it already has before adding another play.

And it is what I took from operating inside GitLab’s Handbook-first culture:

Companies need the same discipline in how they build and govern their technology environments.

Then add complexity deliberately when the business genuinely requires it.

Because maturity isn’t measured by how much technology an organization has accumulated.

Complexity should be something your organization earns through necessity.