“It’s really hard to get mentorship, I don’t have the support I need.”new remote developers
Remote or not, one of the first skills we need to teach junior developers is how to ask for help.
Junior devs often fear that reaching out will make them look bad. To help them get over this problem, their team needs to demonstrate they are eager to help.
One the other side of this, we also have to teach new devs how to google concepts, or how to debug a problem before asking for help from a senior engineer. In other words, we have to teach them the skills they need so they can begin to fix the small problems they run into, and we have to give them frameworks or guidelines that make the decision to ask for help feel obvious and like it’s “the right thing to do”.
While trying to teach new engineers how to google their problems, we also need to avoid making them feel like they are a bother if they reach out.
Be explicit about expectations
If you want them to ask as soon as they have a question, say so. If you want them to batch questions every couple of hours, say it.
Encourage questions, and set a simple decision making framework for new developers.
“What if I’m bothering them ? I don’t want to interrupt them all the time”junior dev
It’s common for new employees to feel like they are bothering you… while you are actively waiting for them to please open up and ask for what they need. If they aren’t asking for help nearly as much as you expect them to, and they seem to be getting stuck or taking too long on tasks, make sure you continue re-setting this expectation to ask for help, and repeat yourself until you’re bored of saying it.
If a junior developer isn’t making progress because they are scared of you, that’s a problem waiting to explode in your face. Act quickly, and ensure they never wait for hours just to ask for help that would have taken you 30 seconds to provide.
Give them a framework they can use to ask for help.
Why isn’t the task done? I gave them a really easy bug to fix.a senior dev, not realizing the junior dev has been stuck for the last 6 hours because their environment isn’t loading.
It helps to give new remote developers (especially junior!) a framework for how to decide they need your/someone else’s help. A simple bullet list can be incredibly helpful to feel confident that you did all you could and you really, absolutely need help to get unstuck.
The goal is to provide the tools for debugging and fixing their own problems, while preventing them from waiting far too long to ask for help.
I have used lists similar to this one, with a bit of context around them. If you don’t have one yet, I recommend copying it or writing your own, then sharing it with the new people in your team as they onboard.
“You will run into problems. We all do. When I have an issue, I have a short mental checklist that reminds me of problem-solving steps, and if I can’t figure it out, I know I need to ask someone for a hand. It goes like this, and I encourage you to have a similar list for yourself and to send answers to the questions when you ask for help, too.
- Did you google your problem? What did you google?
- What do you know about the problem? What’s going wrong?
- What have you already tried?
- What do you think is happening?
If googling your problem and writing down the answers to these questions doesn’t help, please don’t wait any longer and ask the team to assist you.”
There’s a lot of technical details you can add, but I’ve found that this pretend rubber-ducking on Slack is a good way to get rid of google-able questions while ensuring new team members have the help they need and don’t wait for hours just to ask someone about it.
Remember to mention that Not asking for help is a much more common failure mode than asking for help, and that you will let them know if there’s any problem with their approach, so there’s no need to worry about it otherwise.
If you aren’t explicit about your expectations, you’re creating anxiety that could have been avoided with a simple, quick chat.
In three bullets, this is what helps us get individual contributors more productive, faster:
- Giving them a framework to decide when and how to ask for help.
- Being explicit about the fact that you need them to communicate when they need help.
- Helping them learn the basics of debugging