Continuous Learning at Work
( 6 min read )
I’ve been doing job interviews as of late and one question that keeps cropping up is about managing staff.
What would you do if you were a technical manager? What would you do to improve your team and/or company?
I’d have my folks continuously learn new skills every year.
Before I dive into my reasoning I want to preface that IBM has an internal program specifically for this. Its called Think40. The “think” stemming from IBM’s famous slogan and “40” marking the target hours per year one should achieve in learning. Whether that be books, articles, courses, videos, or other training. Every hour spent learning counts towards this goal, and in my experience 40 hours is a very easy target to reach (46 min per week), if you account all your time spent researching technical problems at work, or reading articles related to your field, or attending meetings/conferences. But let’s dive into the pros/cons.
Upsides of Continuous Learning
The reason being three fold:
1) Improves their skills. Adding another tool in one’s toolbelt is always a good idea. Even if they don’t directly use it, the experience will affect their current skills. For Java developers, learning another JVM language like Scala, Kotlin, or Groovy, can help improve your understanding of the Java language and ecosystem. They might have to try a different IDE or a different build tool. And they might also practice deploying on self-hosted VMs or the cloud, all the while learning that new JVM language.
2) Keeps them on their toes. Continuous learning helps fosters an open mind for new ways to accomplish work. They’ll be more receptive to new, strange, or challenging work when it pops up. Practicing new technology stacks for example is a great way to learn how to approach problems from different points of view. For example, If you’re familiar with the LAMP/WIMP stack then tryout the MEAN/MERN stack.
3) Buffers sudden changes. I’ve seen too many coworkers fall behind in skills. They get comfortable and rely on a set of tech skills to pad their resume and cement their position for 10+ years. Unbeknownst to them, project changes or even job changes are inevitable. They’ll happen sooner or later; whether it be reassignment to new teams, re-training, re-location, or getting the axe and having to find a new job. When done appropriately, continuous learning buffers these disruptions for employees and the company.
I had an IBM manager tell me before, Get comfortable with being uncomfortable. That advice didn’t click for me immediately, but after a few years and many projects later. I finally understand what he meant and have tried to improve myself whenever I felt comfortable with my understanding of a topic.
Downsides of Continuous Learning
For starters I can think of two:
1) Learning for the sake of learning can burn some people out. It can be frustrating to constantly have to show hours put into learning, when they’re already doing a full-time job. They’ll see it as yet another metric to be graded on later for raises/promotions. They might think that doing a good job on a project should be enough evidence for that next raise. This however misses the point of continuous learning, and it should be the easiest metric to earn every year regardless. This is because learning can be lots of things; books, articles, classes, e-courses, white papers, videos, blogs, and more. Heck, if you learn something new and apply it to your full-time job to make something easier/better, then that’s a raise/promotion cause right there.
2) Companies/managers don’t like to pay for training or time spent on “unusable” talents. Convincing them will take time and be hard to prove the effectiveness of continuous learning. If you want to start an initiative at your workplace, start small and focus on the benefits to the team and company when pitching it. I wish I had hard facts from IBM to share but my anecdotal experience is simple; the small (<1hr/wk) time spent learning new technologies and skills helped keep my experience relevant and improve my programming for the projects I worked on. I noticeably was better at simple tasks like writing JUnit tests and git commit messages. But I also could talk and brainstorm with the Senior Architects on my last project about what tool to use for each problem, and I think they were just as surprised as I was.
Published: Jul 30, 2018
Category: workplace