A beginner’s guide to upskilling your team

Technology as an industry has an ever changing set of best practices, great frameworks, languages, and ideas. This can be daunting to keep up with, and to address it tech companies will usually provide you with a training budget to buy books, attend conferences and do online courses.

Getting people to actually use this budget can be challenging — how do you know the training will help or be applicable in your own work environment?

One way to upskill your engineers in a place closer to home and be sure that the knowledge is applicable is to run internal training.

There are usually several signals that you need to up-skill your engineers:

• Every company has a small number of engineers and contributors who know exactly how the whole system works. These people are invariably, very very busy.

  • During retrospectives, do people mention getting blocked for a week waiting for someone (usually from outside the team) to do a minor thing?
  • If you have a support rota, are there certain tasks your engineers always escalate due to lack of knowledge or lack of access? This is often a blocker for getting the problem fixed, and it can sometimes be difficult to attract help to handle the issue.
• During 1:1s, do your engineers mention wanting to learn more about infrastructure, devops and how your deployment systems work? Your infrastructure should be really, really boring in order to avoid needing to change or fix it all the time, but without understanding of how it works, how to maintain it, and how to fix it if you manage to break it, engineers will have trouble designing with infrastructure in mind. You may be nervous to give out the permissions to be able to work with your infrastructure for fear of them breaking things. While a legitimate concern, doing this limits your engineers ability to debug and learn how their code is actually being operated.
• If you provide your team with a training budget, have you checked whether anyone is using it? Attending a React conference doesn't guarantee your engineers will come back knowing all the best practices in React, and it definitely won't teach you how we use it internally. In the age of Covid-19, this becomes an even harder sell due to one of the benefits of external training being leaving the office.

How do you start doing internal training?

To put together useful internal training, the first thing you should do is find out what your engineers really need to learn. This information can come from 1:1s, retrospectives, team discussions, but it can also be useful to gather it from the experts. As a starter for ten, you could gather the people with the most knowledge of the area you think your team is lacking. (In our case, it was platform and backend infrastructure.) During that gathering, you should crowdsource a list of topics on which to run explicit sessions — since at Echo we were focussing on platform, our list ranged from gRPC to Kubernetes and container debugging.

From there, each of you can pick a topic on which to write some training materials. It's best to have your sessions start simple and gradually get more and more complicated as you work through the exercises. This content should mostly be left up to the trainer — they know the most about the topic, and if they're going to lead the session, they may have their own style of presenting.

At Echo, we've varied sessions between small, interactive team sessions and larger, opt-in training open to all of engineering. Depending what you're teaching, one or the other may be more appropriate. If it's a complicated technology or one that's very difficult to visualise, we found the former is better: when people are in groups with peers they work on a day to day basis, they are more likely to be comfortable asking their "silliest" questions without fear of derailing or wasting other people's time.

If it's technology that is liable to misuse, the latter may work better in order to cover work more thoroughly. There is an organisational overhead to both strategies, and if your trainer is particularly busy, committing to one hour is much easier than committing to n number of individual team training sessions.

There are other strategies like infodumps, where contributors can request topics and vote on which topics they are most interested. The session is then ran more like a Q&A than training and enables presenters to avoid lengthy investment into creating content in advance. It can also take the guesswork out of what people want to know about the subject.

What's good about internal training?

Running internal training like this can be very rewarding to your team.

For one thing, having a session scheduled to talk about learning a technology blocks out an explicit amount of time where your focus is learning that particular topic. If the rest of your team are also in that session, you have no worries or guilt over slowing the team down.

Having explicitly scheduled internal training means you can tailor it to your team's needs. Doing a course on CSS? Probably 60% of courses or blogs an engineer could read or do by themselves aren't that useful to your engineers. Have a particular area of CSS that always trips people up or seems like your engineers don't fully understand? Great, let's focus on that.

You can also provide greater context as to why we use a specific technology and ensure that everyone is on the same page as to what best practices we are using.

Since there are no other coursemates from other companies, you can also go off the beaten path and ask all the "stupid" questions you may not have been comfortable asking in another setting. This enables your team to deep dive into the areas they're not sure on and can produce greater understanding as a result.

Internal training also provides the chosen trainer with a chance to get a deeper understanding themselves, as needing to explain something can help to solidify the knowledge. It also provides them with some empathy as they will need to sit and think about all of the steps and things they've needed to learn in order to get where they are today.

Downsides

Internal training is a lot of effort. There's the effort taken by the organisers or managers to come up with what topics we need to address, the effort taken by trainers and technical writers to generate content and eventually schedule workshops, and on top of that, the nature of this type of internal training is that it pulls multiple engineers off their work at the same time.

It also puts more ownership onto the company rather than the individual, which means we are more likely to get wrong what you need the most help with, and takes away some element of your autonomy and sense of pride that you learned it for yourself.

It can also be quite difficult to tailor training methods to all types of people — not everyone is comfortable sitting and listening for an hour, and not everyone is adept at creating or delivering training. There are many engineers who would prefer to learn all of this on the job and don't respond well to just listening.

Continuing the work

It should be noted that running training in this way does take someone to start it, and to keep it going. At Echo we regularly get the experts together to discuss who is doing what training and ensure that there's still deadlines and reminders to keep this work going.

Doing training isn't all you're going to need to do in order to de-centralise knowledge, though. We are still working toward ways of applying this learned knowledge. Since starting internal training, we have spread out the access control to our infrastructure to more engineers, but there's still a hesitance to get deep into problems for fear of messing it up, or being too slow to address the issue, which is perfectly normal. For many issues when engineers are on support, we have run books which document what you should do in a given situation. To avoid the problem of lacking confidence, we need to keep these up to date and add solutions to problems that are traditionally handled by experts.

We also need to ensure that we have a safety net, whether that's slow but well-tested backup and recovery processes, or infrastructure as code, which is something we have in most of our infrastructure but not all. As part of de-centralising knowledge we're working towards bringing this work into our engineering teams and encouraging people who don't normally work on platform to join in.

We're also looking to encourage a culture of pairing when investigating operational issues — this doesn't come naturally to everyone as the first instinct is to run in and fix it, not pick up a pair and explain it to them, but it is a powerful tool when used well to upskill your team and instil confidence in learning and maintaining the system.

Summary

In summary, we feel that internal training is a useful tool to build up our engineers knowledge and decentralise the institutionalised understanding of how our systems work. It gives our engineers time to focus on learning, the sessions we provide can be tailored towards their needs, and it ensures that personal technical development is a very welcomed part of our engineering culture. It is however, always a work in progress, and we are always looking for ways we can make it better.