Why the First Sixty Hours Always Feel Wasted

A change manager at a manufacturing company once described her first year on the job as "expensive confusion." She approved changes that seemed low-risk and watched them cascade into outages nobody predicted. She rejected changes that turned out to be harmless, annoying engineers who'd done the work correctly. Nothing about her process was wrong on paper. She just hadn't yet built the judgment that makes the process actually work.

That gap between knowing the rules and knowing how to apply them shows up in stranger places than IT departments.

The map doesn't teach you the terrain

Anyone who's dropped forty hours into a new open-world game knows this feeling. The tutorial explains the mechanics fine. You understand crafting, you understand the skill tree, you understand that stealth kills give bonus experience. None of that stops you from wandering into a bandit camp three levels above your gear score and getting flattened in ten seconds.

Games like Elder Scrolls are built around this exact tension. Skyrim hands you an enormous, open map almost immediately and trusts you to figure out, through repeated failure, what you're actually capable of handling. There's no mechanic that tells you "this dungeon will kill you." You find out by walking in.

The knowledge that matters, which enemies to avoid at level 4, which quests to save for later, when a fight is winnable versus suicidal, comes entirely from lived mistakes. Nobody absorbs that from a strategy guide, no matter how detailed.

Change management has the exact same trap

ITIL frameworks work the same way, and this is where a lot of new change managers get stuck. The fundamentals of ITIL change management are genuinely not complicated to learn. Classify the change. Assess risk and impact. Route it through the right approval board. Schedule it in a window that avoids peak business hours. Document a rollback plan. Anyone can memorize that sequence in an afternoon.

What that sequence doesn't teach you is which "low risk" changes are actually low risk in your specific environment, given your specific dependencies, your specific legacy integrations, your specific team's history of skipping steps under deadline pressure. A database schema update might be routine at one company and catastrophic at another, because the second company has a reporting tool nobody documented that breaks the moment a column gets renamed. The framework can't know that. Only someone who's been burned by it can.

This is why organizations that treat change management as a checklist problem keep getting surprised, while organizations that treat it as a skill built over time start seeing fewer emergency changes and fewer 2 a.m. rollback calls. The process is identical on paper. The judgment behind it isn't.

Failure is the actual curriculum, if you let it be

Good change advisory boards do something that looks almost too obvious once you see it: they keep a real record of what went wrong, and they actually read it back before approving similar changes later. Not a compliance log nobody opens. An active memory that shapes future decisions.

The manufacturing company I mentioned earlier started doing exactly this after that first rough year. Every failed or rolled-back change got a short post-mortem, not to assign blame but to answer one question: what did we not know that we should have known? Eighteen months later, their emergency change rate had dropped by more than half, not because the ITIL process changed, but because the people running it had accumulated the pattern recognition the process alone couldn't give them.

Skyrim players do a rougher version of the same thing without calling it that. You remember which cave had the frost troll. You remember which quest chain locked you out of a better ending because you rushed a dialogue choice. Next playthrough, you're not smarter about the game's rules. You're smarter about the specific traps this particular world sets for people who don't know it yet.

Neither system rewards shortcuts, and that's kind of the point

There's a reason speedrunning a complex system, whether it's a 200-hour RPG or a company's change pipeline, produces worse outcomes than moving through it slowly and getting burned a few times along the way. The burns are the information. Skip them and you skip the only thing that actually builds judgment.

Nobody enjoys the version of learning that involves breaking something in production or getting killed by a dragon you had no business fighting yet. But both systems are patient enough to let you try again, and that patience is the whole mechanism by which competence eventually shows up.