Training programs suck. Well, most of them do. Take it from me, someone who used to design training for a living, formal training programs are just too easy to get wrong. Just think about it, of all the training you have ever been to, what is the ratio of good-to-bad training? 1 out of 10… 1 out of 50?
Why is training so hard to get right? Well, probably because learning & development models are top-down, with decisions being made as far from the end-user as possible. The result – training often addresses the wrong problems for the wrong audience using the wrong approach. In practice, I have seen this top-down approach fail spectacularly:
- The C-suite says we have a problem – “Our managers are terrible”
- Learning teams spend 6 months building shiny content – “How to not be a terrible manager!”
- Over the next year, every manager in the company is forced to attend training – “Ugh… but at least it’s a good networking opportunity”
- Everyone then conflates positive reviews with effective training – “They gave us a 2 out of 3, so… job done!”
- Three months later… “Our managers are still terrible”
At DataGrail, we recognize that a top-down approach is not for us. We are focused on an Employee-Driven Learning model. Here is our hypothesis:
- Managers should provide opportunities, resources, and support for learning initiatives
- Individuals need to be self-motivated to learn and need agency in the learning process
- Employees need the time to learn and grow… during work hours
- Teaching others and learning in order to solve specific problems are the most effective learning methods
- Why so serious? Learning should be fun!
To that end, here are a few ways we are integrating employee-driven learning into the DataGrail engineering team and culture.
Learning as a Goal
We use an Objectives and Key Results (OKR) goal system at DataGrail. You don’t have to look hard to find professional development OKRs at the company or employee level.
I have a few professional development KRs this quarter, and admittedly, I have been slacking on a few of them. I keep thinking that I will have the energy and interest to work on my learning goals when I get home in the evenings… until, of course, I realize that I am too sleepy and hungry.
I am falling into the same trap that most people do – thinking that work time and learning time need to be separate. So why not just shamelessly take 1 hour per day, at my desk, to meet my personal learning objectives? If you see me reading a book at work or writing FizzBuzz in a language we don’t have anywhere in the code base (I hear everyone loves Rust?), it means that it is my learning time.
Embedding learning into the goal setting process is not perfect, but we get better each cycle. This cycle, I made the mistake of focusing on vanity metrics. For example, I wanted to “Read Design Patterns in Ruby by May 15th” which is a measurable key result… but it doesn’t really measure the right thing. If instead I had tried to “Read Design Patterns in Ruby by May 15th and teach two design patterns to a junior engineer” I would have stayed closer to our model of employee-driven learning and had a more measurable learning objective.
Learn by teaching
We promote a teaching and mentoring culture in a number of subtle ways – ‘open-door’ policies, encouraging pair programming, code review policies, etc.
In a not-so-subtle way, Lunch & Learn programs are a great tool to promote a teaching culture. Asking each engineer to sign up for a small research project and present it to the group gives us all the opportunity to spend time learning about and sharing something that we actually care about.
To keep us firmly in the realm of andragogy and keeping in line with our employee-driven learning model, it is important to give these sessions some structure:
- Attendance is encouraged by making the sessions enjoyable, but in the end, is optional
- The group provides feedback each session on topics they would like to hear in the future
- The presenter can pick any technical topic, hopefully inspired by a recent project or problem they have run into
- The presenter is the target learner, passing on the knowledge and skills they have recently acquired
- Presentations are meant to be casual, with interactivity being strongly encouraged (we all love to be involved!)
We have had engineers walk through how to set up serverless apps for features in our products, cover various authentication protocols, and present a step-by-step breakdown of our deploy process. Sure, occasionally a discussion about React Hooks will get derailed into a debate over the merits of single-page apps in general… but we are usually pretty good about staying on topic.
Structured teaching programs can be really cool, with the added benefit of producing content that can be turned into blog posts, conference presentations, or given to new hires during onboarding. But the main takeaway – volunteering to research something new and then teach it to the team gives each of us engineers the accountability and opportunity to take ownership in our professional development.
Give learners a say in their learning
Have you ever sat through a training program and thought “this is so useless. I am never going to use this”? Jeez… why so cynical?
Formal training programs often miss the mark by either focusing on content that is too general to be useful or by very specifically covering topics that 80% of the learners don’t care about.
We believe that the company should provide sufficient opportunities and platforms for learning. We also believe that employees are aware of their own skill gaps and, with some mentorship, are very capable of taking responsibility for their own professional development. DataGrail provides platforms with, for example, an engineering blog or a Lunch & Learn program, but the content and approach are decided by the engineers.
Providing platforms and opportunities can be relatively straight forward. We maintain a technical roadmap of prioritized challenges that engineers can choose from if they are looking for something new and interesting to work on. Then, we also make sure that everyone is involved in the sprint planning process and encourage engineers to promote stories into the sprint from the technical roadmap, their personal OKRs, or to work on blog posts or lunch & learn presentations. Development activities should be part of the work day, not extra work that engineers are expected to do on their own time.
Wrapping up
Employee-driven training is all about shifting the power to make decisions about the content or our learning programs from those who do not have any skin in the game to those who are actually trying to learn and develop professionally. As our company continues to grow, we will see how this approach scales and how we end up dealing with top-down requests for training initiatives. For now anyway, we think we have found a model that works for us.