Wide lanes, tall walls: designing better governance into GTM systems

I parent my kids with a wide lane and tall walls.

My daughter occasionally climbs onto the dining table to experiment with the career potential of base jumping.

My son likes to spray paint his brand new Hot Wheels. I don't tell him not to ruin them. I show him how to mask the windows first.

I'm not interested in turning every questionable decision into a battle. I care more about the walls. Is somebody actually going to get hurt? Are they about to create a problem they can't reasonably recover from? If not, they get a pretty wide lane.

Turns out I build systems pretty much the same way.

I want governance to disappear into the experience

I'm a big believer in what I call invisible governance. I'm sure there's a fancier term for it, but that's the one that makes sense in my head.

The best governance usually doesn't feel like governance.

It looks like the field you don't need never appearing. The impossible option isn't selectable. A phone number gets normalized before it breaks a routing rule. A risky record change stops for review while the boring ones run quietly in the background.

Nobody had to read a 14-page SOP. Nobody had to remember which exception applied. The system knew enough about the context to narrow the choices.

This is one reason I care so much about internal-tool UX. Your CRM workflow shouldn't feel worse than opening a recipe website and immediately getting hammered with 14 pop-ups. I've written before about treating your own team like real users in Confusion is the enemy. Governance is part of that same design problem.

If two fields conflict, I'd rather only show the one that makes sense for the record they're working on than let somebody fill out both and yell at them afterward.

Wide lane, soft shoulder, tall wall

I don't think every bad outcome deserves the same response.

There are roughly three levels I reach for.

Level	Use it when	GTM example
Wide lane	The choice is low-risk and easy to recover from	Let a rep organize notes or choose how they work an account
Soft shoulder	Something looks unusual, but a legitimate exception may exist	Warn on an odd stage change or route a conflicting enrichment value for review
Tall wall	The consequence is expensive, unsafe, hard to reverse, or compliance-sensitive	Block an impossible lifecycle transition or require approval before an AI agent makes a consequential write

The mistake I see a lot is building everything as a tall wall.

A field is entered wrong once, so we add a validation rule. Another exception appears, so we make the error message longer. Eventually the rep has to solve a small logic puzzle just to save an Opportunity.

Sometimes a validation rule is absolutely the right answer. Sometimes the system should warn. Sometimes it should quietly fix the value.

That distinction is built into the way I think about CRM normalization and validation rules: block, block and flag, flag only, or auto-correct and flag. The consequence should decide the enforcement behavior.

Make the wrong thing harder before teaching people not to do it

Documentation has a place. Training has a place. Neither should be the first line of defense against a predictable mistake.

Take something as simple as country values.

If a routing rule needs US, asking every person and integration to remember that USA, United States, and U.S.A. are wrong is fragile. Normalize the value.

The same principle applies to page layouts. If a field only applies to renewals, don't show it on a new-logo Opportunity and hope the rep remembers to ignore it.

It applies to defaults too. If 95 percent of records should follow one path, make that the default and let the unusual five percent opt out.

The system is already sitting between the person and the action. Use that position.

This is also why I think about CRM data quality as a reliability system, not a quarterly cleanup project. A cleanup fixes yesterday's records. Governance changes what happens to the next one.

Some disagreements should survive

Invisible governance doesn't mean the system should quietly decide everything.

Sometimes two values disagree because they represent two different kinds of truth.

Say an enrichment provider says a company has 3,000 employees and your CRM says 2,700. Fine. If the provider is the source you've chosen for firmographic data, that may be a safe automatic refresh.

Now say the same enrichment job wants to replace a CSM's health assessment.

Different wall.

A human-owned judgment field shouldn't be silently replaced because another system happened to write more recently. In my conflict resolution and overwrite policy, those disagreements route to review instead of being resolved behind the user's back.

The disagreement itself can be useful information.

A CSM saying "healthy" while a system-derived risk score says "high risk" may be exactly the thing somebody needs to investigate. Good governance doesn't erase that signal just to make the record look tidy.

AI makes the walls more important

AI turns this from a UX preference into an architecture decision.

You can give someone an incredibly capable tool and rely on them to remember every edge case, permission, and boundary.

Or you can build those boundaries into the experience itself.

The distinction I keep coming back to is simple: capability is not permission.

An agent may technically be capable of updating a record, changing ownership, sending an email, modifying an Opportunity, merging records, or deleting something. Those actions do not deserve the same level of autonomy.

I prefer an explicit ladder:

1. Read context and answer.
2. Read live CRM data.
3. Recommend an action for a human to take.
4. Propose a specific write and wait for approval.
5. Execute a narrow, constrained write.

You can get a lot of value before you ever reach step five.

I go deeper on that model in Permissions and safety for CRM AI agents. The important part is that the wall belongs at the tool boundary. A row-count cap enforced in code is a wall. A prompt saying "please don't update too many records" is a suggestion.

The more capable the agent becomes, the less I want safety to depend on somebody remembering what not to ask it to do.

Invisible shouldn't mean mysterious

There is one place where I don't want governance disappearing completely: consequential decisions.

If a workflow routes something for review, a field becomes locked, or an AI agent refuses an action, the user should be able to understand why.

Good governance removes unnecessary decisions. It shouldn't remove agency.

I want the safe path to be effortless, but I also want the wall to make sense when somebody hits it. "You can't do this because this account has an open renewal" is useful. "Validation rule 17 failed" is not.

The system can carry the rule without hiding the reason.

The test I use before adding another rule

Before I add another validation rule, approval step, or instruction to an SOP, I try to answer a few questions:

1. Can I make the bad choice impossible instead?
2. Can I make the correct choice the default?
3. Can the system safely correct it automatically?
4. Is the mistake easy to reverse?
5. Who absorbs the consequence if it goes wrong?

The higher the consequence and the harder the recovery, the taller the wall should be.

Most of the space inside those walls can stay pretty wide.

Or, in parenting terms, I'm not taking my daughter off the table.

I'm throwing a few pillows on the floor and telling her to go wild.

P.S. The soccer net is there to keep her from going behind the shed. But that doesn't stop her from trying.