How do engineers learn? A model for teaching skills, knowledge, and wisdom

All too often, training initiatives fail.

Many times this is because the wrong methods are used for the intended outcome. In this article, I will introduce a model for helping engineering teams master new knowledge, skills, and wisdom, drawing on my own experiences (and mistakes).

Getting learning wrong

A few years ago, when I was working as a consulting CTO, I made a life-changing mistake.

First, let me give you a little background. I’m Hywel and I love learning. I have been teaching myself different programming languages for the past 25 years. More recently I’ve learned electronics (to build my own 8-bit computer), knitting, and the special kind of knowledge that is required for quizzing. I also play the saxophone and host a podcast that allows me to regularly learn from the awesome guests we get talking about thorny tech leadership questions.

But back to the mistake.

I had built a web app that leaned heavily on a certain library, which had plenty of subtleties, configuration options, and a small number of API methods, each with a large number of options. As the company quickly grew and I hired a team to take over the codebase, I decided to train them in cancancan so they wouldn’t have to go through the rather painful ‘learn by failing’ experience that I had struggled through the first time I used it.

Oh, by the way: the capital of Oman is Muscat (this will become relevant later, promise). 

I built a series of slide decks to explain the ideas behind the library, the gotchas, the shortcomings, how to work around them, and how to debug. It took many hours to write, and several hours to deliver. But all of that felt more than worth it to transfer my hard-earned knowledge to the team.

The day after I delivered this training, a member of the team approached me for help because he didn’t know how to use cancancan, but I did.

I realized that despite all of the time I had invested in (proverbially) teaching my team to fish, I had instead communicated to them that I was their go-to fisherman.

Devastating. The training had been an unqualified failure. What’s even more depressing is that I doubt this story is unfamiliar to you. Or that the outcome (failed training) surprises you. We expect training to fail; we allow for it, which means:

1. We spend less on it because the ROI has a chance of being zero
2. We prefer hiring to developing existing people.

The reason my slides didn’t work? I had used the wrong methodology.

Also, it’s worth noting that Muscat – Oman’s capital – has a view of the Gulf of Oman. 

Getting learning right

The rest of this article will focus on how to get learning right. I’ll start by introducing my model for identifying and understanding the three different outcomes of learning (mastering knowledge, skills, or wisdom), before sharing some general advice for running training initiatives in your team.

What is your desired learning outcome?

When we think about developing our teams, it’s useful to start with the desired outcome. Do we want our team to swot up on some syntax (knowledge), or become competent in using microservices (skills), or be able to make a decision on the trade-offs of monoliths vs. microservices (wisdom)?

Knowledge

If you didn’t already know the capital of Oman, you probably do now. You’ve acquired that knowledge passively (albeit in quite a bizarre way) with pretty minimal effort on your part. Other examples of how to gain knowledge passively include:

• Watching videos
• Listening to podcasts
• Reading documentation 

Knowledge is the retention of facts, data, information. The outcomes of learning knowledge are the ability to recognise and recall it, or to use it to inform activities that you’re doing.

You can gain knowledge passively, which makes it easy and cheap to get knowledge. But you can also use more active measures (e.g. repeated exposure and testing) to help it stick.

Skills

To master new skills, learners need to be actively involved. Think about skills you might have – driving, playing a musical instrument, playing a game. Did you gain that skill from reading blog posts, or from trying it yourself?

Skills are learned through doing – trial, failure and repetition, ideally with feedback from someone who can help you improve. No-one learns to drive by watching videos on YouTube.

The ICAP framework explains that the level of engagement in learning is directly correlated to how much the learning sinks in. Examples of engaging with learning would be:

• Collaboratively working on a problem
• Debugging code and getting live feedback on the approach
• Creating something new, and navigating hurdles in the process

These types of learning can happen naturally in the course of working, but they can be effectively replicated in training by using a live, problem-based training approach.

It’s worth noting that active, interactive, constructive learning can develop knowledge too – it’s by no means exclusively the domain of video lectures!

Wisdom

