Enterprise Strategy

A gym membership isn't a workout.

Handing out AI licenses changes almost nothing by itself. What got one design team further in three weeks than in the six months before.

Brandon Harris · Essay · 6 min read

Share
A quiet gym with a pegboard of unused membership cards and one small group working out with a coach

Give a hundred people a gym membership and you'll get a few who were already going to work out. You won't get a fitter company.

That's most AI adoption programs. Licenses go out on a Monday. There's a lunch-and-learn. Three months later a handful of power users are doing remarkable things, and everyone else has quietly gone back to how they worked before. Then someone in finance asks what the licenses bought, and the honest answer is a few great demos.

Handing out a tool, on its own, is useless for organizational change. It'll catch a few people. It won't move the org.

The equipment keeps changing

The tool can't be the center of the plan, because the tools won't sit still. AI is moving so fast that the right tool six months ago may not be the right one six months from now. Knowing what you're trying to accomplish, and roughly how, is a different skill from knowing your way around a particular product. One of those lasts. The other has a shelf life.

Think about someone who really understands training. They know what they're working on, which muscles, how to isolate them. Drop them in a hotel gym with half the machines missing and they'll still get a workout, because they can swap one exercise for another. A good personal trainer from twenty years ago has watched the equipment "advance" a dozen times. The principles of building strength, endurance and general health have barely moved.

That's who you want on the receiving end of an AI rollout. Someone who knows what the work is for, and treats the tool as this year's equipment.

Start with what success looks like

So the order matters. First, get people to understand what success looks like. Then get them familiar with the tools that get them there. And get them out of the idea that they're limited in what they can do.

For one program I ran, success had a plain picture: a designer, or whoever held the strategic lead role on a team, taking an idea from problem to a tested, working prototype without waiting in an engineering queue. Engineers stay. What goes away is the good idea that dies because the person who had it couldn't build the first version.

The "you're not limited" part matters more than it sounds. Hand most people a new tool set and ask "what can you build?" and they freeze. Show them what's been done with it instead. The surprising uses. The thing a peer built on a Friday afternoon. Get them curious, let them try things, let them watch other people try things, and make room to talk about what's working and what isn't.

Who goes first matters too. I started with designers. Engineers already build, so AI makes them faster. Designers get a whole new capability, which makes the change visible and the stories spread. Next come the strategic leads, whoever holds that role (often a PM, not always). A strategic lead who can build a working prototype walks into a review with evidence instead of a spec, and the talk with engineering moves from "should we build this?" to "here's what we learned building it."

One design team, three weeks

A design team I worked with got a mandate to start using AI. At first it went badly. Everything was slow, it was hard, and they weren't getting much done. In a lot of organizations design is one of the harder teams to bring along, and this one was no exception.

A one-day session to test things out and prototype helped some. Three changes helped a lot more.

We showed them what was plausible, then gave them dedicated time to build the thing. Not "hey, build this with AI" dropped on top of a full week.

We changed the constraints. Instead of "you have a week to do this," it became "you have a day. Let's see what you get out of a day." That expectation could only be met with a new way of working, so people picked up the tools and figured out how to use them better.

And we ran weekly challenges. They started out unrelated to the team's real work, then moved onto the work itself, with feedback each week and space to share tips.

In three weeks the team got more adoption, and more impact from it, than in the previous six months. People started trading faster, better ways of doing things. They also found the places where AI was slowing them down and, frankly, sucked. That was the goal. We wanted to know where it helped and where it didn't.

One more piece kept it honest. Someone outside the team reviewed the work independently and said, plainly, "this is better" or "this is not better." We didn't take a worse outcome just because it had been built with AI.

Guardrails are a way to see your progress

When people ask about guardrails they usually mean rules. The guardrail I care most about is a way for people to see results for what they're building.

Set up something like peer review. While people are getting used to new tools and a new way of working, they should be finding ways to do it better and feeling like they're getting somewhere. That's a big deal for a team in transition. Even when an outcome fails, they should be able to see the progress in what they learned, so the loop can't only be about outcomes.

Give feedback on the outcome itself (I launched something, does it work?), on the craft, and on how the tool was used to get there. Those are different conversations, and people need each of them.

Ownership belongs here too. The minute non-engineers ship things, someone will ask who owns them. Answer that before IT asks, or IT will answer it by closing the door.

Where the bottleneck goes

When building gets cheap, the bottleneck moves to judgment: picking the right problem, and knowing when a prototype is lying to you. A clickable thing that works in a demo can hide every hard question about data, edge cases and who maintains it.

That's a product skill, which is why I think product should own this kind of rollout. Engineering belongs in the room, and should set the rules for anything that ships to customers. But "is this worth building at all?" is the product question, and cheap building makes it more important.

If the plan is to use AI to do the same work with fewer people, that's the least ambitious thing you can do with it. It also spends the trust you'll need for everything after. ("AI should be a supersuit, not a severance package" goes further into that.)

A membership card has never made anyone fit.

Where the metaphor breaks

A gym membership you don't use costs you the monthly fee and some guilt. An AI tool people use badly can cost more. Gym members don't build things other people come to depend on. Your designers and strategic leads will. A prototype that turns into a team's daily tool needs an owner, and a gym has nothing like that.

Some people really do just need the key. Your power users were going to work out anyway. Don't make them sit through the beginner program. Make them coaches.

Try this

  1. Write one sentence describing what success looks like for one team in ninety days. Make it something an outsider could check.
  2. Before anyone gets tool training, show that team three things people have actually built with the tools.
  3. Change one constraint. Take a task that normally gets a week and give it a day.
  4. Run a weekly challenge for a month. Start off-topic, move to the real work, and save time each week for tips.
  5. Ask someone outside the team to judge the results: better, or not better.
  6. Keep a running list of where AI slowed people down. It's as useful as the list of wins.
Any industryAI50 to 250 people250 to 1,000 people1,000+ peopleLeadership and org designProductDesignAIMetrics

Share

Handed out AI licenses and still waiting for something to change? Tell me what success would look like.

Read next

All writing