.svg)
Michael Burr didn't set out to get promoted. He set out to fix a gap on NiCE's website. Four years and two promotions later, he's the person every department at NiCE goes to first, and the way he got there is worth understanding if you work in any role that touches demo content, sales enablement, or customer education.
This piece breaks down the three-stage system Burr used to turn tool expertise into internal leverage, the specific workflows he built, and the framework you can use to apply the same approach at your own company.
Why it matters
Most internal enablement content decays for a boring reason. It's not neglect. It's coordination.
Before Burr rebuilt NiCE's training modules in Storylane, updating a single learning module meant identifying what needed to change, finding the person who owned the slide deck or video, waiting for them to update it, getting it re-recorded if necessary, and then republishing it to wherever it lived. A change that should take ten minutes took weeks because it depended on a chain of people who all had other priorities.
Burr's fix removed the chain entirely. He opens Storylane, makes the change, and publishes it. Because the embed link never changes, every page or platform that displays the module updates automatically. Nobody else has to be involved.
That's the part worth sitting with. The skill that made Burr indispensable wasn't demo building. It was removing a dependency that other people didn't even know was slowing them down.
Own tool mastery
Burr's first move was refusing to stop at good enough. He tested HTML capture against screenshot capture for every product screen, pushed annotation placement to find out what confused users versus what guided them, and experimented with branching flows until he understood exactly when branching added value and when it created unnecessary friction.
None of these were things he needed to know to ship a basic demo. They're things he learned by pushing the tool past its obvious uses, which is how he ended up knowing things about Storylane that nobody else at NiCE did.
The features other departments noticed
Burr didn't pitch these features to other teams. Once people saw them in a presentation or a live demo, they asked how to get access. The branching logic got attention from product teams who wanted to show different user journeys depending on persona. The annotation controls got attention from training teams who wanted to build self-guided modules. The embed stability got attention from anyone who'd ever had to update a link across fifteen different pages.
That inbound pull is different from being asked to execute someone else's request. It meant Burr was being brought into decisions earlier, before the work started, rather than being handed a brief after someone else had already decided what they wanted.
Own the infrastructure
Tactical work is replaceable. Infrastructure is not. Burr's second move was building systems other people could trust without his direct involvement.
He built a demo library organized around use case and audience, not just product area, so reps could find the right asset without asking him which one to use. He set up view-only permissions for different teams so the library stayed consistent even as more people accessed it. He created a maintenance cadence so demos got reviewed and updated on a schedule rather than whenever someone noticed they were out of date.
Each of these reduced the number of decisions that required Burr to be in the room. That's counterintuitive if you think visibility comes from being needed for every individual request. It actually comes from owning systems that keep working whether or not you're there, because those systems are what leadership notices when they're deciding who to trust with more responsibility.
Own the expansion
Burr's third move was taking what he'd built for sales and extending it into adjacent departments that had the same underlying problem.
NiCE's customer success team needed onboarding content that stayed current without requiring constant maintenance. Burr's system already solved that. NiCE's product team needed a way to show feature walkthroughs to internal stakeholders without scheduling live demos every time. Burr's system already solved that too. He didn't have to rebuild anything. He had to recognize that the infrastructure he'd built for one team was reusable, and then go make the case for it in two more rooms.
By the time Burr had done this across three or four departments, his work had become load-bearing for the company in a way that a single team's demo library never is. That's when the career moat closes.
The career moat framework
The pattern Burr followed maps onto three questions you can ask about your own situation. What do you know about your tool that nobody else on your team does? What systems have you built that other people depend on, and would break if you left? Which adjacent teams have the same problem you've already solved?
The third question is the one most people skip. It's also the one that separates someone who's good at their job from someone who's indispensable to the organization.
The takeaway
Burr's promotions weren't a reward for building better demos. They were a consequence of building infrastructure that other teams needed, and then expanding that infrastructure until removing it would have required significant coordination to replace. You don't build a career moat by being the best at a tool. You build it by making the tool's benefits available to more people than anyone else thought to reach, and by making those benefits durable enough that they don't require you to be involved in every instance.