Lessons learned managing remote

Transcript

Cal: Hi, and welcome to the Frontier podcast, sponsored by Gun.io. My name is Cal Evans; I’m your host. And my special guest today is Dave Hall. Dave is coming to us all the way from the other side of the world. Say hi to everybody, Dave.

Dave: Hey everyone.

Cal: And you can tell from his accent–I mean, of course–he’s in Louisiana. No, I’m kidding. Dave’s all the way over in Australia. It’s 1:00 AM for him. So we really appreciate Dave staying up and talking to us today. Hey, we’re gonna talk about lessons learned managing remotes. Okay. Everybody, with the COVID everybody, a lot of people, have gone to remotes, and managers have had to learn how to deal with managing remote. So we’re gonna talk about a few of the lessons that Dave has learned, and we got some questions we’re gonna ask him. So Dave, I do appreciate you taking the time to be with us today. Before we dive into remotes a little bit though, let’s talk about the difference between a remote team and a distributed team. In your opinion, give us the difference between those.

Dave: Yeah, so I say that they are quite different things. So, a remote team is where you have like a central office, or a core group of people that are co-located, and then you have a few people spread out over the place. But it’s still primarily, you know, the office and then the people who are remote, whereas distributed is: it doesn’t really matter where people are. It’s focused on everything assuming that two people working together aren’t co-located and building processes around having people spread out and in different places. So even when people are in the same physical location, you still have processes that mean that everyone is able to take part in decision making, the general engagement.

Cal: Very good. It’s an interesting distinction. We’re gonna use the term remote here a lot, but I think what we are really talking about, what you’ve described, is more of a distributed team. And that is the type of team that I’ve worked on most of my career. The past 20 years, I have worked on distributed teams. A couple of those have been remote teams, where the majority of it’s in one place, but a couple of us are spread out, but for the majority of the time, I’ve worked on distributed teams and really enjoyed it. So, what’s the biggest benefit that you enjoy by having remote developers or that you enjoy about having a distributed team?

Dave: Sure. So, I say there’s actually two really good benefits. One is the benefit for the organization, which is that they can get the best people available. It’s not the best people who are within commuting distance of the office. They have a far larger geography. So, the team that I lead, we have people spread from Chennai all the way through to the UK. And so, we’ve got quite a distributed team and then there’s myself in Australia, working time-shifted, but that gives us billions of people that we can choose from. Whereas if we decided that we only wanted people within a commuting distance of the London office, like London is a big city, but there’s not billions of people around London. So it reduces the number of people that we can attract to the team.

And the other benefit I think, is for the individual team members, because when you are in an office, there’s a bit of pressure to kind of be there at nine o’clock and not to leave before five. Whereas if you have a distributed team and you’ve got people in different time zones, it gives you more flexibility. So myself being based in Australia, I generally work a time-shifted day. I get up in the morning, usually late morning, you know, have breakfast and then check in to see what’s going on, see if there’s any problems I need to deal with. And then in pre-COVID times, I would go out and have lunch with my partner, go shopping, go out and do whatever I wanted for the afternoon, pick kids up from school. And then I would come home and start to get into my work day. And it just gives a lot more flexibility in your work day. You know, you still need to be available and engaged and things like that. But I think when you aren’t stuck in the office, there’s a different mentality about how you measure how well people work.

Cal: Absolutely, and I think we’re gonna talk about how you measure that in a minute. Uh, your first point though, about ‘it opens up the gates for companies to have access to a lot more developers’. I’m famous for saying–and this, this makes a lot of recruiters mad–if you’re not willing to consider remotes, then you’re not looking for the best person, you’re looking for the most convenient person. And I’ve been saying that a while. I tweeted that out just recently again, because a company that I would love to work for, just won’t consider remotes at all. I’m like ‘In this day, really? You’re making people go into the office?’ But hey, to each their own, that’s, you know, that’s their policy. I respect that.

Dave: Like, I’ve been working for overseas clients since 2003. I’ve worked a mix of remote and distributed and yeah, the companies that really get distributed are the ones that I found are the best to work for.

