AI 'aha' team meetings
There’s no shortage of AI content out there—workflow breakdowns, productivity revelations, time-savings stats. Most of it is more brag than useful. But when I talk to engineers, I’m hearing something different: many have no clear path to the “aha” moments that actually make these tools useful, other than finding their way through trial and error.
More worryingly, I’m noticing a widening gap between people who are enjoying AI tools and people who feel like they’re falling behind. If these tools really are the future (and despite my reservations, I think they are), I don’t want certain people to get left behind. The loudest evangelists tend to skew toward a pretty specific demographic. I want people who aren’t white cis men in tech to feel like they’re keeping up—and to actually be keeping up—not just operating out of fear.
I spoke with a number of staff and principal engineers at various companies who are using AI daily to do their work, and are feeling pretty effective at it. None of them are what I would call evangelists; they are people who have felt reticent to adopt these tools, and still have some serious feelings about being complicit in the environmental cost and the politics around who’s building these tools and why. But now they’re using AI—Claude, mostly—to do the vast majority of their programming work.
My goal in interviewing them was to validate an idea I’ve been developing: that what teams need right now is a weekly meeting in which tips, tricks, and other “aha” moments about how their work is evolving are shared. (I detail how to do this below!)
That severe gap I mentioned—the people who feel like they’re being left behind versus the “I use it every day for everything” vibes that some folks give off—is something managers have to address. Not just because your leadership is mandating (or, ahem, heavily encouraging) AI tool adoption. But because you care about these folks, and you don’t want this new era to chew up and spit out the people who are just trying to survive this rapidly evolving industry.
The trial-and-error problem
The vast majority of the time, the people I spoke to only learn how to adopt these tools and where they might be useful by using trial and error.
I kept asking: are you sharing tips and tricks with your teammates?
Their answer: kind of. At each of their organizations, there’s a version of a Slack channel where people are sharing longform posts about their workflows, or they’re asking quick hit questions like “How can I get Claude to do X?” But these engineers rarely read those channels these days, or their usefulness has had diminishing returns. Why?
The world is changing too fast. A workflow post from a week ago might already be outdated—three things it touched have since changed. Internal governance is shifting just as quickly, and engineers don’t want to craft niche solutions to problems that might be solved next week by a new internal tool or a devtools team update. And context is everything: tips from someone across the company may not be relevant to how your team works in your corner of the codebase.
The engineers I spoke with have strong internal networks and some colleagues that they do trust to share tips and tricks with, but nobody described a one-to-many setting in which they consistently learn how to use these tools more effectively. A few reasons why:
- The most vocal sharers can be the most enthusiastic or braggy, not the most practical.
- There’s a “secret sauce” vibe at some organizations—especially where leadership visibly rewards the fastest, most AI-fluent engineers. When productivity feels zero-sum, people hoard what’s working.
- Workflows built on these tools often carry some risk. Someone might be comfortable with a configuration they’ve built, but hesitant to recommend it to others in case it breaks their setup.
- Power dynamics are a factor; some folks (especially newer-to-the-industry people) are hesitant to say “I did this with AI” because they feel like a fraud, even when everyone around them is doing the same.
- And sometimes people just don’t know how a colleague will respond. Will they get a lecture about the state of the industry? A dismissive “duh, just use Claude for that”? The unpredictability makes it easier not to open the door at all.
By and large, the engineers I spoke with are adapting through trial and error and trusted one-on-one conversations. I think there’s a better way—one that makes this kind of learning feel normal, democratizes the information, and makes room for the full range of feelings people have about this stuff.
Aha! AI meetings
The format is a simple variant of classic “show & tell” meetings:
- Attendance is optional, but participation once you’re there is mandatory.
- Kick things off by explaining the goal in your own words.
- Mine would sound something like: “This stuff is changing so fast. I wanted us to have a way to share what we’re learning as a team.”
- One at a time, everyone shares one “aha” moment they had in the last week due to working with AI in some way. “Aha” means “I was surprised” or “I learned something.” It can be the tiniest thing: a new way to save prompts, or realizing you had a totally wrong assumption about how part of the codebase worked—and only found out because you asked Claude about it.
- “Here’s where I screwed up” is way better for vicarious learning than “Here’s why I’m awesome.” Encourage this! Model it!
- After each share, the group responds in whatever way fits your team’s culture: emoji reactions, jazz hands, a genuine follow-up question. The point is to signal: this was valuable to hear.
- Questions are encouraged after the applause. This is how learning happens.
- Everyone shares. Yes, even you, manager.
Depending on the size of your team, it should take less than an hour.
Be a good facilitator
- If questions are running long, move them to Slack so everyone gets a turn.
- If someone’s being vague—sharing the outcome but not the how—ask follow-up questions. You want to hear the “how” behind the “aha.” If they keep deflecting, check in one-on-one afterward. No judgment; it’s probably fear.
- If someone says they have nothing to share, say, “Sorry, everybody’s gotta share! It can be the teeniest tiniest thing.” Again, even YOU are going to share something.
- If someone repeatedly skips the meeting, check in. Some people are genuinely happy learning on their own, and that’s fine—this meeting is for people who want to learn vicariously. Not everyone does, and that’s okay.
The grumpiest people in the room will soften over time. They’re grumpy for real reasons: frustration with security or devtools constraints (I feel for the folks on those teams right now!), anxiety about what’s happening to their jobs, genuine ethical discomfort. A consistent, low-stakes, celebratory space for learning helps them too, even if it takes a few sessions for that to land.
By design, people will learn other stuff from these meetings, not just how folks are using AI. The person who demos how they found nine versions of a checkout function will be inadvertently showing everybody else how a part of the checkout flow works, and the value of repeatable patterns. The framing of the meeting is “learning AI,” but the outcome (especially for folks who don’t have all of the context built up for this part of the system yet) is so much more than that.
Of course, all of this only works if people actually feel safe enough to show up and share.
Psychological safety
None of this works if people feel hesitant to share. And there are plenty of legitimate reasons they might feel this way:
- Their workflow feels like a competitive advantage they’re not ready to give up.
- Someone in the room has previously expressed frustration or anger about AI adoption, how leadership is handling this, etc.
- They’re afraid of being left behind—or perceived as being less experienced with these tools.
These are all valid. In a stack-ranked culture, you don’t want to hand your edge to the competition. In a team with mixed feelings about AI, you don’t want to upset a colleague who’s scared or frustrated. And when you already feel shaky about a new technology, it doesn’t feel safe to lead with your mistakes.
As the manager running this meeting, you need to name this, explicitly, at the start. Here’s what that might sound like in practice:
- I have complicated feelings about this stuff. You might, too.
- Everything is changing so fast, and I want us to have a way to share what we’re learning so we can all adapt.
- It might feel weird to share mistakes, frustrations, or even joy in a setting where you’re not sure where other people are at. I know that you care about each other; I care about you, too.
- I’m hoping this helps lighten the load of adapting while everything is shifting. And I hope we can support each other through the normal feelings that come with this completely bonkers moment.
As the meetings unfold, watch how people are reacting to one another and what they’re sharing. Be visibly enthusiastic when someone shares a mistake they learned from. Celebrate vulnerability when you see it. Find something to celebrate in every “aha,” no matter how small. It will feel cheesy at first. It will get less cheesy. I promise.
Years ago, when I ran weekly demo meetings at Etsy, we did a little round of applause after every share—no matter how small. Even managers would demo something as mundane as a calendar invite they’d set up, and everyone would laugh and clap, because, ha, manager work. But it mattered. Everyone had a moment in the spotlight, everyone participated, and the power dynamic in the room flattened out a little. The whole team showed up every week because it genuinely felt good to be there. That’s what you’re building toward.
Conclusion
I learned a lot more from these engineers than I’ve captured here: about their feelings on AI, where their time is actually going, and what their day-to-day workflows look like. I’ll share more of that soon.
In the meantime: you have everything you need to run this meeting. Start small, go first, and make it safe to be a beginner. Let me know how it goes—I’m on BlueSky.
Want to communicate more effectively?