2020 was the year that Covid-19 hit the world like a hammer. Restrictions and social distancing forced Working From Home to become part of the new normal.
For many managers, this was the first time managing without being able to physically meet their team, and they struggle when unable to "grab a quick coffee" to check catch issues that might be brewing (no pun intended).
In my experience, having first worked and then managed remotely since 2012, most of these challenges you face while managing remotely really don't differ much from the challenges you would normally face as a manager.
However, there are some areas that I think become really important once you go remote.
Synchronous vs Asynchronous
First of all, I think it's useful to talk about where managing remote teams actually differs a lot from managing in person, namely how we can leverage the asynchronous nature of remote work to our advantage.
Knowledge work, which is what we mostly deal with in the software industry, is not assembly-line-type work. The whole line does not break down if everyone is not at their designated station at the same time every day. If it did, then meetings would already have killed every company on the planet.
Instead, people can do their work asynchronously and report back when it's done. This has one very big implication for how we work. Namely, most of the time, exactly when the work gets done does not matter. This shift in mindset means we can go deep into the work, with less context shifts.
Written communication helps a lot here, but a word of warning. It's easy to fall into The Trap of Availability. The Trap of Availability is when you get into the habit of being available to everyone all the time. This problem grows exponentially with every hour of timezone shift that you add to your team and will eventually lead to burnout.
Write it down
What I've found is that the more we write, the more smoothly everything runs. This holds regardless of whether you work fully synchronously, fully asynchronously, or use some hybrid model in between.
Thus, a key practice that I try to instil in everyone on my team is to document every single thing that gets decided. Every meeting that is held should end with someone jotting down decisions that were made and assigning a responsible person to each and every action that gets decided on. The same goes for decisions that are made outside of meetings, especially those that are made in a Slack thread.
Speaking of Slack, I am a big fan of Slack and I have also written a blog post about how I like to use it. The TL;DR version of it goes a bit like this: Use public channels for almost everything, including more context than you think is necessary and never, ever just say hello in Slack. Structuring the communication this way minimizes the back and forth and helps keep everyone in the loop.
Just remember, it's easy to write something down once. The hard part is remembering to keep what you have written up to date. In other words, make sure to include a step in your process updating any documents that you might have already produced in your process. In my current team, we have "Update documentation" as a final checkbox in our ticket template, which means it automatically gets included for every new piece of work that we add.
As established in one of my all-time favourite books on management, High Output Management, the 1-on-1 is one of the best tools in your managerial toolbox. The 1-on-1 is your chance to check in on and get to know the person behind the Slack avatar. 30-60 minutes every week or so, is a good place to start. You can then adjust the length and frequency as you both see fit.
Try to avoid talking about the individual work that is being done by the report, as this should be handled asynchronously. Instead, take this time to focus on giving feedback, and strategizing around the personal growth of your report. Do also make the report and provide the agenda for each 1-on-1. It's their meeting, so let them take ownership of it and their growth.
When giving feedback, be sure to make it as specific as you can. Give examples and try to tie the feedback to whatever goals you and your report have set up for them. This is important when it comes to areas where the report can improve, but it might be even more important when you've noticed they are moving in the right direction.
The strategizing part is the medium to long-term growth of the report. Do they want to become a better manager or leader, become an expert on a specific topic or just grow as much as possible in their current role? Be specific, set time-bound goals, follow up on progress, and update goals as they change.
Tactics, such as using the Pomodoro technique or how to set up a sales funnel in Hubspot, are where most inexperienced managers usually start. These are usually hands-on tips on how to solve very specific problems for the report. And while not unimportant, in my experience, they are usually less important than the feedback or strategy. So take tactics last, and if needed.
Onboarding is an area that I think deserves a post of its own, so I'll settle for a couple of high-level pieces of advice.
Leverage all the documentation that you have built up and use that as a base for the onboarding document that you have prepared. This document should describe your way of working and link to relevant documentation for each part.
Have the recruit start by updating the documentation as they go through it. This instils the value of keeping documentation up to date right off the bat.
As a manager, it's your job to make sure the new hire starts achieving goals and feels productive as soon as possible. I like to start by setting the expectations for what you would like to see from the recruit during their first 100 days on the job. Write this down and follow up.
Leverage 1-on-1s to pick up on if the person is feeling lonely and/or disconnected, and take action as needed.
Meeting in person
Every time I talk about working remotely with someone there is one topic that gets brought up without fail. Social interaction and meeting your co-workers. People often seem surprised when I not only agree but also think that meeting in person is one of the most important things needed to create a good culture.
However, I also don't believe that throwing everyone into the same building and slapping a big logo on the side of it inherently builds a sense of belonging. Keeping people in the same building does create a culture, but not necessarily the culture that you want.
In my experience, the best way to build trust within a distributed team is to organize structured get-togethers where the purpose is to align on direction and values. This holds for companies as well as teams.
Being clear about where the company is heading makes it much, much easier for middle managers and team leads to take initiative, and it removes much of the (perceived) need to micromanage. Being clear about the responsibilities and vision of a team does the same.
This means that meeting in person doesn't have to be a big event planned by upper management. Maybe it's a team meeting at an Airbnb a couple of days (or even a week) every two months for some co-located work and long-term planning. Or maybe it’s just meeting up for beers once a week.
Encourage (and subsidize) meeting up at industry conferences, and hosting and attending meetups together.
When starting up (and especially if you are doing some sort of "hybrid" solution), it's good to be mindful of where meetups take place geographically. You don't want to accidentally create an "inner circle" in your company with only the people living in the city where your HQ is located. If you have people working in different areas of the world, try to have the meetups in different areas of the world.
There is of course a lot more to managing remotely than what I can fit here. If you are anything like me you will now want to go deep on one or two of the topics discussed here. For that, I highly recommend Gitlab's Guide to All-Remote. Highly recommended for anyone being or thinking about going remote, hybrid, or remote first.
As always I welcome any feedback or questions that you might have after reading this, especially if you disagree with me. Either way, if you have made it this far I would love to hear from you. Reach out to me on Twitter or just send me an email at viktor [at] this domain.
Until next time!
After over a decade of building apps, teams and companies, I've now started coaching founders and CTOs through something that I call Nyblom-as-a-Service.
If this is something that would be interesting to you feel free to schedule a free discovery call to see if we are a good match for each other.