Over the past year, my main responsibility has been helping the people I manage grow their skills and develop competencies. Usually we have a steady supply of client work to cut our teeth on, but this past year presented some challenges and for almost 50% of our workforce, there was little to do but learn. So how did we do it and not lose our minds watching training videos?
There are, of course, decades worth of training videos on numerous online platforms. You can also find several million miles of text to describe almost any facet of technology that you would care to learn. Everyone and his cousin's brother has a blog about something or other. Learning material is not in short supply. Quality material can be a challenge to locate, but even that is becoming a simpler task with tools like Bing AI and Chat GPT which can give you a well sourced answer to most questions. But reading and videos only take a person so far? What can you do to actually hone technical skills?
Simply put: hands-on-training. In the office we have had a couple of different ways we tried to do this and each met with differing levels of accomplishment and engagement. That last part, engagement, is a huge key. Without engaged minds, the learning is not going to take root in the gray matter. While a good portion of our workforce is geolocated to one city, a smaller portion is remote. For these remote folks, getting them engaged and keeping them engaged is difficult, but can be done. It is, in my opinion, still not as effective as face-to-face group project work, but it can yield results. And that reveals the big take away - face-to-face group project work is, we have found through much trial and error, the most effective and engaging way to train people on new skills. Let's take a look at each of these mechanisms and find out what worked well and didn't.
Remote paired programming is pretty good for getting the job done when there is a client driven deadline, requirement or some other forcing factor. When the project at hand is a voluntary upskilling lab exercise, those forcing factors are not present, so we found we needed to introduce them, even if they were arbitrary and artificial. Setting deadlines also has an effect of providing a challenge to people, which it turns out can be fulfilling when it's a target they can hit by pushing themselves slightly.
What does not work in this space is demeaning people for their lack of skill and then obligating them to fix that deficit in the way you determine at a pace you determine. Proscriptive, and derogatory, leadership in a field of creative technical contributors is like pouring water on a campfire. So we have learned by observing some minor failures what not to do here. It's important for leaders to understand that culture matters and talking down to talent is a big mistake.
Face-to-face projects benefit from the same mechanisms and suffer from the same failures of leadership. It's important to find tasks that the people engaged in the lab will enjoy and want to learn. Asking developers to learn network mapping is going to be met with a lot of hesitancy and might even turn people off to the point where you start losing talented people to employers who understand human psychology better than you do. But taking solid backend developers and asking them to learn a new service oriented architectural pattern, or front end developers and having them pick up a new tool chain for web development makes for good career growth that leverages their existing passions and interests. It's OK to ask them to stretch into other areas, but make sure you tie it in well to what they already know.
In summary, people learn better when they have a study buddy, attainable goals, and interesting objectives. If you would like help designing your training activities, drop an email to datatribe@gmail.com - I'd be happy to help you out on a contract basis.