Wisdom is contextual judgment – assessing a situation and making a decision. There are trade-offs and contextual decisions made in tech every day – sometimes very important ones – that hugely benefit from wisdom. For example:

• How much testing is too little / too much / just right?
• When is my organization ready for an orchestration platform like Kubernetes?

Questions like these, that don’t have a clear answer, push you beyond the idea of a generic ‘best practice’ and force you to address the ‘when’ for a particular approach.

To teach wisdom, scenarios that require contextual judgment can be used to mimic experience.

So, with the above as a window into the differences between knowledge, skills and wisdom, below is a cheat sheet to the right methodology for each desired outcome:

When what we need goes beyond knowledge, it’s pretty common for tech leaders to turn to hiring seniors instead of developing the existing team. This is fine as a solution if you also need more bandwidth, but training your current team is often a more sustainable (and effective) option.

Running effective training initiatives

Now that you’ve identified your desired learning outcome (whether you want your team to master knowledge, skills or wisdom) and you know which methodologies will help you get there, you can start to plan your training sessions. As I’ve already done the failing for you in this area, I’m going to share my top tips for getting it right:

Personalize

One of the worst things you can do in training is cover old ground. Teaching someone something they already know is demotivating, time-wasting, boring and results in no new skills. Time spent understanding the skill profile of your team is well spent to avoid this waste.

I recommend approaching this by breaking down a technology into its component parts and creating a questionnaire that probes understanding of each discrete element. So rather than saying a person is ‘intermediate in Python’, you’re able to identify that they are confident with generators and function decorators, but need more support on the SOLID principles and mixins. That’s the level of granularity that will help you make training high impact.

For an example of how I’ve approached this, you can sign up for a free trial of Skiller Whale here and take a look at the assessments in Python, React, Typescript, React Native and Postgres.

Focus

This follows naturally from personalization: when you’re able to get granular about the skills someone does or does not have, and you can overlay that with what you need them to have, you’re then able to group the people who would benefit from developing a particular high-priority skill.

Reduce your cycle time

Application and practice is a crucial part of learning, but all too often forgotten when training plans are built. Building training that focuses on areas that can have immediate application and impact on the learner’s work is incredibly motivating for the learner, and means faster outcomes for the company.

This means thinking about learning in terms of bite-size outcomes, rather than as ‘courses’ where you go through each topic in order from simplest to hardest. For example, if you need your team to write more performant code, you might have a focused session on writing performance tests, practice, then a separate session on debugging performance issues, followed by practice etc. This means learning can be immediately applied and built upon.

Compare this to signing up for an ‘Intermediate Python course’ which leaves out anything that’s considered ‘beginner’ or ‘advanced’ and instead plods its way through every topic at a preset pace and in a preset order (hopefully including some that are performance-related), hoping that the team remembers the performance stuff when they work through it in their own time. It seems to me that the former is at the very least more efficient.

Challenge and support

Memorable learning happens when you’re challenged to your limits and you get past that challenge: you’re stuck and then unstuck. This is most effective and reliably done by using problem-based learning that is pitched at the level of the learner, with an expert standing by to provide well-placed nudges, suggestions and feedback.

Spread it out

Full-day training sessions are good for one person: the trainer. They’re horrible for learners – exhausting and overwhelming, or boring and unengaging (maybe all of the above).

An 8-hour course delivered over 16 weeks – a bit at a time with plenty of time for practice in between – will have much more impact than the same course delivered in a day. This has three benefits:

1. You get to reduce your cycle time and see impact faster.
2. You don’t overwhelm your learners with lots of new information and skills to apply at once.
3. You don’t lose valuable learning to mid-afternoon exhaustion.

In summary

In my experience, for your team to successfully master any kind of learning, four things must be true: training must be personalized to what people do and don’t know; learning must be hands-on and problem-based; it must be led by an expert who can give live feedback and nudge folks in the right direction for an ‘aha’ moment; and it must be done in small chunks (30-90 mins is the sweet spot in my view). Learning is hard but essential, especially in our fast-moving field. Hopefully following this model will make it a little easier for your team.