← Head back to the Starter Manager Guide
We should know by now that training is a non-negotiable part of good management. As we’ve mentioned in the last chapter: ‘training and delegation are two halves of the same process!’ All good managers are able to delegate well; therefore, all good managers know how to train.
This sounds an over-generalisation at first — surely this can’t be true for all managers, right?
But I stand by this assertion. Consider the alternative: imagine that you are a new hire, and your manager has delegated a new task to you without providing guidance nor a clear articulation of expectations. You do the task to the best of your ability, and when it’s done, you deliver it. Your manager does not check your work; later on, when it becomes clear that your work is not up to par, your manager rounds up on you and berates you for the lack of quality of your output, blames you for your work, micro-manages your next few tasks, and then concludes that you were a bad hire.
How would you feel? You would feel horrible. What makes it worse is that the business might have been affected by your work — even though you had no idea in advance what to do, thanks to the lack of training from your manager.
So who is to blame in this scenario?
To me, the answer is clear. I believe the manager is responsible, so the manager is to blame.
Remember that the job of the manager is to increase the output of the team. Or, to put a spin on this: the manager’s output is the team’s output, no more, no less. This means that it is the manager’s responsibility to ensure his or her subordinates have all that is necessary for them to get their jobs done. If you are a manager and you have not provided training, and your subordinate has failed, it is your fault as their manager. (Conversely, if you have provided plenty of training but your subordinate has failed, then the blame may not be on you).
Now, I’m not saying that the manager can’t delegate training to a senior member of their team — in fact, at the end of this chapter I’ll explain how to do just that. What I’m saying here is that training is ultimately the manager’s job. If you’ve delegated training to a senior member of your team and he or she doesn’t do an adequate job, the end result — an insufficiently trained team member — will affect the output of your team.
However you cut it, the quality of the training inside your team reduces down to you.
The Basics of Training is Teaching
This all sounds well and good, but what if you don’t like training? What if teaching frustrates you?
This is ok! In my experience, there are two kinds of managers when it comes to training: those who enjoy teaching and are naturally good at it, and those who don’t.
Whether a manager likes teaching or not is not a particularly important concern to me. My concern is if a manager can become good enough at it to be effective at their jobs. Training is a skill, just like any other — and you can get better at it regardless of whether you like it or not.
(Granted: those who don’t like training might not become great teachers, but we’re not asking for greatness here — merely a base level of competence!)
How do you know if your ability to train is good enough? Well, I propose the following goal:
If you find yourself being able to delegate 50% more tasks than you did six months ago, then you are doing a good job of training.
This percentage is an arbitrary one — but the goal implied is clear. If you are good at training, you should find that the set of tasks you may delegate reliably to your team to grow over time. Conversely, if at six months you still find yourself diving into the weeds and fixing things for your subordinates, this is a strong signal that you need to improve in your training.
Diving into the weeds to fix things for your subordinates should be the exception, not the norm.
Learn Training from Super Mario
So what’s the secret of training? How do you get good at teaching without being frustrated?
The answer here is to understand that you can’t teach too many things at the same time. To illustrate this, I often tell new managers to take a look at Super Mario.
“Wait,” I hear you say, “Super Mario?!”
Well, yes. First released in 1985, Super Mario had to introduce a whole generation of gamers to the basics of a platformer. And it had to do this without text, cutscenes, or the assumption that the gamer would read the lengthy manual that came with the NES cartridge.
Instead, the Nintendo designers made the entire first level of Super Mario a tutorial for the rest of the game. If you've played Super Mario before, you probably had no idea you were being taught the basic mechanics of the game as you progressed through the level - but you were!
To get an idea of what this means, take a moment to watch this breakdown of the decisions Shigeru Miyamoto made when designing World 1-1:
Notice how Super Mario’s World 1-1 introduces each game mechanic in order. It does so without ever overloading the new player with too much information; instead, the game introduces one idea at a time, building on what was previously introduced.
This is the core idea that you need to use in your training.
Stacking The Lessons
It's difficult to imagine today - but at one point you, too, were new to the work you now do at your startup. And I don't mean in terms of just programming, designing, or marketing - the known skills for which you were originally hired for. I also mean the hidden things that any employee of any company needs to know to get their work done:
- What's considered an acceptable level of code quality? Or design quality?
- How is code checked into the repository?
- Which repository do you use? Using what tool?
- How is the code deployed to production servers, or shipped to customers?
- Where are the design specifications located? Who writes them? Who do you go to for clarification?
- Where do you ask questions when a spec is unclear?
- How do you get set up to start programming or designing?
A new hire knows nothing about your specific company's codebase, design language, or marketing processes. If you were early at the company, it's likely that you made these processes up as you went along - and now you find you'll have to teach them to your new hire.
Your training program should take this into account. Like Super Mario's World 1-1, pick tasks that introduce one basic idea at a time, and order them so that each task builds on the lessons learnt in the previous task.
At my company, the very first task I give new members of my team is a simple one: change the colour of a single button. I grant them access to a Google Doc containing my instructions, and then I tell them: "Your job is to change the colour of this button … to whatever colour you want! Follow the setup directions in this document, and call me if you're ever stuck."
In this one task are a dozen invisible lessons. Sure, my assignment is meant to educate the new hire in the business of changing button colours. But along the way, my new hire will gain:
- Access to our company's code repository.
- The ability to download this code.
- The know-how to run this code on their development machines, and to learn what dependencies this program needs in order to run.
- Their first taste of navigating our large codebase.
- And, finally: the ability to change the colour of a component's button.
My instructions for this first task contain everything necessary a new hire will need to know to get to the point where he or she can change the button colour: I include links to the repository, instructions to retrieve the code, a guide to running the program for the first time, and some hints as to where to look in this large codebase for the code that determines button colours. Each step is something that builds on the last.
When this first task is done, I check the button colour approvingly, and then move them to the second task: to add a new button, and to hook it up to some real functionality. Notice that the concept of 'brick stacking' applies fractally: the second task builds on the ideas introduced in the first. They poke at the same corner of the codebase, and they're still messing with buttons — but the scope has increased; they're now touching functionality.
This pattern repeats for the third task, and the fourth, and so on — until my subordinate has finished their training, and is ready to start being useful to the team.
Create a Training Program
Shortly into my managerial career, I was tasked to expand the team I was running in Vietnam.
I realised that I had a major problem: every new hire we brought in would need to be trained for a few weeks, before they could start contributing to the team. Since training was ad-hoc, this was incredibly painful work. The added work of training a new teammate before he could start contributing added to our already overloaded workload.
At some point I decided that enough was enough. I would train one newcomer, and have him write down every task I gave him. Over the next few days I gave him a series of tasks, starting with the really simple work of setting up all his company accounts, to eventually reimplementing features in a frozen copy of our code base. I came up with these tasks on the fly, and checked his work at the end of every work day. My eventual goal was to have him capable of tackling basic support tasks by the time we got to the end of the training program.
At the end of two weeks, I told him to hand over the document he wrote. This became the basis of the training document that we used for the next three years. Make no mistake: the first time was incredibly painful for me as manager. Because I was training a new hire on top of my daily workload, I had to move some of my work to after-office hours, for the duration of the training program. I distinctly remember being unhappy throughout this period.
The end-result, though, was worth it. The training program was designed to expose the trainee to every major subsystem in our code base. Any software engineer who went through the program would end with the same set of capabilities. This meant a couple of important things. It meant that they would ‘graduate’ with a predictable set of tasks for which they had good task relevant maturity. This in turn meant that they could be delegated to at the end of training.
In the end, the training program itself was delegated out to senior engineers — who provided the feedback and checked on the work in order to increase task-relevant maturity. At the end of two weeks, we knew what these new, on-boarded hires could handle, and we started delegating to them. The training program has paid itself back hundreds of times since the first run.
If you are a manager, you are likely to have taught your subordinates during the course of doing your job. But I'm willing to bet that most managers have not considered systematising the things that they teach.
I want to urge you to consider turning the training you give new hires into a system. The benefits are considerable.
First, training in an ad-hoc manner might cause you to miss important elements that are crucial to getting the job done. Why bother worrying about this? If you systematise your training, you will never forget the set of tasks to teach, along with the best order to teach them in. You will also be able to control the set of skills your subordinate will have by the end of the program. This allows you to plan ahead: “oh, Joe will be done in 2 weeks, which means we can give half of Mary's support load to him then”.
Second, systematising your training allows you to scale your leverage. The ‘thing’ your systematised training should produce is a training document. This document represents the work that you've done preparing the program. It may be passed around to new hires in lieu of verbal instructions, and taught to senior engineers. Later, it may serve as a template when you're training managers to replace you.
If I may make one last suggestion: consider using the exact same set of tasks when you're systematising your training program. What I mean by this is that if you are a journalist, you should have a training program that includes an old article as a task, alongside the source material that produced that article. Then, your assignment to a new journalist is to ask her to write the piece. For feedback: you edit her output, and give her the actual piece that was published.
If you are a software engineer, you should freeze a copy of your codebase (e.g. create a git branch) and hand this frozen copy to your new hire. Then, give them a series of tasks that operates on this codebase. Bonus points if you give an actual (but edited) specification for features that have already been built into your product. Then, you may compare their solutions with the actual code your team shipped, and use this to train them on what a real, deployed feature looks like in your company.
Doing this — that is, using a simulation of an actual task — is better than training using a real task, because it is a repeatable process. You will be able to provide the exact same set of instructions and evaluate your new hires along the exact same parameters. Better still, you will eventually be able to delegate the running of the training program to a hire who has been through it!
Actionables
So how should you create your training program? I've found that all training programs I've created have followed the same basic steps:
First, think about the tasks that you are most likely to delegate in your team. Break each of them down to the smallest possible components, and then order it from the most simple to the most complex. Write this down as a series of tasks you will ask your subordinate to do. After testing this program once, go back and tweak depending on the task-relevant-maturity that you see in your new subordinate.
Gamers know this process of teaching very well. If you download and play a computer game today, you'll find the tutorial levels to be structured very similarly. Each task in a game tutorial teaches a distinct concept. They are ordered in such a way that the tasks taught in the current tutorial builds on the tasks taught in the previous tutorial. The complexity and difficulty increases as you advance in the tutorial, until you gain the minimum set of skills necessary to start playing properly. You should approach your training program in the same way.
Try this out the next time you have a new hire. You'll be surprised how much better your team would become if you try.
Chapter 4: How to Prioritise and Regain Your Sanity →
If you're a Commoncog member, download the ebook copy of this guide here. If you're not a member, fill this out to get an ebook copy:
Originally published , last updated .