For many trainers and L&D managers, especially those in large organizations, there’s a tendency to be wary of tech skills. If you’re not a software engineer, it can feel difficult to come to grips with the tools and skills you want your developers and engineers to get to know.
That’s why certifications are so popular – they’re a good way to communicate technical aptitude. However, while certifications and qualifications can be useful, they have some limitations. When things change so quickly, it’s not just about what you know; it’s about how you know it – and where your mind and skills are going next.
Ultimately, technology training is about decision-making. You need an engineering team that isn’t just effective at writing code and developing the applications your organization needs but that’s also able to make the right decisions. From learning to execution, decision-making is a core part of what it means to be a software engineer. As trainers, we need to facilitate and support the development of that skill. Here’s how.
Let Software Engineers Drive Their Own Learning.
In today’s open-source software landscape, it is important for developers to drive decision-making forward.
Software architectures and stacks are constantly evolving based on the needs of the organization – often, a mixture of short- and long-term goals. Although alignment with technical leads and CTOs is essential for those leading training initiatives, it simply doesn’t make sense to provide structured short-term training. Instead, it’s more effective to offer a wide range of resources that facilitates engineers’ learning.
However, putting the right resources in place is just one step in this process. A different type of training is required at another level. Often underrated or completely ignored, this type of training helps engineers make decisions about what they learn or, sometimes, how they approach learning.
If this sounds a little abstract, to a certain extent, it is. But it is possible to think about in a practical way: Developers will have to make a decision about a new framework they plan to learn. For example, do they learn React or Angular? Of course, to make this decision, developers need to understand the differences between the two web development frameworks. They need to understand the advantages and disadvantages of both and how they might fit into their current stack of tools. Once they have this level of understanding, they can then move a little deeper. They can begin to invest time in more traditional technology learning – but still, a straightforward curriculum won’t quite suffice. Depending on the details of ongoing and future projects, developers may need specific routes into different technologies. There are a million different reasons to use one technology over another. What those reasons are will change how engineers decide to learn it.
Clearly, every learning journey is complex and unique. Having to communicate those needs to management and leadership only adds a further layer of complexity. More than that, it’s unrealistic. No one has the time to talk about their learning needs. They’d rather just be learning.
We Need to Better Understand How Software Engineers Learn.
The fact is, many software engineers enjoy learning. It’s built into their daily lives. A survey by software development forum Stack Overflow revealed that developers visit the website at least a few times a week, often every day.
But it’s important we don’t misunderstand what the learning journey looks like for many software engineers. Daily problem-solving is essential but may be beyond the scope of more traditional training methods. But the decision-making aspect is just as important and often undervalued – by everyone.
Two Ways We Can Support Software Engineering Teams
It’s essential that developers and engineers are empowered to do their own learning, but providing a framework to help them do so more effectively is perhaps the best thing trainers and L&D managers can do for them.
There are two core components to this process. The first is providing the resources that allow engineers to make decisions. In an age of information overload – and, more recently, fake news – unraveling different perspectives on various tools and approaches can be time-consuming at best and misleading and incorrect at worst.
The second element is more akin to what are often called “soft skills,” which are more about the awareness of how the different components of an individual’s work fit together. Here, individuals need to be supported to better recognize their needs, the business’ needs and the needs of those around them. It’s essential that we encourage these skills throughout our teams, particularly for senior engineers in managerial roles. Not only do they make planning for the future that much easier, but they also foster a better team and organizational culture.
Of course, this task can be challenging. It would be much easier if we could simply put together a course or curriculum and stick a certification on the end of it. But just as developers and engineers need to adapt to change, so do we. So do entire organizations. The key lesson is that training can’t just be about the simple transfer of knowledge. It needs to be about frameworks of learning and problem-solving. Knowledge and understanding is just one aspect of this process.
One way of thinking about this problem is to focus not on “knowledge gaps” (along with “soft skills,” another term that’s been overused in recent years) but instead to think carefully about those issues and areas where knowledge is contested and open to debate. We need to focus on those places where decision-making and judgement are required. That’s where everyone needs more support.
