The response was almost all words that I would consider negative. Here are a few to give you a flavor: 'Remedial' (ouch). 'Junior'. 'Boring'. 'Bootcamp'. 'Corporate' (this one felt particularly brutal).

While many of these words aren’t objectively negative, from the mouths of experienced software developers, they say a resounding 'not for me'. The association with the term ‘corporate’ suggests that training is seen as the tool of slow-moving, bureaucratic organizations, rather than nimble tech companies.

I was particularly interested in the words 'remedial' and 'junior' because they point to a perception of formalized learning as something that is either the shiny badge of a rookie or the dunce hat of a poor performer. As a result, asking an experienced engineer to attend training in tech could be something of an ego hit. And that’s holding us back.

In this article, I’m going to look at why this perception exists, how you (as a tech leader) might be making it worse, and how to change it and instill a continuous learning culture in your team.

Why does this perception exist?

To look at where this perception originated, first consider the rather romanticized picture of a young (time-rich, responsibility-poor) dev who started coding at the age of nine and spent countless hours self-teaching with an insatiable passion for coding. By the time this developer hits the workforce, they’ve got maybe a decade of ‘experience’ under their belt without ever having been asked to – or paid to – write code.

Understandably, they take pride in the results of this self-teaching. And it’s also understandable for that pride to grow into arrogance with regard to learning.

I’m going to call this character the Vocational Dev. They were popularized in the zeitgeist of the 1980s and 1990s. Think Hackers, WarGames, and ‘nerd’ characters in almost every sitcom, and the mythology of the dorm-room coder billionaire (looking at you, Gates, Woz, Zuckerberg).

This developer has paved the way for a culture – and expectation – of self-teaching and curiosity-driven learning.

However, tech today has grown past the domain of nerds. It is increasingly both mainstream and recognized as a lucrative and appealing career path. The last decade has seen a huge influx of a new generation of software developers: The Bootcamp Grads. Tech bootcamps have completely changed the software developer landscape by making it possible for people to enter the industry without any prior coding experience or relevant qualifications.

Unsurprisingly, these Bootcamp Grads hail from a far greater diversity of backgrounds than their predecessors. More of these folks are starting their software career later in life, and are thus more likely to be in a caregiving role. This profile makes it less likely that they have either the time or inclination to regularly spend hours self-teaching after the workday. They have actively chosen software development as an attractive career, rather than an extension of a hobby, and are likely to bring a diverse range of backgrounds and perspectives with them.

Most organizations are already aware of this and have adjusted their hiring processes accordingly. But, in my experience, that awareness hasn’t often translated into what happens after onboarding. The same self-serve learning resources (which I like to think of as ‘biscuit learning’, or ‘learning as a perk’) that have been deemed appropriate for our Vocational Dev are offered up to the Bootcamp Grad, with negligible results.

No rest for the seniors

With the rise of DevOps, containerization and cloud computing, the bleeding edge of tech is bleeding more profusely than ever.

Once, a senior developer could expect to learn a new version of their specialist technology every few years, but now they can’t just be good at one thing. For example, they can’t just master Rust, they also need to grok Git, work with Docker, deploy on Kubernetes, be competent with Microservices, and more. In short, lead developers are now constantly at risk of being out of date and need to embrace and adapt to new technologies and approaches at a dizzying rate.

In this world, if teams see formal learning such as training or coaching as negative, it will be holding back not only each individual, but the company. Tech-driven companies are the capabilities of their dev team; they live and die on whether the team can ship quality features at pace.

Understanding the origins of the negative perceptions around training, and with an awareness of an ever-increasing need for all members of a tech team to quickly learn and adapt, I’d like to focus on how to shift the perception of learning, for the benefit of every team member (and, by extension, the company).

The paradox in our attitude to learning

There is a strange paradox in the attitude to learning and training in dev teams: We expect self-teaching (and we see formal training as a signal of poor performance for non-juniors), yet when developers select a company to work for, opportunities for continual learning is one of the top factors considered.

I suspect this paradox drives the popularity of self-serve learning resources. Leaders benefit from a team that learns, and employees want to learn, and we expect self-serve learning to be the answer. It is not. The topics learned and the speed of progress are driven by the individual and their free time. The time-rich enthusiast will devour the content offered, but the rest of the team will not have time to watch videos during work hours. As a result, the skill gaps of the team stay just as they were before (more on why here).

Passive self-teaching means that people are only challenged in their new learning when they come to write the code during the workday. We call this approach 'trial-and-error in production' (the horror, the horror).

Leading from the top

To make the shift, I think we need to address the ego issue head-on, with an acute awareness that culture comes from the top. We need to make a conscious move away from a developer’s sense of their own capability as tied to self-sufficiency.

To assist with the mental shift, it may be helpful to consider other fields of excellence in which coaching and mentorship are a mainstay. As I’ve discussed previously in comparing dev teams to sports teams, top athletes have a coach, and, in team sports, attend regular training sessions. This is not seen as an insult to their self-learning talents, or their seniority in the field, but a necessary resource to enable them to excel and work well as a team.

Here are my tips for instilling a continuous learning culture in your team:

Preparing for the change

1. Review your learning opportunities and ensure that they cover more than the bare minimum (onboarding, career progression, PIPs). This means ensuring you have appropriate tech learning opportunities for every member of the team to gain something. 
2. Your tech strategy is likely to describe an increase in the team’s capabilities. Rather than assuming that delta is going to come from hiring alone, think about how you can take the existing skill profile and mold it into the vision you have for the team.

Making the change

1. Ensure your direct reports are included in, embracing, and talking about learning opportunities. Encourage them to do the same with their direct reports. I’ve found the sports team analogy helpful for making this mental shift in the Vocational Dev.
2. Make learning a key part of your strategy, without leaving your existing team behind.
3. Frequently remind your team about learning and its importance in achieving team goals.
4. Model continual learning in the tech leadership team by talking about what you’re learning, how, and why.
5. Refrain from celebrating self-teaching as more valuable than instructor-led learning. Having a trainer is a sign of taking training seriously, not a sign of weakness!

Ego gets in the way of learning when we, as leaders, create an environment where training is seen as remediation for performance. Change that, and the rest will follow.