Module 18 · Lesson 02
Designing and Running the Monthly Team Seminar
Reading time: 16 minutes Track: Yungsten Tech Employee Curriculum · Consultant path
The seminar's role in the engagement
The monthly team seminar takes what the C-suite is learning in biweekly sessions and brings it to the broader team. Without it, AI adoption stays at the executive level and never changes how the team actually works day-to-day.
The seminar is also where you encounter resistance — team members who are skeptical, worried, or have specific concerns that weren't raised in the executive sessions. Surfacing and addressing that resistance is part of the seminar's job.
Seminar design principles
Practical over theoretical. Teams don't want to hear about AI trends. They want to know: what can I do with this next Monday morning?
Role-specific. A seminar that covers generic AI is useful to nobody. Design seminars around the specific roles in the room: "For those of you in customer success, here's what changes" is more powerful than "here's how AI works."
Hands-on. Every seminar should include at least 20 minutes where attendees work with Claude on real tasks. Abstract knowledge doesn't transfer; experience does.
Address the concerns in the room. Leave time for honest questions. The concerns that go unaddressed in session fester and become resistance. The concerns that get addressed become buy-in.
Standard seminar structure: 75 minutes
Opening: the why (10 min)
Framing that connects the seminar to something the team cares about:
- What's actually changing about how the company works with AI?
- What will be different for people in this room specifically?
- What is and isn't changing?
Don't start with Claude features. Start with what matters to the team.
Skill block 1 (20 min)
One concrete, role-relevant skill. Demonstrated by Yungsten, then practiced by the team.
Example for a BD team: "How to use Claude to prep for a discovery call — what to research, how to structure your notes, what questions to generate."
Skill block 2 (15 min)
Second skill, building on the first or covering a different role in the room.
Open practice (20 min)
Attendees work on something they actually need to do. Yungsten and the client AI lead circulate, coach, and troubleshoot.
Q&A and concerns (10 min)
Open floor. Welcome skeptical questions. Acknowledge real limitations honestly — teams see through defensive answers, and one honest "that's a real limitation, here's what to do about it" builds more trust than three perfect-sounding answers.
Handling resistance
The three most common resistance patterns and how to address them:
"This will replace my job."
Don't dismiss. Acknowledge the concern is reasonable. Then be specific: "For this team, what changes is [X]. What doesn't change is [Y]. The skills that become more valuable are [Z]." Specificity beats reassurance.
"It makes mistakes so I can't trust it."
Agree that it makes mistakes. Then teach verification: "You're right — which is why the practice is to treat Claude output as a strong first draft you review, not a final product. Here's what that looks like in practice..."
"I don't have time to learn a new tool."
"That's exactly why we're here — to show you patterns that save time faster than they cost time to learn. Let's try one right now and you tell me if it was worth 20 minutes."
The goal isn't to eliminate resistance — it's to convert it from unspoken friction to addressed concern.