Remote developers need to grow in remote organizations

Is it hard? Yes, remote is always hard. Here’s the thing: open offices are hard too (for me, much much harder, for others, maybe not), but we still bring junior engineers into open offices, so we might as well bring them into remote environments and support them as they learn how to work.

I believe by saying we cannot hire juniors into remote environments we are doing our companies a disservice, and we are giving our teams the wrong message when we say only seniors can join our remote team.

We need to get better at this.

We can’t insist that remote is the future while sustaining that a new generation of engineers cannot join us for the next 5 to 10 years.

We’re telling senior developers and managers that it’s best for juniors this way.

We are assuming that junior folks don’t know what’s good for them when we disregard their interest in working remotely by saying things like “it’s best to learn in an office”.

Not everyone can go to an office and get a good job that will give them opportunities for growth. Many people function better in remote environments, and I don’t see how being a junior developer stuck in an office will be better if you can’t deal with open offices or noisy environments.

We are saying they will have too much of a hard time, that it’s better for them if the people in offices take them and grow them before they can join our teams. That’s not always the case, and that’s not always desirable.

When we say “only seniors can join a remote team”, we are giving juniors way less credit than necessary.

The real concern with hiring junior developers seems to be the amount of support they’ll need, not the fact that they’ll be bad engineers, so I have to ask: why do we act like we are hiring a kid that needs constant vigilance, instead of realizing we are supposed to be hiring a mostly grown, adult human being?

Remote employees don’t learn how to be remote from working in an office.

Most of us started out in offices, and we all had to unlearn some things to thrive in a remote environment.

Do you want to just drop junior engineers in a team and hope for the best? No, of course not. Do you want to start with junior engineers before you have figured out the very basics of remote work? Nope.

But many of us work in established remote companies. Companies that have been here for a while, companies with senior people who can mentor others.

Use that. Teach new people how to do remote well. They have no bad habits from 10 years of office work, so you have a really good chance at helping them learn how to be remote.

Creating a new generation of remote leaders starts by practicing remote leadership.

How will we create an excellent, empathetic, remote first leadership pipeline if we are preventing seniors to learn how to help everyone regardless of where they are located? Learning how to help other people grow remotely is a new skill for many senior developers.

How do we empower and create the next generation of remote leaders if we are actively stopping a huge part of the developer population from joining us in remote work?

If we only hire other seniors, we are preventing them from acquiring what should become an important part of their leadership toolkit: mentoring folks in all skills levels, remotely.

Hiring only seniors is putting the burden to grow engineers on other people.

Seniors don’t grow in trees. If you only hire seniors, you are also saying someone else is supposed to do the work of mentoring and helping those junior people improve.

It makes me think that maybe you won’t help me with my own professional development goals either.

Show us that you don’t just think on the short term.

Having a junior person in your team gives the message that you are investing in the future of your team, and you’re not just thinking in the short term.

Everyone in your team will have excellent opportunities to help others get over their mistakes, learn, iterate, and do better next time.

It will force you and your team to think even more often about how safe people feel to fail and experiment, and if you play it right, it would mean that people of all levels will feel safe to make mistakes, share them and learn from them, instead of hiding things under the rug when something goes wrong or being terrified of getting a stretch assignment because it could be risky if you need too much help or get something wrong.

Give your team the message that remote work does not mean it’s everyone for themselves.

People with less assumptions can help improve your workflows.

Here’s another reason why your team needs junior developers: the senior folks will have an invaluable opportunity to use the brains of new people who have fewer preconceptions about how things should work.

People with less preconceived notions on how things have always worked will help you improve workflows and tools in ways that benefit everyone, including very senior ICs. This can provide fresh opportunities for seniors to work on engineering-lead projects that will help them showcase their skills, both technical and leadership oriented.

For people who want to advance in both the IC-track and management track, having projects where they control the goals and can provide proof of what they achieved is really beneficial, and for their managers, it can be an easy way to boost morale.

What can you do to help remote junior developers succeed?

With all this, I guess what’s left to say is “what can you do to help your new, remote, junior team member succeed?” I don’t know if you’ll like the answer, but it’s almost the same things that you did in those shiny offices:

• onboard them both in the technical aspects of the job and in the “this is how the company runs” aspects.
• check in about onboarding in 1-1s. Regardless of level, I like to ask simple questions like “how do you think this decision was made” or “do you know who approves your vacation requests?” to understand how onboarding is going for them.
• make sure they know that you care about what they produce and how they interact and help the team, not how many hours they worked.
• on the previous note: also make sure they know overworking is not okay and that you expect them to ask for help.
• pair programming: try to find the time to pair once a week with junior folks. Be explicit that you expect juniors to be pairing up with seniors and even managers (when the manager codes). Coding together is an easy path to bring down walls.
• ensure they are participating in code reviews (if you have them) not just as the person whose code is being reviewed, but as the person reviewing code. Find tiny changes they can help review so they get used to both sides of this and integrate fast with the team.
• provide opportunities for them to do interesting things at the level they are at.
• give them feedback often. Once a week is okay. Once per month is too little.
• ask for their feedback often. Once a week is okay. Once per month is not enough.
• ensure they have a few seniors in their team so that they have people they can go to when they need help.
• provide extensive coaching on onboarding and mentorship to your senior engineers. This will be like onboarding a new person in some ways. Check in often to ensure they understand what is expected of them and can adjust their approach if something isn’t going as planned.

There’s no special magic that makes it impossible for junior developers to succeed in a remote environment. Your company doesn’t need a 200-page guide on how to make it work for them before you consider hiring one.

If your seniors are doing great, if there is psychological safety, if you have a team of peers that are eager to help each other succeed, you have what it takes to mentor juniors.

You’ll set them up with a manager that does their 1-1s weekly, you’ll help setup 1-1s with senior developers, you’ll make sure they get to know their team, you’ll provide guidance on how the company operates… this is not that different from what you should do for new people regardless of level. It’s not even all that different from what you should be doing in a very large, probably very noisy open office.

As a little time goes by, you’ll notice their work patterns, how they want to be helped, what interests them and what seems to not be their strongest suit. You’d need to notice this stuff for senior folks too. If anything, seniors can sometimes be harder to get to their A game because you might not have walked the path to the next level yourself. Maybe before being a manager you made it to tech lead, but you were not a staff engineer, so you can’t guide them at a technical level as much as you can with a more JR engineer, and since you are not as skilled as an engineer as they are, your only recourse is to help them navigate the organization instead of the code…. this is way harder to do in a remote organization than sitting down with someone to pair for a few hours or reviewing code more often than you’d like (and to be clear: we still need to do that part, we still need to help senior folks navigate the organization)

Hire Juniors. Help them become mid-level. Keep them happy and growing.

If you do this well, you’ll eventually have a new group of seniors in your team: the ones that stayed with you from their junior and mid-level years, and the previous senior folks, the ones that developed their mentoring skills and are now leading others in whatever capacity they enjoy the most.