Learn in context; learn while doing

Learning is often regarded as a side-activity. Something to do when we have time after or around ‘the doing’. This is not only a less effective way to learn, it often leads to people deferring and avoiding learning new things because they are too busy to learn.?There is another way...

Embed learning in doing

Learn every day. Be open to embedding learning into any activities that lend themselves to it. Scheduling learning separately tends to be less effective and often just doesn’t happen. Approach every task you do looking to become 1% better at performing that task should you need to do it in the future, and with the curiosity of mindset that looks to find what useful learning can be found while doing this activity that might also be useful elsewhere. If you achieve this often enough, there is rarely a need to plan to learn anything - the learning takes place autonomously as you progress.

This is a great example of why unrealistic deadlines and overly demanding work schedules are seriously counter productive. If you are driving the ‘performance’ of your team by giving them the bare minimum time (or even less) to get things done, they just won’t have time to learn and their actual performance will degrade in real terms over time.?

Learning is much more efficient and effective when driven by the outcomes you intend to create. I recently decided I was going to build some new apps in languages and technologies I’d never used before. Given I was pretty rusty at hands-on software development having not worked directly on building a significant codebase for several years, it might have been tempting to embark on a 3-6 month learning course or experience to reconnect with my previous knowledge and learn the new languages, tools and approaches before starting to design and build. Instead I just went straight into building the apps, embedding any learning I needed as part of the development process. The old knowledge quickly flooded back, was augmented by new knowledge and understanding of the more modern technologies and tools we have on offer now, and the first app went from concept to first pilot in 16 weeks while I learned the languages and tools being used as I went.

Yes, there was definitely some learning by mistakes, additional refactoring costs as a result, and some things could have been done more effectively if I had comprehensive knowledge of these technologies upfront, but not much more than I’d expect on an evolving product anyway. This additional refactoring cost would have been eclipsed by the waste of effort and elapsed time of learning a lot of detail I didn’t need, and the inefficiencies of learning for learning’s sake. I finished developing the minimum viable product of the app before I would have started it, if using a learning for learning’s sake approach.

Learning in real context is far more effective

"I hear and I forget. I see and I remember. I do and I understand." — Confucius

Learning for ‘hard’ technical knowledge and for ‘soft’ (even harder to learn) behavioural skills both benefit from learning in a real context where they are used to create value immediately.?

In the above example, if I took the 'learn upfront' approach I would have still taken a practical approach to learning and developed several ropey apps during the course of learning the languages I needed to, but a lot of this would include things I might potentially never actually need, and through experience the learnings just don’t stick nearly as well if applying to a hypothetical practice learning scenario, compared with doing something real. Even less would have stuck if I’d taken a theoretical learning approach; it may work for some people, but for me (and seemingly Confucius) it needs to be hands-on learning.

It is just the same for behavioural learning. I have designed, run and enjoyed many leadership programmes over the past decade and must admit that some of the earlier ones were not as effective as they could have been. They were definitely more context-integrated than traditional leadership programmes and I tried to embed as much practical learning in them as possible, but this was constrained to an extent by the way we were able to implement them. It was clear to me that some of the learning value was lost, and while the programmes were recognised as a great success and the participants significantly increased their skills and impact, some spectacularly so, the separation of this learning from the day job reduced the long term integration of these skills and the impact they could have when they returned to the day job.?

Leadership programmes we design and run now are even more reality-integrated, using an Outcome Driven Development approach. Kicking off a new programme this week, the programme is tailored around the needs of the participants from two perspectives; what learnings do they need to personally develop in the next 6-12 months of their career, and what learning topics (hard and soft) do they need to help them deliver three projects that will create direct value for the organisation. The programme is built around these projects, these people and their needs. This means that everything that is learned is used directly, and used in a real way either in their core role or as part of the project delivery. The projects will drive both technical outcomes and people and culture outcomes in the areas most necessary for the organisation. This makes the learning more effective, delivers value immediately which more than pays for the programme costs and time commitment, and this value delivery makes it much easier for the rest of the organisation to support the focus on learning needed to make the learning changes.

Learning while doing is more effective, more efficient, and more valuable than learning in isolation.

Build your learning into doing, or your doing into learning.

This content by James Carter is licensed under CC BY 4.0