Here’s a paradox when you gain a new hire: you’re happy because you have a new subordinate to help spread the load. But at the same time, a new hire needs to be trained — and training means more short-term work for you.
This leads to mixed feelings whenever you’ve successfully enlarged your team: “Yay! We have more manpower!” And “Boo! I’m going to be busier for the next two months.”
(If you don’t think training is necessary, or that training isn’t your job as manager, read this. No seriously. I’ll wait.)
So how do we deal with this paradox of training? You might think that delegating the training is the right idea. You’re a manager, after all, and you have ‘better things to do’.
This is almost certainly the wrong approach — especially if you're at the beginning of your management tenure. As manager, you are ultimately responsible for the output of your team, so you're responsible for the training that helps your team achieve the output you desire. Leaving this responsibility to someone else is abnegation of your job. You need to drive the training yourself at the beginning, and have a direct say in the kinds of things you teach new teammates.
(Note: I’m not saying you shouldn’t delegate out training at some point, later on in the process. I’m arguing that you shouldn’t do this at the beginning. Because you are responsible for the output of your team, iterating on the training that helps you deliver that output is key to getting the results you want!)
The best answer here is to get good at training. And by 'getting good', I mean being more efficient at the training you deliver. It’s probably no surprise to you that training is an actual skill — the same way teaching is an actual skill! — and it’s a skill that you have to learn if you want to perform as a manager.
Super Mario as Training Template
What might surprise you is the idea that Super Mario is one of the best examples of a self-serve training program. Yes, you heard me right: good managers have much to learn from a 30 year old video game.
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:
The first Goomba doesn’t emerge until the player has moved towards the right of the screen, and the mushroom powerup is designed to be near unmissable when it finally drops down, bounces off the first pipe, and slides towards Mario. Each gameplay mechanic, or idea, is introduced in sequential order, and only after the player has experienced (and hopefully absorbed!) the lessons of the previous idea.
There are many lessons to be learnt from World 1-1, but I want to focus on this principle for the duration of this blog post. Teaching one idea at a time is the fundamental idea that underpins all good training.
Stacking The Lessons, One at a Time
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.
The Joy of Fast Feedback Loops
There’s one last aspect in which your training should be like Super Mario: that is, that you should keep your feedback cycles small. Note that my tasks start simple. Each subsequent task then grows in complexity and in length. This idea shares similar principles with World 1-1: allow a new player — or new teammate! — easy, simple wins, and the sense of forward progress.
Fast feedback loops are your friend when it comes to training. Every instruction that a learner completes works to give them a sense of forward momentum.
Notice how, in Mario, dying from the first Goomba isn’t a disaster: this first death occurs so early in the level that the player hasn’t lost much time or effort. Making mistakes early and recovering from them quickly prevents frustration — especially at the beginning, when there are a lot of new ideas to learn.
When training your new subordinates, make sure to give them tasks that are sized appropriately. This means not giving them critical, important tasks early in the program, and it also means not giving them too many lessons to learn in a single task.
This seems like too much to take in, but it really isn’t that difficult. Take it slow. Assign a first task to your first hire, and then watch carefully. When they get stuck, you’ve probably found a gap in your instructions. Fill those instructions in. Then rinse and repeat.
Work forwards until you have a clear on-ramp — and then make that on-ramp your training program. Keep doing this until no gap remains. When you're done, you'll have a World 1-1 of your own.
If you enjoyed this, you'll like The Starter Manager Guide (from which this post was adapted).