Everyone Was Excited. Not Everyone Was Using It.
IBM Bob was available to everyone on our team, and the excitement was genuinely there. People were curious, interested, and asking questions. But there's a meaningful difference between being excited about the hype around the new tool and actually weaving it into your day-to-day work, and that gap was wider than it looked.
Some teammates had already fallen in love with Bob, building custom skills and moving faster than ever. Others were still at step zero. And for a team whose whole purpose is helping clients adopt emerging technology, that uneven adoption was something I really wanted to address. Not as a mandate, but as an opportunity to invest in the people I worked alongside.
- Capability Gap: "Technical" fluency looked very different depending on who you asked, and that inconsistency was limiting what we could do together
- Credibility Gap: we help clients on their AI journeys every day, and it felt important that we were genuinely walking that path ourselves
- Intrapreneurship Gap: we knew our newest talent had fresh perspectives to offer, but we needed a clearer path for those ideas to surface and grow
- Adoption Gap: I'd seen enough enablement programs to know that awareness and actual behavior change are two very different things
A Beautiful, Wonderfully Complicated Audience
About 80 practitioners across five disciplines, each with completely different workflows, priorities, and definitions of "a productive day." That diversity was actually one of my favorite parts of this challenge. It meant the design had to be genuinely thoughtful, not one-size-fits-all.
Already deeply technical. Excited about Bob and needed examples that could actually keep up with the sophistication of their work.
Wanted Bob woven naturally into how they research, facilitate, and visualize. Not as an add-on, but as a genuine thought partner.
Looking for ways to think through architecture faster and produce clearer documentation without cutting corners on quality.
Eager to explore smarter ways to write, review, and ship code, all within the tools they already loved.
Craving more time back in their day. Less time on reporting and comms, more time on the work that actually energizes them.
I Spotted the Opportunity and Got to Work
This program started as an idea I brought to leadership, something I genuinely believed in and wanted to make happen. Once I had the green light, I owned the whole thing: the strategy, the experience design, the logistics, the community building, and the measurement. Four weeks, a lot of moving pieces, and a team I really wanted to serve well.
| What I Owned | How I Approached It |
|---|---|
| Strategic Leadership & Executive Alignment | Brought the idea forward, built the case, and got people genuinely excited about it |
| Experience & Learning Design | Reimagined the learning format entirely, from passive training to active creation |
| Program Orchestration | Designed the role-based tracks, selected facilitators, managed every communication and timeline |
| Change Management & Messaging | Positioned Bob as a thoughtful productivity partner, something to look forward to, not endure |
| Measurement & Outcome Analysis | Built feedback systems that looked for real behavior change, not just satisfaction scores |
The Belief at the Heart of This
People don't truly adopt a tool by learning about it. They adopt it the moment they use it to solve something they genuinely care about and feel the joy of it working. That's the experience I wanted to design.
So rather than building a training program, I built a creation experience. I wanted people to walk away with something they'd actually made: a skill, an artifact, a workflow tweak that saved them real time. Something they could point to and say, "I built that."
Measuring What Actually Mattered
I cared a lot less about completion rates and attendance than I did about four much more meaningful questions:
Making something with a tool is what makes it memorable. A full room means nothing if people leave empty-handed.
The truest measure of any enablement experience is what people are doing with it two months later.
Not just "I enjoyed it" but "I can do something today that I couldn't do yesterday."
Confidence is what brings someone back to a tool on a quiet afternoon weeks later, just to see what else it can do.
The Principles I Designed Around
What lights up an engineer is completely different from what resonates with a strategist. Both deserve something that feels made for them but cross-sharing was totally fine too.
No decks about Bob, no watching someone else use it. Just a real challenge, real time, and real support to figure it out together.
The most knowledgeable Bob users were already sitting next to everyone else. I gave them the chance to shine as teachers.
Start by Listening
Before I designed anything, I had conversations. I wanted to understand where Bob was already creating joy on the team, where it was sitting unused, and what kinds of friction people were bumping into day-to-day. What I heard was lovely and consistent: people weren't resistant. They were just waiting for examples that felt genuinely relevant to their specific work. That insight became the foundation for everything that followed.
Design the Bobathon
I created five discipline-specific tracks, each one built around the real challenges that particular role was navigating. Role leads, dedicated build time, pre-event collaboration sessions, and technical support throughout. The part I loved most: participants didn't receive a list of use cases to complete. They got to choose the ones that genuinely mattered to their work. That small act of agency made an enormous difference in how invested people felt from the start.
Bring the Community Together
The squad managers identified track leads to pair-up who were already thriving with Bob alongside those who were just beginning or junior. Together, they co-created labs, shared real workflows, and built things side by side. What surprised me most was how much the "experts" got out of it too. Teaching is one of the best ways to deepen your own understanding. The knowledge spread in every direction, not just one.
A Day Designed to Create, Not Consume
The event was intentionally built around making. Teams built, experimented, got curious about what Bob could do, created artifacts they'd actually use afterward, and learned from the person sitting right next to them. It was energetic, collaborative, and genuinely fun, and the work that came out of it reflected that energy beautifully.
Measure What Changed, Not Just What People Felt
I cared deeply about getting the measurement right. I didn't want a survey that told me people had a nice time. I wanted to know if something had actually shifted. So I designed feedback that looked at confidence growth, skill progression, and real usage patterns in the weeks and months that followed. Two months later, the data told a story I was genuinely proud of.
People Grew and Kept Growing
What People Said
"I really liked the role specialized use cases. Instead of general use cases where every role does the same thing — role specific use cases help understand how to use Bob for our specific purposes."
"The lab tracks were well thought-out and the role-based grouping was ideal."
"I really liked the knowledge sharing and having dedicated time to explore Bob."