I remember it well. That moment of excitement that follows a breakthrough in coding. My eyes burning from staring at the screen too long with no breaks, my apartment awash in the faint orange glow of the setting sun outside. My stomach grumbles, “Did I forget to eat lunch?”. What had gripped my interest so tightly? I was writing a custom add-on inside of a video game, something I had never done before. I was writing the add-on in LUA, a language which is widely used as a scripting language by game programmers. I was interested in trying this for years, but felt intimidated by where to start. I decided to see how far I could get in a full day of working towards my goal with zero preparation. In my excitement, I messaged a friend of mine explaining what I was doing. As we discussed the idea and my learnings, he paused and asked, “wait…aren’t you supposed to be working right now?”
Smiling, I replied, “I am working… I’m taking my learning time.”
This blog post is about learning time at Babbel – what it is, why it’s important, and how we approached implementing and improving it.
What is learning time?
Simply put, it’s time you take during working hours to learn about something. This is time during working hours to independently pursue professional growth. This helps accelerate your growth and improve long-term efficiency and satisfaction as both a Babbel employee and an engineer. The details on exactly how to allocate the time is left up to individuals and teams. A common pitfall of learning time implementation is being too prescriptive about how it should be taken. Some teams and individuals do very well with having it locked into their schedule, while others prefer to take it much more flexibly without locking a specific day they take it.
Why is it important?
Learning time has many benefits, such as helping with attrition and burnout. As our VP of Engineering for the US, Eric Goldstein, put it:
“Encouraging people to explore personally-meaningful topics promotes happiness; a workplace that does so is irreplaceable.”
Learning time can lead to unexpected innovations (as a result of unhindered exploration of seemingly unrelated topics) – or it can give engineers a time slot to fix something that bothers them through refactoring, reducing technical debt as a result.
An example: Steve Jobs and Typography
When Steve Jobs decided to drop out of Reed college, he was no longer bound by the requirement to take “normal classes” and decided to take a course on calligraphy. This course carried no direct connection to anything he was doing – he was just interested in exploring it – he was curious. From his Stanford Commencement Speech in 2005:
“None of this had even a hope of any practical application in my life. But 10 years later, when we were designing the first Macintosh computer, it all came back to me. And we designed it all into the Mac. It was the first computer with beautiful typography.”
This shows one of the (many) possible benefits of unconstrained learning time. Hindsight is always 2020, but true innovation isn’t something that can be planned.
How do we implement learning time at Babbel?
Learning time is not a new concept at Babbel, however, a renewed focus on improving it started in 2020. At the time we started re-evaluating learning time, we realized we had good intentions, but no standardization. We had some teams who were doing great with learning time, taking it regularly and cohesively, but we had other teams that were completely unaware that learning time even existed as a company endorsed policy.
So our first challenge was, “how can we get more people aware of and using their learning time?”. To do this we created a document which summarized all of the details of learning time to build a consensus. What is it, why is it important, how often can you take it, what can you do during learning time, etc… We tried to put in writing all the most common questions that came up on how to implement it. So how does this look at Babbel?
At Babbel we recommended dedicating 5-10% of your time to learning. This was broadly communicated to the teams; however, we knew that this alone would probably do very little to shift the wider culture and increase the number of people taking learning time. To improve this we arranged for a “learning conference” in 2020, where we picked a day, department wide, and said we would all take a learning day at the same time. We could then schedule an optional follow-up sharing session one week later, with something like a lightning talk style format. You didn’t need to have a presentation – you could just show your code, or just talk in front of a black screen, or simply come to learn and enjoy – the important thing was to encourage everyone to share their learnings with each other.
During the sharing sessions we had a wide range of topics – from the advanced mathematics of elliptic-curve cryptography, to entity–component–system design and how it’s used in game development, to presentations about stand-up comedy methods and why humor is important at work and an evaluation of numerous task management methods.
The most interesting observation I had during the learning conference was that people felt compelled to share learnings from things they did months ago, not only the stuff they did specifically on the LearnConf day. We had people who didn’t take part in the shared learning day, but still shared learnings – and vice versa. This made me realize that despite it making logical sense that learning time and sharing those learnings are linked processes, they really are two distinct processes of equal importance. If you want to share something you learned, you shouldn’t need to wait for learning time to do that – we should create the infrastructure and platform for engineers to share learnings easily with each other as they come and as they feel motivated to do so. Equally so, if you learned something that maybe really helps you personally but you don’t feel like it will bring value to others, you don’t need to share everything you learn. If we want people to be regularly taking learning time and also sharing learnings and experiences, we need to address the blockers of each goal separately. We can’t assume if we get people to take learning time that they will naturally just share everything.
Measure, measure, measure!
Before the learning conference, we took a survey of everyone in the engineering department about learning time. We asked how often they took it, if they felt they could reliably take it, what blockers they had, etc… We then sent the same survey 3 months later to try and gauge if things were actually improving. As the graph above shows, we found that about 40% of respondents are now taking over 50% of their allocated learning time, compared with only 14% in 2020. This is a very important step if you are considering learning time at your own place of work because it provides objective data with which to measure your efforts.
Going forward
Even though we have made a lot of progress, there is still room for improvement. In fact, I truly believe that the implementation of learning time will change over time, and will never be fully “solved”. It requires constant iteration and reinforcement to make it really culturally stick. Going forward we are working on ways to enable sharing of experiences and knowledge more organically. As for taking the learning time itself, I believe we have to work on helping people get out of the way of themselves. Recently we have started to see great improvements in this area with some departments announcing this is a key focus area for engineering. This allows conversations around why people aren’t taking learning time to happen regularly and if there are blockers they can be addressed quickly.
My personal tips for learning time
Make sure to plan your work around learning time as if it was a vacation day. If you are working on a few tickets, try to close things up before you take learning time so you don’t feel pressure or stress from ongoing work. Announce it to your colleagues when you plan to take some learning time to help create some positive pressure to actually take the time. Also, allow yourself to be curious. Go on adventures into unexplored topics with reckless abandon and see what things you learn along the way.
In the past I have worked on a variety of topics such as:
- Completely revising my developer setup, documenting my tools, removing unnecessary tooling
- Writing a video game addon in a completely foreign language to me
- Refactoring a piece of our code base that really bothered me
- Writing this blog post
- Working on a side project
Be as curious as possible, learn often, and share the things that excite you – those are the best tips I can share.
Header Photo by Hans-Peter Gauster on Unsplash