DEV Community

Chad Dyar
Chad Dyar

Posted on

The enablement program I built that flopped, and the ten assets that worked

I once built what looked like the best enablement program I had ever designed. It flopped.

The ten assets people actually used? Nobody designed those. Reps found them and shared them with each other. The system I built was impressive. The system they built was useful.

What I got wrong

I treated adoption as a delivery problem: ship the program, train the managers, count who showed up. What spread was a handful of small assets that one rep made or found, a teammate liked, and a third person copied. There was no rollout plan, no launch email, no owner.

If you build software you already know this pattern (the feature nobody asked for gets used, the roadmap item everybody asked for sits there). The signal is in what people do when nobody is watching the dashboard.

What I'd do differently

Find the ten assets first. Before building anything, learn what people already pass to each other, and make that the spine of the program. Then build around it.

Then scale it on purpose. One manager coaching one team is a one-to-one thing. Getting coaching past your direct reports is a systems problem, and that is the question Performance Amplified takes on: how coaching scales across the whole organization, not just the people who report to you.

A free place to start

Before you build anything, take the Performance Cost Index on Performance Lab. It is five questions and about two minutes, and it is free. You answer from the current reality, you get a score between 5 and 25, and you get a next step. It is a self-score that starts a conversation about where the friction in your work sits, so use it to decide what to ask people, not to rate them.

Take the Performance Cost Index: https://chadsperformancelab.com/diagnose/pci?utm_source=devto&utm_medium=organic&utm_campaign=performance-amplified

Top comments (0)