Starting to manage remotely

I've heard a lot of people talking about setting up a remote office recently. However I haven't heard as many people talking about how to handle a team remotely. This is something that I've dealt with for years. It's also worth thinking about even if you're not a manager, since it can inform how you manage up (the  fifth hardest direction to manage). Which I'll go over at some point. There is an inherently asynchronous nature to working remotely, but if you're used to working in an office that can be a big transition. Location based management styles don't always translate well. I'm trying to be nice, but they generally don't. The more hierarchical your organization is the more problems this is going to cause. I'm not attacking the way you have your team organized, but it's a reality that the more people one of your employees needs to talk to, the longer a task will take. The most important parts of managing people remotely are empowerment/autonomy, queueing, and communication. Let's break it out a little.

Empowerment/Autonomy

Let's start with a story. I was working remotely in Thailand for a company in the Pacific NW. The person I was reporting to was a colleague of mine I had worked with for years when I was still in the offices. He was/is still also a good friend of mine. He would start conversations with a simple, "Hey." Then it would be a day or so until I saw it due to a 14-15  hour time difference (don't make me look up if it was during daylight savings or not, and I hate doing time zone math). I would respond asking him what he needed, then it would be a day or so until I got a response. That meant that every exchange took 2+ days. I tried to get him to start using more elaborate emails/messages. Something to the tune of,

"Hey, how is the project doing? If it's going well, when can we expect the next milestone? If it's not, then what do you need from us to hit the deadline. If you can't hit the deadline, when can we expect you to be finished?"

That kind of thing saves a ton of time. I'm vaguely paraphrasing from The Four Hour Workweek. It does a phenomenal job of covering it and is worth a read even though some of the material is a bit dated.

This is all a fairly extreme example of back and forth in a very asynchronous workplace. I'm sure some of you are thinking that it doesn't apply, but think of every time one of your employees has to ask someone for permission to do something.

• Send out a purchase order to a vendor
• Contact a customer
• Follow up on a sales call
• Allocate time to a new task
• Help out someone on a different team

Now compound that for every person on your team. These are very real problems that add up quick. Also people like autonomy. To paraphrase Time Ferriss, It's amazing how much smarter people act if you treat them like they're good at their job. However this requires clearly communicated clear expectations. I personally work very well with task/project based deliverables, but that doesn't always translate to other industries. For instance customer service doesn't do too well with that. I worked customer service/inbound support for years, and being too metric driven is terrible.

I suppose that part of it comes down to whether you have an idea of what a good job looks like for people you're managing. If you don't, that's a huge issue. If you do then it has to do with communication.

Queueing

So People talk about multi-tasking. People can't actually multi-task. All of the research shows this. What they usually mean when they say that is quickly switching between tasks. However, every time you switch tasks you lose some productivity. Good engineers I've known can tell you about how long it takes them to context switch. This comes up a lot in software development due to the nature of the job. Also some places do very granular time tracking by project. That's the worst, by the way. People hate that. Don't make your team do that. Gag.

However, when you're working remotely and it takes a bit to get a hold of someone then you need something else to work on. This means that you need to make sure your team has multiple things to work on that aren't dependent on their other tasks. Some individual tasks in a project might be able to be accomplished out of order, but there are going to be some dependencies.

A good way to think of it is, "Can they work on either of those today?" If the answer is yes then they are probably discrete tasks. This means that they can be queued. There's ticketing/time tracking systems that make this pretty easy. I like Trello for that. It basically digitizes the idea of having tasks on post-its that you put on a bulletin board. I generally recommend just making three columns with labels like

• To Do
• Doing
• Done

People tend to over complicate this kind of stuff

I operate completely off of a queue. It's the only way I've found I can stay sane in a busy work environment. If I need to get a hold of someone I send out the email/message, then I set a reminder on my phone/calendar to follow up in a set amount of time, then I take it off of my queue. It's off my queue until the reminder, and I move on to the next item. I don't even have to think about it.

The purpose of this is that your team can work on tasks until they hit a roadblock, but then they aren't just sitting there waiting on you, or someone else to respond. They move on. The amount of discrete tasks that they are going to need will vary, depending on how long they take, and depending on business requirements. In software, if you use agile methodology, we tend to outline tasks for something called a sprint, which is around 1-3 weeks, depending on the company you're at. The amount of tasks will also need to be clearly communicated.

Communication

Communication is key, as in all parts of life. However it's important not to just have the semblance of communication. The perfect example of the semblance of communication with no actual communication is the overfull meeting. Don't do that. They suck. No one likes them. If you have have to have a meeting then make sure their is an owner that keeps it moving, an agenda, and keep it as small as possible. Only have people that HAVE to be there on it.

Also don't require yourself or every manager to be in every meeting. That's another way of bottlenecking productivity. I'm also not really including short video conferences as meetings. I use those almost like phone calls at this point. I would probably just do voice calls, but I end up screen sharing a lot these days due to the nature of my work. This is useful not just for coding, but also for going over documents, projects, or websites.

I worked at a place for years where I ended up being head of a very small department. It was really just me and two other people. More of a technical lead than a manager. However I spent 30+ hours a week in meetings because I was required to be in all the management meetings even though I almost never had anything to say in them. This was in addition to 30+ hours a week of engineering/project management work.

In those meetings I didn't even want to be there, and kept myself muted the entire time so that I could still get my work done. I asked why I needed to be in there, and they said it was important. I could have pushed the issue, but it would have been politically foolish. Don't force your team to make the choice between pissing you/other managers off or getting their work done. It leads to lower job satisfaction, and lower performance. Also it's kind of a dick move. If you're careful with your hiring then I assume your team takes their work seriously, and everyone wants to do good work and make substantive progress. Let them.

Thoughts

One of the best pieces of advice I ever got in my career, from one of the best managers I've ever had is that good management requires putting aside your ego. He never verbally told me that; he just demonstrated it every day in the years we worked together. A lot of bad management practices are, at their heart, a way of making us feel more essential. However if your team is rocking out, then you're doing your job as a manager well. Everything else is kind of secondary.

With remote work we have to endeavor to get out of the way even more as managers. One of the biggest counter-arguments I hear about this is, "What if they just screw around and don't work?" Well, then they were probably doing that on the job too. If you don't trust your team you have much bigger problems. People like to feel appreciated and accomplished. The point is that you should facilitate your team getting their work done. Make it as easy as possible and set them up for success. The more successful and fulfilled your team feels the better the work gets, and that's really why we're all there. Also because we get paid. That too.