The Tricky Timing of Training Wheels

Starting a new job often reminds me of my dad trying to teach me to ride a bike. Jogging alongside me as I try and learn the basics, working out if he should let go to see how I ride by myself … and asking me not to tell mum as he retrieves me from a hedge that came out of nowhere.

Talking recently with managers from a few other companies, I think it’s a pretty common challenge to work out if we’re overly babying a competent, self sufficient professional or if we’ve yelled “This is Sparta!” and pushed them into a gaping pit of acronyms, tools and services we haven’t prepared them for.

Everyone’s a bit different and it’s part of the skill of training people to know if they’d rather you let them get comfortable in a stack of training manuals and spin their wheels for a bit, or if they want to go for more of a tandem ride down company lane. While I definitely lean more towards keeping a close eye on new starters, there’s a real risk of metaphorically handing a grown adult a pink sparkly bike and making them feel like you’re being condescending — so I’ve come up with a loose 3 phase plan over my years of teaching and training that seems to have worked so far.

Phase 1 — learn the neighbourhood

This phase can last anywhere from a few days to a few months, it really depends on how accessible the company’s systems are, but this is the stage where they grab a straightforward ticket with a clearly deliverable outcome, great candidates for tickets to give new starters in my experience include:

• Off by one errors
• Adding a new button
• Setting up a new alert / monitor

Tasks like this are unlikely to get someone stuck in the weeds, but quickly give people something they can point to, to reassure themselves they’re not putting the breaks on the team’s productivity. More boring options include writing up documentation, adding test coverage and so on but these can also be fantastic for a low pressure introduction to the wider ecosystems and info support channels.

Phase 2 — Right behind ya

Once I think they’ve had a good amount of time to get to grips with the essentials of the role, I try to step back a little bit. Asking for help gets a response like ‘what have you tried’ and ‘have you checked out #microservice-support?’, I’m still eager to help them solve problems but in a way that encourages them to start solving problems without me. This is a tricky phase to get right, you don’t want people to suddenly feel like they’re out there on their own or like they should know everything already. During this phase my go to tickets are things like:

• Find out from X what the message should say and implement it
• Use this API doc to make the call to the backend
• Use this example implementation to add a new, similar feature

When people have given me tasks like this in the past, it helps me get used to solving the new puzzles involved in my job while knowing there’s support nearby if I get a puncture

.Phase 3 — Look ma, no hands!

Unless you have the luxury of training up people one at a time, you’ll almost certainly have too many people on your plate to be keeping tabs on everyone at once all the time. At this point you’re there in emergencies and it’s a great time to get some feedback on if the training docs are good enough, but the day to day support and answers come from the larger group chats and documentation. You might find during this phase that you need to re-contextualise part of your previous coaching, either in the context of the wider domain or refining code with better practices once the fundamentals are in hand.

Repair Shop

It’s also really beneficial to check in with the people you’re coaching to find out if the seat’s at the right height (Are all the docs in place), are we on the right gear (am I going to fast? too slow?), how smooth is the trail (Where are the big holes in our support, documentation and culture) and making sure they don’t have a puncture (issues outside of work).

A good onboarding and coaching lifecycle includes you and the process learning and improving too!

Final Thoughts

More than once, I’ve had the chain come off my own bike while coaching someone, because I’ve tried to change up the gears too quickly. Teaching and training is also learning and growing, so here’s a few mistakes I’ve made that you can learn from:

• Making sure people aren’t drowned in terminology is great, but don’t keep highlighting that the newbie doesn’t understand — be subtle about it, explain or clarify acronyms without calling people out specifically or give them direction to the explanatory resources outside of the group conversation
• Be explicit in your expectations, be it timelines or performance
• Respect the dynamic — “Hey can I talk to you for a sec?” makes people nervous, so be explicit about what’s on your mind upfront with something like “Hey do you have 5 minutes for me to explain this service?”
• Consider how your tone will be perceived, I’ve learned the hard way that trying to be overly helpful can come off as condescending or dismissive of their ability, despite your best intentions