Why Traditional Workshops Fail with Engineers (And How to Fix It)

Why Traditional Workshops Fail with Engineering Teams

Engineers spot wasted time instantly. If you run a training session that feels like a one-way lecture, they will quietly open their laptops and start reviewing pull requests. The issue isn't that technical teams hate learning.

The problem is how we deliver the information. Most corporate training defaults to pedagogy, which is the method used to teach children. It relies on a central authority figure lecturing a passive audience.

Adult learning theory, specifically andragogy, flips this dynamic entirely. It aligns perfectly with how engineering teams already operate: through logic, autonomy, and rapid problem-solving. By applying these theories, you can design sessions that actually stick.

Andragogy: Designing for Autonomy and Relevance

Malcolm Knowles introduced the concept of andragogy in the 1970s to explain how adults learn differently than children. Adults demand relevance, self-direction, and practical application. If a senior backend developer doesn't see how your workshop helps them write better code or ship faster, you've lost them.

Andragogy rests on four core pillars that map beautifully to engineering culture. First, adults need self-directed learning. They want to be active participants in solving a problem, not passive listeners.

Second, they rely on experiential learning. They bring years of technical baggage—both good and bad—into the room. Third, they demand immediate relevance. Finally, they are driven by internal motivation, like mastering a complex system, rather than external rewards like certificates.

The Theory in Practice

Imagine you are an L&D specialist partnering with a Scrum Master to run a workshop on reducing technical debt. A traditional approach would involve a 40-slide presentation on best practices. This will fail.

Instead, apply andragogy. Start by putting a real, messy piece of legacy code on the screen. Ask the team to identify the vulnerabilities based on their recent sprint struggles.

By letting them diagnose the problem themselves, you tap into their need for self-direction. You are no longer preaching; you are facilitating a structured debugging session for their workflow.

Experiential Learning: Treat Workshops Like Sprints

David Kolb's theory of experiential learning posits that adults learn best by doing. Kolb outlines a four-stage cycle that should look incredibly familiar to any team working in Agile.

The cycle moves from concrete experience to reflective observation, abstract conceptualization, and finally, active experimentation. If you structure your workshops to mirror this cycle, engineers will naturally engage with the material.

Mapping Kolb's Cycle to Engineering

• Concrete Experience: Start with a real failure. For example, dissect a recent API integration that caused a system outage.
• Reflective Observation: Facilitate a discussion on what went wrong. Why did the fail-safes not trigger? How did the team react in the moment?
• Abstract Conceptualization: Introduce your new framework or theory here. Present a new automated testing protocol that addresses the specific gaps they just identified.
• Active Experimentation: Have them immediately apply the new protocol to a sandbox environment before the workshop ends.

When you use experiential learning, your training stops being an interruption to their work. Instead, it becomes a dedicated space to improve their daily output.

Transformative Learning: Debugging Team Mindsets

Sometimes, the goal of a session isn't to teach a new technical skill, but to change how the team operates. Jack Mezirow's transformative learning theory is about reframing perspectives and unlearning deeply ingrained habits.

For technical teams, this often means shifting from an isolated "my code works" mentality to a holistic "the product solves the user's problem" mindset. Transformative learning requires individuals to confront their own biases and assumptions.

Transformative learning is the mother of all mindset shifts. It redefines how people view reality, requiring them to unlearn existing beliefs before they can adopt new ones.

To facilitate this, you must create cognitive dissonance. Present data that directly contradicts their assumptions. For instance, show a team of engineers a recording of a user completely failing to navigate the feature they just spent three weeks perfecting.

The discomfort of watching that failure is the catalyst for transformative learning. Guide them through the frustration and help them rebuild their approach around user-centric design.

Actionable Takeaways for Your Next Session

Designing sessions around adult learning theory doesn't require a Ph.D. It just requires a shift in how you view your role. You are not a lecturer; you are an architect of experiences.

Before your next session with a technical team, audit your agenda. Are you spending more than ten minutes talking at them? If so, cut it down. Replace the lecture with a hands-on problem that forces them to apply the concept immediately.

Stop fighting their natural instincts. Engineers want to break things down and build them back up. Give them the frameworks to do so, and step out of the way.

If you need a logical, proven structure for your next technical retrospective or planning session, you can use metodic.io to design it in minutes. Focus on guiding the conversation, not building the agenda from scratch.