Three years buying ServiceNow. Seven years selling it. Ten years watching the same pattern repeat, from both sides of the table.

I call it the permission window. It opens the moment a new platform lands, and it closes faster than almost anyone expects.

Here's what nobody tells you when you buy a platform: you're not just buying software, you're buying its opinion about how your people should work. Every enterprise platform ships with a process already baked in — a default way of doing the thing it's meant to help with. Nobody in the company voted on that opinion. It arrived in the box.

For a brief stretch after purchase, an organization is unusually free to disagree with itself. People are still comparing the new way to the old way out loud. Workarounds are still being named instead of just used silently. That's the window — and while it's open, someone, somewhere, is making a call: how much do we run this the way the platform works out-of-the-box, and how much do we bend it back toward what we already had?

That call almost never gets made in a governance meeting. It gets made in a configuration workshop, by whoever's in the room — usually a few levels below whoever's actually accountable for the outcome.

Here’s a newsletter I read most every morning. It’s quick news an everything happening in this space.

I expect some pushback here, so let me make the case against myself directly: isn't this just process design? An implementation detail — genuinely different from governance, which is supposed to mean deliberate oversight, someone accountable, weighing tradeoffs on purpose?

I used to find that argument convincing. I don't anymore, and here's why: the whole problem is that configuration choices get treated as plumbing, and that's exactly how they escape the people who are supposed to be accountable for them. Nobody schedules a governance review for a field mapping or an approval-routing default. But six months later, that default is just "how we do things" — and the policy document that eventually gets written is describing behavior that already calcified, not shaping a decision that's still open. By the time governance shows up with a clipboard, the actual decision has already been made and forgotten. Calling it "just implementation" isn't a rebuttal to that. It's a description of the mechanism.

For a long time, I thought the fix here was change management — help people adjust to the new process, communicate the "why," get buy-in. I don't think that's the real problem anymore.

The people closest to the new process usually aren't resisting it out of habit. They're making a judgment call, in real time, with no clear authority to make it and no one senior enough in the room to make it with them. That's not a training gap. That's a decision-rights gap. You can run the best change management program in the world and still never answer the actual question: who's allowed to decide how much this platform gets to change how we work?

I asked this on LinkedIn this morning and I'll ask it here with more room: who should actually own the permission window?

The project team is closest to the decision and has no authority to make it stick. The executive sponsor has the authority and is almost never in the room when the call actually gets made. I keep landing on the process owner — the person accountable for how the work runs, not just whether the platform is live — but I'm open to another opinion.

If you've sat in one of these rooms, on either side of the table, reply and tell me who ended up making the call at your organization — and whether you think it was the right person. I read every reply.

— Isaac

P.S. — Wednesday's edition (Ed. 4) picks up a different thread: why most AI rollouts improve everything except the one thing that matters, courtesy of Goldratt's Theory of Constraints. If "the permission window" landed, that one will too.