Cal: Yeah. I just came off a contract for two years with a company that had a remote team. There were a few people remote. But they were, when I started, they were all in the office. Most everybody else was in the office. Of course with COVID they shut that down. Everybody went distributed and because they had the policies in place already and everything, the infrastructure in place, it took absolutely nothing for everybody to just go, okay, we’re working from home. Hey, let me ask you the next question. What’s the biggest challenge that you have in managing distributed teams?

Dave: So I think that it’s a bit tricky when you are trying to measure how well people are doing. Because, you know, when you are in an office situation, if someone’s struggling, you can kind of see that and you, you can pull them aside and say, ‘Hey, is there anything I can do to help you out? Or is there stuff going on that we need to deal with?’ Whereas when it’s, you know, just everything on zoom and, you know, in chat, you lose a bit of that broader context of what’s going on for people. So, you have to be more proactive in communication. And I also think it’s good at the start of a call to just have a bit of general chit chat with people, rather than, you know, it’s right on, you know, 10 AM, straight into the meeting agenda. So provide some opportunities for a bit of additional engagement. So you know a bit more about what’s going on for people.

Cal: I had a team back in ‘99 and I hired my very first remote, you know, we were all in the office, but I needed this one person. I needed somebody that could hack the Linux kernel and write me a module for that for the app we were doing. And there was nobody in the area. So I hired a friend of mine that was out of the area and keeping tabs on that person, not ‘are you working?’, but ‘are you okay?’ Because if we’re all in the office and somebody walks in and slams their coffee cup down or slams their door, you know there’s a problem. But if they’re, if you don’t have those immediate cues, that can be a bit challenging. And I found myself, back then, all we had was Skype and IRC, and I found myself, you know, on a regular basis, just pinging Adam and saying, ‘Hey, you doing okay?’ <laugh>, you know, just making sure that they’re okay and hoping he’s telling me the truth.

Dave: It’s so important to understand what’s going on for your team. And I think that applies not just for distributed teams or teams with remote people, and even like, if we do return to a lot of people working in offices, actually understanding what’s going on for people in your team is really important to ensure that you’re supporting them properly.

Cal: Yeah I totally, I totally agree with that. Now you were managing remotes and distributed teams pre-COVID. Did already having remotes and distributed teams set up, did that help everybody else make the transition, or was there still some problems?

Dave: So for us, we were already largely distributed. Like, we’ve had people work from various locations for a long time, but there were some people in the organization who weren’t used to working from home and weren’t really set up for it. And some people adjusted quite quickly. Other people, it took them quite some time to adjust, and also not everyone is as lucky as I am. I have a converted garage that I work from as my office. We’re about to move where I’ll actually have a two-room office in the new house. I’m very much looking forward to that. And so I’m very privileged. Whereas some of my team members, they’re at home with young children, small housing, you know, they’re trying to work at the kitchen table. And so it is challenging for them.

And I think companies really need to understand that the different work environments that people have and make allowances and give people support because not everyone is lucky enough to have like a large multi-story, uh, not multi-story, multi-bedroom house, where they can just set things up and, you know, not everyone wants to have a desk with a webcam where they’ve got the bed they sleep in every night over their shoulder. So, you know, for us, there have been some challenges, more for some of my team members than for myself though.

Cal: That’s an excellent point. And, as things start to open back up–we’re seeing things here open back up a little more–I always remind people that if they want to continue this, don’t call it ‘work from home’, call it ‘work remote’ because, you know, there are days when we’ve got a nice coffee shop nearby, a Panera bread with nice outdoor seating and good wifi. There are days, you know, I’ll sit there and do my morning there and enjoy coffee and something to eat because I can work remote. If you do, if you tell people you wanna work from home or tell management, you wanna work from home, they have this mental image and you’re right: we all start at the kitchen table. And, you know, we all work there. I, like you, I’m lucky enough to have an office, not a big office, but it is crammed full of production gear and all kinds of fun stuff right now.

