Congratulations! Your startup is taking off, or it’s time to accelerate the pace of your internal project or consulting work. It’s time to hire more people to join your team. You have chosen promising candidates, and they have accepted your offers. Now all you have to do is wait until their start dates…right?
Not necessarily. If you want to get your new team members up to speed as quickly as possible, you need a system for orienting those new team members to all the important context they need to do the best possible job for you.
Having them shadow another team member, or even multiple team members, isn’t a system. And it isn’t going to be enough. Here’s why:
Why shadowing/pair programming isn’t enough to orient a new team member:
Let’s use software engineering as an example. A new engineer is joining your team, and in order to succeed on your team an engineer needs a set of knowledge and skills. For the sake of illustration, let’s say that knowledge and skill set is represented by this list of tasks that they should be able to do:
There are several paths to acquiring this entire skill set, but they all involve exercising all of these skills. Developers frequently get thrown into the deep end and expected to “figure it out,” so they end up with work paths that look something like this one that result in piecemeal skill acquisition:
In an ideal world, eventually the developer would follow a work path that at some point covered each of these skills. That’s how randomly rotating pairs is supposed to work: ultimately, every developer should get context on everything.
Let’s talk about how that falls down. Here’s your skill set again, this time with some labels on it:
If you have read a lot of my writing, you already see an issue here: the description of some pieces of context as ‘easy’ or ‘basic.’ We’ll get to why that’s a problem soon.
So, let’s say your developer is coding away, or pairing away, and here are their paths through the skills grid on the first week of their employment:
Some stuff got covered, and some did not. Maybe a piece of work took an extra couple of days, so the developer didn’t get to make the grand tour of another piece of the code base that week. Maybe one developer on the team has become the ad-hoc ‘expert’ on a particular work stream, and that’s the one that involves logging into CI, so your new developer doesn’t do it.
That’s OK. Your developer doesn’t need to learn everything immediately.
But one day, while soloing, your developer runs into a task that requires him to use this skill:
Do you see the problem here? The developer has never been exposed to this, but if they have been here any length of time they’re expected to know it because it’s ‘easy’—even though they have never been exposed to it and had no way of knowing they needed it. What is the developer going to do?
Hopefully, they’ll ask for help. But frankly, developers are not always kind to other developers who ask questions—especially questions that they consider to be ‘easy’ or ‘basic.’ In fact, developers are so bad at this that several developer education academies have specifically banned the demeaning way that developers react to questions they know the answer to.
Your new developer might think that they should have know this thing and it’s their fault that they don’t know what to do. So they make it up. Or they skirt that piece of work. Or they introduce a new solution on the team, one that’s more familiar to them but that everyone else now has to learn. Later, when asked to justify that decision, your developer might get defensive because they have to justify that decision in a way that isn’t ‘I didn’t know X.’*
*A sidenote: these serpentine paths through the skill grid represent most programmers’ educations on a larger scale, too, which explains some of the defensive arguing that you find in the programming community.
Please Ramp Responsibly: How to Orient New Team Members
- Practice drawing diagrams of the problem you’re solving and the solution you’ve built. During your new hire’s first week, you will draw these diagrams while explaining the system to them. The diagram will help the new team member understand what you’re doing and easily. identify spots where they have questions. The diagram will also make you better at explaining what you do. Finally, your new hire can keep a photo of the diagram as a reference for later.
- Set a goal for which problems you would like the new hire to be able to solve independently after 30 days. If the answer is ‘everything,’ then you’re either hiring for a very easy job or you need to put more thought into this. When the new hire shows up, share your expectations with them. That way, in the first month, they’ll feel motivated to ask questions that drive them toward being able to complete those tasks. Also, your new hire will have some security after the first month asking questions not related to the tasks, because if they completed the benchmark tasks by the benchmark, they know they don’t have to worry about not knowing something they “should” know. Consider repeating this exercise at three, six, and twelve months.
- If the new hire will be shadowing or pairing with someone, make sure the shadower or pair is willing to slow down and explain everything they do. If this person is racing through their work, the new hire won’t learn much—and will also learn that racing through things is the way to get work done, which could be dangerous. Nota bene: just because so-and-so is good at X, does not mean that person will be good at ramping a new hire on X. The person must also be demonstrably patient, vocal, and empathetic. By ‘demonstrably’ I mean that you have empirical evidence of their patience, vocalness, and empathy from observing how they respond to team members’ questions or observing them at work speaking up on behalf of someone subordinate or junior to them.
- Brief your team on how to respond to questions in general. Remind them that, no matter how good at something they are, if they make it unsafe and humiliating for people to ask them questions, they will never be viewed as a go-to expert—nor reap any of the career benefits that come with that distinction. For some people, the impact of their demeaning behavior towards others will not dawn on them (or at least won’t matter to them) until they understand how it can negatively impact their career.
- Assign your new hire a specific person who is responsible for getting their questions answered. This person doesn’t have to know everything, but they do have to help the new hire figure out where to go for what. And that doesn’t mean sending the new hire on goose chases, either. They should help find the answer until the answer is found. A good guard for this one is to ask the new hire for feedback on their orientation person after a month or two on the job. Consider rewarding your good on-rampers for the immense value they provide to your team: they allow your team to scale; without them, you would be stuck in startup mode.
In Conclusion:
You’re excited to have your new team members contribute to the success of the project. But in order to see that as quickly as possible, you need to set them up for success. Tossing them into the deep end, or even having them shadow or pair, isn’t enough to guarantee a solid foundation for scaling your team. Instead, create a plan. Map out your problem space with diagrams. Identify benchmarks for your new hires. Coach your team on helping their coworkers and teaching effectively. And reward the members of your team who make it possible for your team to grow, because they are your most important asset when it comes to scaling your efforts.