How to build problem solving capability
Teaching problem solving skills that stick.
A practical guide for L&D professionals on developing problem solving capabilities through workshops and training that create lasting change.
A few months ago I heard from a L&D manager at a financial services firm about her first problem solving workshop. She'd spent weeks preparing, had beautiful slides, and knew her content inside out. The session bombed.
Not because of her delivery or the content quality. It failed for a reason I see repeatedly when teaching problem solving skills: she treated it as a training session rather than capability building. Participants learned about problem solving frameworks but couldn't actually solve problems any better when they left the room.
Here's what I've learned from facilitating problem solving training sessions and, more importantly, from watching others succeed and fail at teaching problem solving skills: building genuine problem solving capability in organisations requires a completely different approach from traditional training.
The skills retention challenge no one talks about
The uncomfortable truth about problem solving training is that most of it doesn't stick. People forget 70% of what they learn within 24 hours without reinforcement. I've seen organisations invest thousands in external consultants who deliver brilliant problem solving workshops, then watch those capabilities evaporate within weeks.
The problem isn't the quality of training. It's that we're trying to build capability through knowledge transfer alone. You cannot lecture someone into being a better problem solver any more than you can lecture someone into being a better swimmer.
What actually works? Three things that consultants know but don't always share.
How to teach problem solving: Start with real problems, not hypothetical examples
The single biggest mistake I see when training employees in problem solving is using generic case studies or hypothetical scenarios. "Imagine your team is facing a productivity challenge..." No. Stop right there.
When I facilitate problem solving workshops now, I tell participants upfront: "Bring an actual problem you're facing. Something that's keeping you awake at 3am or causing friction in your team." This creates immediate awkwardness. People look uncomfortable. They worry about discussing real issues.
That discomfort is exactly what you want.
Real problems create authentic learning because:
- The motivation is intrinsic—people genuinely want solutions
- The context is immediately applicable—no translation needed
- The emotional investment drives deeper engagement
- The learning transfers automatically to their actual work
In a recent 45-minute workshop, participants tackled everything from talent retention challenges to email overwhelm to technology adoption resistance. Not made-up scenarios from a case study library. Real situations causing genuine headaches.
The difference in energy is palpable. When someone is working through how to fix their actual approval bottleneck that's delaying urgent purchases, they engage differently than when they're role-playing a hypothetical scenario about "Company XYZ."
Frame it as capability development, not problem solving training
This distinction matters more than you'd think when developing problem solving skills in teams. When you call something "problem solving training," people hear: "You don't solve problems well enough." The defensive walls go up immediately.
Instead, position it as core capability development. Strengthening skills for current and future roles. Career pathway development. The exact same content, completely different reception.
I learned this the hard way. Early workshops where I led with "Let's improve how you solve problems" met resistance. People felt criticised. Sessions where I positioned it as "developing transferable skills that work across different roles and challenges" saw immediate buy-in.
Language matters. Not because we're being manipulative, but because framing affects psychological safety. People need to feel safe to experiment, make mistakes, and try unfamiliar approaches.
The systematic versus lightning distinction
Here's something consultants understand but rarely explain explicitly: not every problem deserves systematic analysis.
Some challenges require deep, structured investigation. Others need quick action. Teaching people when to use which approach is as important as teaching the tools themselves.
Systematic problem solving—with its defined phases, structured tools, and thorough analysis—works brilliantly for complex challenges with significant consequences. The talent retention issue? Absolutely systematic. The recurring tech glitch that costs 20 minutes weekly? Probably not.
What I call "lightning problem solving" handles everyday obstacles with action-oriented mindsets. Quick fixes for non-critical issues. Experiments for learning. Rapid responses when time pressure demands it.
In workshops, I now spend explicit time on this distinction. When do you slow down for systematic analysis? When do you move fast with experimentation? This meta-skill—knowing which approach to deploy—is what separates people who can apply frameworks from people who genuinely solve problems better.
What happens after the workshop matters more than what happens during it
This is where most capability-building efforts fail, and it's entirely fixable.
The best workshops I've seen include these follow-up elements:
- A take-home reference guide (not slides—an actual practical toolkit)
- Specific commitments about when they'll apply what they learned
- Scheduled check-ins at 2 weeks and 6 weeks
- A shared space where people can ask questions or share wins
You don't need sophisticated systems. A simple shared document where people post "I used the 5 Whys on our meeting structure problem and here's what I discovered" creates powerful reinforcement.
One L&D manager I work with sends a single-line email every Friday: "What problem did you solve this week using a systematic approach?" Just that. The replies create a culture of practice and a repository of real examples for future workshops.
The facilitation mindset shift
Traditional training rewards the facilitator for delivering content well. Capability building rewards the facilitator for enabling practice well.
Your job isn't to be the expert at the front of the room. It's to create the conditions where people develop expertise themselves. This means:
Embrace the mess. When someone's real problem doesn't fit neatly into your planned example, that's perfect. Messy, authentic problems create better learning than tidy hypotheticals.
Get comfortable with silence. When you ask people to apply a tool to their actual challenge, don't fill the thinking space. Let the cognitive work happen.
Prioritise experimentation over perfection. Tell participants explicitly: "Apply the frameworks systematically first, then adapt based on your experience." This permission to iterate prevents the paralysis of trying to use tools "correctly."
Make activities work individually or in pairs. Not everyone wants to share their genuine workplace challenges with a large group. Give options.
Getting started without overwhelming yourself
You don't need consultant-level materials or weeks of preparation. Here's what actually matters:
- Secure 45-90 minutes. Shorter sessions work better than you'd think if focused on application.
- Ask participants to bring a real problem in the invitation. Frame it as "a genuine workplace challenge you're currently facing."
- Teach one framework and 2-3 tools maximum. The Define-Analyse-Devise-Decide-Implement-Improve-Document cycle works for systematic problems. Pick your favourite complementary tools.
- Build in application time. 60% of your session should be people working on their actual challenges.
- Create a follow-up mechanism. Even if it's just a shared email thread or monthly check-in call.
The first session will feel rougher than a polished training delivery. That's fine. Capability building is inherently messier than knowledge transfer. You're facilitating development, not delivering content.
What success actually looks like
Three months after that financial services firm's L&D manager ran her first (failed) session, I checked in. She'd run four more workshops using these principles. Her measure of success had completely shifted.
She wasn't tracking satisfaction scores or knowledge retention tests. She was counting:
- How many participants used tools on real problems within two weeks (83%)
- How many reported solving a problem they'd been stuck on (47%)
- How many requested follow-up sessions or asked colleagues to attend (91%)
One participant told her: "I've been to a dozen training sessions this year. This is the only one that's actually changed how I work."
That's the marker you're aiming for. Not "they enjoyed it" or "they learned something." But "they solve problems differently now."
Building internal problem solving capability versus buying it
External consultants absolutely have their place. For specialised expertise, for objective perspectives, for surge capacity when you need it. I'm not arguing against ever using consultants.
But teaching problem solving skills to your team is different. It's a core transferable skill that strengthens with practice, transfers across contexts, and compounds over time. It's not something you can outsource and expect to retain internally.
When you build this capability yourself, you're not just solving today's problems. You're creating a team that tackles future challenges better. That applies these approaches to situations you haven't anticipated. That coaches others in structured thinking.
The paradox is that building capability internally often feels harder than hiring expertise externally. It requires patience. Acceptance of messiness. Willingness to iterate. But the returns compound in ways that consultant engagements, no matter how brilliant, simply cannot match.
If you're responsible for building problem solving capability in your organisation, you already have what you need to start. You don't need consultant-level polish or comprehensive programs. You need real problems, systematic frameworks, genuine application time, and follow-up reinforcement.
The rest is practice—yours and theirs.