But at least it is my place. And, you know, I did some of this when I had little kids also, but for the most part, my kids were grown. I didn’t have to deal with all of that. By the time I started doing my remote work, but you’re right. That is a challenge for a lot of people and companies need to be sensitive to that. Managers need to look for that and be proactive about it, find ways that they can help. You know, and I don’t have any suggestions for how they can help, but each situation’s unique. They need to be looking out for their employees and for their, you know, for their, their mental health.

Dave: Yeah. I think we’ve come a long way with that stuff too. Like when my kids were young, they’re now teenagers. Like when I was on calls, you know, they were always told when the door shut, you leave Dad alone, he’s working, but kids being kids they’ll still wanna come in. There’s the famous video of the Korean expert where he was giving the interview with the BBC and his kids just came marching in. My kids would come in from time to time. And for me, it was always embarrassing because you look unprofessional and stuff like that. Whereas I think the pandemic has meant that a lot of companies now make more allowances. It’s like, okay, you know, that person is still being productive, even though their kids come in from time to time. And having a kid coming to your workspace is really no different to having a colleague who’s going back from the kitchen to their desk, stopping by and going, ‘Hey, how is your weekend,’ or whatever. It disrupts that flow and still has an impact. So, yeah, I think companies are realizing that and are more supportive, which is great. Yeah.

Cal: I agree. And while all of us decry the drive by meeting like that–Hey, how about that local sports team–and that kind of stuff. I actually believe even though developers love to go deep and get focused on stuff, I believe that every now and then having somebody come by and bring you back out of that is actually a good thing. You know, it refreshes your mind to step away from a problem for a minute. Too many of them is a problem, but you know, every now and then, whether it’s a coworker or the kids coming in, or my dog telling me that she wants to go walk, you know, those things, they help me. So, let’s talk a little bit about onboarding new employees, because I’ve been both the remote employee that has done remote onboarding, and I’ve been the remote employee that has been brought out to the office for two weeks to be onboarded there. Since that’s not been an option the past couple years, how has onboarding new employees changed for you?

Dave: So it’s interesting. So I work for large companies and small companies, for. For large companies, that process hasn’t changed that much. You know, the person starts, say they end up on, like, a bunch of video conference calls getting to meet, you know, the new team members, talk about processes, talk about what they’re going to work on. And it’s kind of the same process that’s always been there because, with large companies, it’s rare to have, you know, 90,000 employees and an army of contractors all in one building, there’s people everywhere. So, that works better.

For smaller companies, I think that there’s still a bit of work needed in having a ‘this is what we do when a new person starts’ and having a distributed or remote-first kind of approach to onboarding. And, you know, part of that is, you know, not having to have someone come into the office to collect the new hardware, like organize to get it shipped out, aim for it to be there on the Friday (Mm-hmm) so, you know, when they start on the Monday, they can open the box rather than spending the first half of their day going ‘Wonder when the FedEx guy is going to turn up?’

Cal: That’s a good point. I’d never thought about that, but yeah. Shipped to have it there the Friday before they start on Monday.

Dave: Yeah and, you know, if people are using their own equipment, make sure you’ve got processes for handling that, and people are aware of that before their first day, so they can be set up properly. You know, for contractors, maybe that’s doing all their work in a virtual machine or whatever, but having people understand what that process will be upfront. I think it’s important.

Cal: Yep. That’s very good. Hey, what’s the one most useful non-developer tools? I don’t want to hear GitHub or VScode or stuff like that, but what’s the most useful non-developer tool that helps you manage distributed teams?

Dave: Yep. I–there’s two which I use a lot. One is chat. Some of my clients use Teams. Okay. They pay well enough that I tolerate Teams. And then there’s the clients who use Slack. And I get it that chat can become overwhelming for some people, and it can become a real distraction. At the same time, it’s a really good way for having asynchronous communication between people and moving from that need where, you know, everyone has to jump on zoom for a call to discuss something. You can work stuff out over a period of time in chat.

