Categories
Hiring Management Managing while Remote

Remote developers need to grow in remote organizations

Intro.

Most companies and teams know the benefits and the need to hire junior engineers; after all, that’s where seniors come from. While that’s true for many companies, for many remote leaders or folks who are considering a remote job, the idea of hiring early career engineers seems to trigger an automatic NO reaction. I’ve talked with people who have been managing remote teams for years, and they still feel like Junior folks won’t fit in, will not onboard correctly, will lack opportunities for growth or plainly hurt their company.

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.

Categories
Management Short thoughts

Engineering Management is like Debugging

Engineering management is a lot like debugging and bug-fixing at times.

Sometimes you don’t know much about a failure except that it happened. Sometimes the solution is clear but risky in some way, and sometimes you just know what needs to be done and wonder why you didn’t do it earlier.

More often than not, there’s a problem coming up that you didn’t expect and don’t fully understand. As with code, those bugs are hard to figure out, but when you do, it’s extremely rewarding.

 

Categories
Managing while Remote

Challenges of remote work

I’m a huge fan of remote work. It’d be hard to convince me to take a role where I need to go to an office every day.

Even as a remote work believer, there are still days when I wish we could get everyone in the same room for an hour without it being a big deal and involving air travel.

Where you live still matters.

Since many companies opt to hire “Remote US”(or wherever they are from) your options will often be limited by location.

This is especially true if you don’t live in the USA. The competition for remote jobs is huge, so the stakes can be higher at the interview stage. In that case, chances are that you will work in “remote worldwide” companies (which are not the majority) and it’s likely you will be setup as a contractor or hired through a 3rd party “employer of record” service.

That first day in a remote team is weird.

Joining a remote team is great, but don’t expect the first day in a new company to be the same as joining a new team in an office.

I remember my first week as a fully remote worker, it was super weird and it took a little time to feel like I could even take a step away from the computer. I was notifying my coworkers of important events like “I’ll be out for the next 10 minutes” for no reason other than being worried they might think I was slacking off 🙂

If you can’t travel at all, you’ll miss out on really important opportunities to get to meet your team.

I found that going to team retreats and casual events helps improve personal relationships. There’s very little ways to replace the unstructured interactions that happen in a team retreat setting. Making coffee together in the morning, cooking for a group, walking around the block to go grab a drink or buy supplies, going on a fun day trip, solving unexpected issues that happen during the week…. these are all things that help you connect in different ways.

A team retreat feels like 6 months worth of interactions compressed in a single week or two. Instead of talking near the coffee machine for 30 seconds, you essentially live with these people for days, either in a big house or in a hotel. You don’t get that very often in offices, but I suspect some teams would benefit from this even if they have offices to go to every day.

The counterpart to “bonding in team retreats” is important, too: it can be done outside “in person” interactions, it works great, but in my opinion you need to also have some real world interactions, especially when someone first joins so that they can feel fully integrated.

Being the only team member who never met the team in person can be super weird, but after that first meetup, things get easier.

Sometimes I miss looking around the office and being able to see my coworkers excited about the same things as me.

The last time we got some great news that affected the team, I felt a little sad that I couldn’t be in the same room to congratulate the parties involved and hang out with the team after we got the announcement.

There’ll be one on ones, and GIFs in slack. There’ll be ad hoc chats and spur of the moment calls with folks.

But even then, it won’t be the same as being in the same room. It was just one of those weeks when I wished I could grab a cup of coffee or a beer after work, without needing a video call.

Any communication problem will seem to be related to being remote.

That one bugs me, but I’m guilty of this too. Some problems are clearly related to the remote aspect. John says “ok” in a DM and leaves, and now someone is left spinning for a day because they thought something was wrong. John is always so cheerful, why didn’t he add any emoji? WHY? Anyway, I’m not saying this happened to me… but yes, yes it did happen.

Some problems are more likely to be related to remote work.

Some problems would be even worse in an office.

There are things that would be more or less the same, but maybe they would present differently and have the same result, like John making a decision while chatting with Juan in the office and forgetting to document it and let the team know. Six months later, there’s confusion about how this happened, who made the decision and when. This is the type of thing that can happen in an office, but when something similar happens remotely, we tend to attribute it to remote work instead of just thinking “someone forgot to document a decision”.

What I’m saying is that remote workers are extremely aware of the fact that their work style may be problematic at times. This tends to be good, because we obsess over having every decision written down and sharing notes from meetings (and when we don’t, great people call us out, loudly).

Remote workers seem to be in a state of constant introspection about whether the remote thing is working out, and so we tend to think everything is a remote work issue.

Kanban board out of date? Must be the lack of whiteboards.

John forgot to mention a deadline before his vacation? Must be the remote thing, if we had seen John leave through the front door for the week maybe someone would have asked about it (in case you are wondering: people in offices also forget things sometimes).

You need to be explicit about keeping in touch.

Since you won’t run into people while you make your morning cup of tea/coffee/whatever, you need to be intentional about “running into” folks online.

If you don’t make an active effort to talk with your team, you may never actually have contact with them except for short messages in GitHub issues and other focused  tools/activities.

This is fixable by setting up 1-1 calls, instant messaging, hanging out in the remote “water cooler” type channels and talking with people there, etc.

It’s just different, and you need to be more intentional about it, especially at first.

Time zones

Time zones in a remote team are one of the main friction points. If you wake up and half your team already finished their day, you’ll need to adjust how you work.

In my current job we try to adjust things to be as async as possible, and it mostly works. This includes most of the on-boarding activities, day to day communication, development, discussions about strategy, etc.

Just because we need to work in a more async way it doesn’t mean that everything is done asynchronously, just that we optimize for our situation instead of optimizing for synchronous work. Sometimes we have to make sacrifices and join a late or early meeting, but generally the team tries to avoid having the main discussion be synchronously and opt for google documents instead to give people a chance to write down their thoughts and give their input ahead of time.

I really miss whiteboards sometimes

This one is weird, but I liked having the ability to walk up to a whiteboard with a team when I needed to collaborate on a hard problem.

Digital whiteboards are okay, but they don’t necessarily replicate the experience of the analog ones.

Solving this “lack of whiteboards” issue to me comes down to unlearning some behaviors, sending drafts of how I think something should work, getting on a call and discussing it, and then iterate on shared documents with others. Sometimes even creating the diagrams right there in the call and adjusting them together as a pair or group.