Catch up with Part 3 (which has back-links to previous installments) if you’re not up to speed.
In the previous installment, I shared some of the common characteristics I’ve seen at companies who are really excellent at making learning one of their ordinary, day-to-day production outcomes. In this article, I want to share some specific “lessons learned” for leaders.
First, recognize that if learning is intended to support a desired company outcome, then the company needs to pay for the learning – both whatever materials are involved, as well as time. And “time” can’t be “just sit at your desk and learn;” most humans can’t learn effectively in a distracting environment. Set aside quiet spaces where people can learn on their own, if you’re using self-paced training. Most people can’t effectively spend more than a couple of hours a day learning, so this time can be scheduled around production time.
And along those lines: if you need your folks to learn something, know why. Know the business outcomes that the learning is expected to lead to. Know how to know if you’ve achieved those outcomes. Blindly throwing learners into a learning program with no means of understanding the results is a poor investment strategy.
Second, recognize the value of hands-on practice, ideally the day after a more formal learning experience. Provide the infrastructure – virtual machines, for example – so that learners can learn. And reduce your reliance on “canned” hands-on labs that merely walk learners through a process or procedure. Instead, try to connect whatever a learner just learned to something your business needs them to do, and let them practice that way. Canned labs have their place, but they’re not the end-all be-all, and they’re never going to reflect your production environment.
With those two points in mind, the company needs to be prepared to spend some time planning for learning, just as you’d plan for any other production activity. That might mean time for a senior person to review a learning plan and develop short practice “assignments” following each, for example. You might dislike taking some of your most senior, productive people off of production work, but learn to treat them as “force multipliers.” If one senior person can enable learning for ten junior people, you’ll end up with eleven senior people. That’s ROI.
Third, don’t shove everyone into the same learning pattern. Some people learn by watching videos, others by reading, and others through self-directed exploration. Value the outcome of learning, not the process.
Fourth, have a means of assessing whether your learning activity is working. Vendor certifications aren’t the best for this; they represent a point-in-time milestone achievement, and rarely provide any diagnostic for directing future learning efforts. They’re also based on someone else’s idea of what you need, not yours. Instead, look to production-connected KPIs. For example, a programmer who has increased code check-ins, with an uptick in automated unit test passes, has clearly learned something. Tools exist to help you discover those metrics. And again, if you didn’t have a plan for measuring the learning results, you maybe shouldn’t have engaged in the learning until you did.
Fifth, never stop learning. As a leader, it’s your job to look ahead and predict at least some of the company’s future needs. Direct learning there, even if there’s no immediate need for the skills. Learning is like a muscle, and it needs to be exercised continually to stay sharp.
Sixth, create positive incentives for effective learners. That doesn’t necessarily mean a promotion, although it might be one way someone moves into a senior position. Some companies have “fast squads,” for example: small teams of skilled professionals who have a pronounced ability to learn quickly. They move in to jump-start a project, and help mentor a new team into place. Then they move on to the next thing.
Seventh and finally, recognize that not all learning is easily recognized as learning. That hour someone took to find a solution on StackOverflow counts as learning; so does the junior programmer who’s pair-programming with a more senior one. Learn to acknowledge these “other” kinds of learning, and find ways to capture them: when someone finds a solution on StackOverflow, for example, make that the subject of a quick team huddle.
Now… what can learners take away from this discussion? I’ll wrap up next week with Part 5.