And my second tool, which I know a bunch of devs listening to this will probably be screaming at me for suggesting this, but JIRA. Now, JIRA is the least bad ticketing system I’ve worked with. I’ve worked with a bunch of ticketing systems. JIRA is still bad. It’s the least bad though, because I can make it do what I want it to do. And it allows me to understand where the work is at. So I’m not being that manager who is pinging people all the time, going ‘what’s happening with this piece of work, what’s happening with that piece of work’. I can go into JIRA. I can look at the board, I can see where things are at. If there’s stuff that concerns me, I can ping the dev and we can chat about it, or I can leave a comment on the ticket. But those two tools allow me to have good engagement with my team, but allow them the space to be productive without me having to be, you know, one of those managers, who’s just hassling them all the time for updates.

Cal: Yeah. I agree. And that’s very important. I think JIRA really ought to adopt that as their tagline: ‘We’re the least bad.’ <laugh> Because you’re right, nobody likes it, but it does serve a very important role. You’ve gotta have some way to do that. And the other option, like you said, is to be constantly bugging your developer saying, ‘what’s the status on this?’ You know, so having some lines of communication, but it all boils down to communication. Both of those are communications tools. I do like a good chat system that I can turn off, you know? I work with, well, I work with Gun.io and one thing Gun does very well is we’ve got a channel called ‘reporting’ and every morning, everybody logs in and says, this is what I’m working on.

And if they’ve gotta step away from the keyboard, they say, I’m gonna be AFK for so long to, you know, run errands or something like that. But if they’ve just gotta be heads down, they say, ‘I’m out for the afternoon heads down on X,’ and nobody cares, but everybody knows, you know, that that way I don’t go looking for people if, you know, if I see in reporting that they’re not gonna be answering, you know, I know I’ve gotta find my answers elsewhere, so… Now, you’re in Australia and you’ve worked with people in, like you said, in London and you work with people all over. Time zones have gotta be a real problem. How do you handle that? How do you handle just distributed teams where people are in a multitude of time zones?

Dave: Yep. So, for me, the key piece is defining your boundaries. And so I have a general rule that I’m available for 12 hours every day, from noon till midnight, local time. And I do that year round. And so, um, during the Australian summer, that means midnight for me is 8 AM in the US, for the east coast, and even earlier for the west coast. But having that, those boundaries makes it a lot easier for me to manage my time and also just not having the evenings drag on because in the past I’ve kind of gone, all right, this time, I’ll do a meeting till 12:30 and then someone puts a recurring call on 12 o’clock till 1 o’clock. And then it’s like, oh, well, Dave’s on calls till 1 o’clock, we’ve got a call that needs to happen at one that’ll be just after a call, and before I know it, my calendar’s full of stuff till 2 AM.

And then the days I need to get up early and do stuff, or, because you need to wind down once you finish a work day. So it just drags on. So my rule is midnight to–midday to midnight. It means that for people in the west coast, I usually can still see them in the morning if there’s stuff we need to chat about, and we’ll schedule a call at the end of their day, which I can do at the start of my day. And for people on the east coast, sometimes they get a bit annoyed about, you know, having to get on a call early, but it’s like, well, I’m sticking around until 11 or 12 o’clock at night to get overlap with you. We both need to compromise a bit here and that’s the other part of it.

Everyone needs to be a bit flexible. Like, have your hard boundaries, but make sure that those hard boundaries have enough of a time span in there to provide some flexibility. And I don’t expect people to work the 12 till 12, like I do. I’ve done this for probably close to a decade now, and I’ve worked other times with clients in Europe and stuff. So I’m used to this time-shifted day, but I don’t think that, you know, it’s reasonable for people to be available 16 hours a day, just in case people need it or for organizations to have an expectation that people are going to be getting up at, you know, five, six o’clock in the morning to jump on calls, to deal with things. You need to find that middle ground for everyone.

