Nowadays there are hardly any companies that aren’t trying to assess candidates’ willingness and ability to learn. Nearly everyone agrees that constant learning and having a growth mindset is fundamental to success in software engineering. Albert Einstein is reported to have stated, “Once you stop learning, you start dying” and this definitely seems true in our trade, there’s so much change on multiple levels: new programming languages, frameworks, and tools pop up like mushrooms after rain.
Yet once you’re done with onboarding at your new job as a software engineer the rat race seems to begin, leaving no dedicated time for learning. True, in many cases the best way to learn is by doing, but that usually lacks structure and strategy, and a sense of progress.
Why isn’t learning happening?
First of all, learning is complicated. Doing it right highly depends on your personality and requires a topic-specific setup and structure. Some things are best learned by just doing it repeatedly, some things need a top-down, hierarchically built set of materials, some require a constant back and forth between these two modes. Some people learn best alone, some progress best with a mentor who stays close. Certain topics need longer chunks of focused time, some can be mastered in a series of 10-minute breaks between two work sessions.
Most importantly in the majority of cases learning requires a commitment from both parties which means support from the company (plus your team and your manager). Moral support is hardly enough. It’s not enough to say “we trust you can learn this, do your best”.
For most engineers, immediate success is defined by team goals (sprint goals/project goals) and personal goals. This means that if you only talk about learning the next card on the board will be more appealing to your engineers. They might even feel they’re cheating on their team and they are being selfish if they use work hours for learning. When annual reviews happen they aren’t talking about the books they read but the projects that they contributed to (and even though learning might support the next project, the immediate need feels to be the current one).
What can we do then?
As a manager supporting your engineers is a huge part of your job. In this particular topic support has many forms and aspects:
- Encouragement and empowering – clearly communicate that learning in topics X, Y and Z are officially supported (or even expected!)
- Create space and time. One thing can work particularly well: if you’re using some kind of work-tracking tool (JIRA, etc.) make sure that learning tasks/cards are represented there. This does two important things: it makes it official and it can inspire others in the team to do the same. Make learning a goal. Think of having dedicated learning days even (which has the nice opportunity to turn into a team event such as a mini hackathon from time to time).
- Create a structure for that specific learning area or topic. Work with your engineer to figure out what clicks, what works best for them, AND the topic at hand. Is it reading a book about it? Is it creating a pet project? Is it fixing a handful of cherry-picked bugs from the team backlog? Is it an online course? Any combination of the above? This relies on your experience, the engineer’s experience, and some trial-and-error.
- Think about mentorship as a potential setup here – which is a mutually beneficial relationship: it can tremendously boost learning and can grow the impact scope of the mentor. There are additional benefits such as creating connections across team boundaries and helping with knowledge distribution within engineering.
- Regularly follow up with your engineers – do they feel their learning is going well? How is their progress? How can you (or others) help them?
- Think meta-learning hard skills is usually trivial and is the low-hanging fruit. Picking up a new language or framework? Easy. We kind of know how to learn that, we’ve seen tons of examples. Well then, how to learn debugging the best? How about incident response? How about leading meetings? How about architectural planning? These are not so trivial but depending on the level and interest of your engineers can be the biggest blockers in the growth and career. Think ahead of time and set them up for success.
- Make sure that checking in on learning goals (called development goals officially) is part of your review cycles.
- Celebrate learning. You don’t need to overhype it, of course, but some public praise is always a morale booster and good feedback.
- Reduce pressure on your team – get realistic with estimation and deadlines (this is a longer topic in itself) to make sure you have time for learning and it doesn’t feel like ‘learning vs. delivering’.
- This might sound trivial – make sure you have a budget to spend on learning. Books, courses, conferences cost money, don’t expect your engineers to pay for those – at least chip in. Put your money where your mouth is.
- Help form communities around learning some longer topics within your company. Think book clubs extended.
As a closing remark, I’d like to emphasize that making sure learning happens is your responsibility, too, dear manager. It’s not enough to say you encourage it, demonstrate it with relevant actions. Don’t expect people to magically grow without proper support. The amount and kind of support heavily depend on the situation, but it’s always required.