Cal: Yep. You need to do that. And you need to set hard boundaries, like you said. My very first time–I live in the east coast–and my very first time working for a company on the west coast, their favorite thing to do would be to schedule a meeting on Friday at 3:00 PM their time. Well, that’s five my time. I would accept, but I would always put ‘can’t promise sobriety.’ So, you know, cuz you’re cutting into my drinking time at that point. So, but if you still want me there, I’m with you. So yeah, <affirmative>

Now, the big problem, the problem that everything I hear from non-technical managers, when I’m talking to them about remote developers is, ‘well, how do I know that they’re working,’ because traditionally butts-in-seats is the way we measured ‘working.’ You know, if you’re sitting there, obviously you’re working – cuz nobody ever just sits at their desk and surfs the internet. So how do you handle making sure that your developers–I don’t wanna say ‘are working’– are as productive as they need to be.

Dave: Yeah. So that’s the key distinction: are people being productive? And that’s what you should be measuring. Now, I’m a contractor. I get, like, contractors – people wanna do hourly rates. I’m quite happy doing an hourly rate. If the rate is high enough, I’ll negotiate a day rate. But I do like my hourly rate. Companies generally like the hourly arrangement as well, because they’re not paying for time that is not being used. But I think that measuring ‘are people being productive’ and ‘are they delivering value’ is the key thing that you should be measuring. Not butts-in-seats, how long someone spends on Zoom or WebEx in a week, cuz you know, you can fill your calendar with meetings and then you’ve got no time for doing the action items you sign up for on those calls. So delivering value and being productive needs to be the measures and you need processes for measuring individual productivity.

And you know, you want to see people growing over time. Like, I don’t think that you can really take two developers and benchmark them against each other. Like, you know, this dev delivered 50% more points than this dev over the last six months because, you know, everyone knows you can gain points in sprints. Or this developer billed more hours than the other dev; well maybe that just means it took them longer to actually get the work done. So I think you need ways of measuring ‘are people delivering value and being productive,’ and that’s going to be different for different teams. Because what you consider ‘delivering value’ may be different to what I consider to be ‘delivering value’ as well.

And you know, maybe doing the job properly the first time, like, you know, writing clean code, having tests, all of that stuff. For some organizations, that will be highly valued. For a startup that’s just trying to get the product out the door, there’s more likely to be a – ‘just crank out the code. Don’t worry about tech debt. Once we get the VC money, we’ll come back and fix that.’ And so, you need to determine that the metrics and you also need to make sure that they’re not easily gamed because developers are problem solvers and you know, metrics are just another problem to be solved. So whatever metrics you set up, if they can be gamed, they’ll find a way.

Cal: Good point, good point. Hey, we talked a little bit about this earlier, but communication is incredibly important when you’re managing distributed teams. We talked about how you communicate with your developers, but how do you make sure that the team itself is communicating?

Dave: Yep. I think that’s really important because having devs talk to managers, you know, that makes sure that the developer is on the manager’s radar. That doesn’t mean they’re working well with the rest of the team. And I think that it’s better, or it’s actually critical, for them to be able to work with other members of the team. Like, you know, them telling me what’s going on – that’s good. But I want to see the team work together and the team delivering. And I know that some organizations, they want everything in the group chat so they can see that people are communicating. I think that there is a time and a place for group communication and that group communication in group channels is really important. But also having people DMing each other when they’re unsure of stuff.

It means people are going to be more likely to ping someone and say, ‘I’m not sure about this.’ Rather than spending, you know, half a day with Google and StackOverflow, trying to figure it out. Because, you know, there is a certain degree of feeling shame for some people by saying, ‘I don’t know.’ Like, I’m at the point in my career where I’m happy to go, ‘Hey, I don’t know, but gimme half a day, I’ll try to figure it out.’ Or, ‘Hey, can you give me the info, so then I can jump on a call and make it sound like I know what I’m talking about.’ So, I think that having the team be confident about being able to communicate in a group, but also directly with each other, is important. And on my team, we’ve got people who speak a range of different languages.

Now I’ve had some conversations where some people have suggested I don’t care, seeing multiple languages in a chat. Based on what I’ve seen, you won’t get people using their native language in a chat which is primarily English, but they will set up another channel, which is just for discussion in that language. I don’t need to be there because I’m not gonna run the whole chat log through Google translate. I’ve got better things to do with my time, if they’re–you know, they might be sitting there going, ‘Oh, Dave’s such a bad boss.’ I don’t care. Like, so long as they’re talking and they’re delivering, you know, I’m happy. And I’m sure that there’s multiple native language chats at work that I’m not even aware of. And that’s fine. That means people are collaborating.

Cal: That’s excellent. And yeah, you’re right: DMing, it doesn’t all have to be in the main channel. I learned this; I spent two years on a team and I thought everything had to be out there in the open. And I would ask, you know, what I considered embarrassing questions about, you know, basic stuff. And finally one of the developers said, ‘look, if you got a question just like that, just DM me, okay, we can talk about this.’ And from that point on, you know, I’d help people when they ask in the channel, but if I’ve got something that’s not relevant to everybody, I can just ask, you know, the appropriate person.

Okay. Here’s the hard one: you’ve got remote developers, you’ve got onboarding, remote onboarding. How to put this politely… How do you remote off-board someone? How do you deliver bad news via remote?

Dave: So I’ve seen several news stories where companies have invited large numbers of people onto a Zoom and just said, ‘if you’re on this call, see you later.’ I think that’s an awful way of, well,< that’s horrible> Also making people watch pre-recorded videos, telling them that they’ve been fired? Just as bad. Like, it’s really tricky to tell someone that they’ve gotta go. Like when it’s face to face, it’s uncomfortable. At least with, if you are doing it over video, you hit the ‘end call’ button and you are not actually watching them pack up their desk as they leave. Yeah. Which, you know, I kind of–I’m happy that you avoid that bit, but it’s not easy. Letting people go, doing it over video does feel a bit impersonal.

I’ve, you know, quit jobs via email in the past on remote jobs where, you know, it’s kind of felt like it’s time. I’ve done it over the phone, I’ve done it face-to-face. As the person quitting, it doesn’t feel good. I’ve actually been lucky enough that I haven’t been fired, but I have fired people and yeah, doesn’t matter the scenario, it’s always uncomfortable.

But one thing that I think, it doesn’t matter how you are letting someone go, having processes to remove their access at the appropriate times is important. And, you know, I’ve been in situations where I’ve been given a heads up that someone will be walked in a couple of hours and to make sure that at a certain time, their access to everything is removed. Now, not a great position to be in, be the person who is ripping out the access, but having the forethought to plan for that can be important. But generally try to have a good relationship with people where you can go “look, this isn’t working, let’s have a plan for transitioning out,” rather than letting it get to the point where it’s just like, ‘see you later.’

Cal: Yeah, yeah. I’ve actually been on the receiving end of that call before. And it’s not happy for either one of them. And I was good friends with my boss. I knew that this was painful for him. I knew that, you know, that, and we both knew why this was a financial decision by the company. It had nothing to do with performance or anything else. You know, but it still, it wasn’t a good, a good feeling. And, quite honestly, I felt that he dealt with it with more empathy and compassion over Zoom than, you know, I’ve seen other people deal with in the same situation. So, you know, as long as you’re being honest with people, as honest as you can be in that situation. You know, HR has very specific rules about what you can and can’t say so… anyhow. Hey, Dave, I want to thank you for taking some time to be with us today here on Frontier.

I’ve learned a whole lot. Audience, I hope you have. Thank you, Dave, for staying up with us. Audience, thank you for being here with us. Hey, do me a favor. If you have enjoyed this episode, go out to your favorite podcaster, whatever you use to stream audio, and give us a rating, you know, leave us five, thumbs up, five stars, whatever. If you did not enjoy it, or if you think that there’s some better way we can serve you, drop me an email [email protected]. I would love to hear how we can make this podcast more useful to you. Thank you. We’ll see you right here next time on Frontiers.