Hi everyone. I'm Jessica Reeder, All Remote Campaign Manager at GitLab, and I'm here speaking with Eric Johnson, Executive Vice President of Engineering also at GitLab. We're going to talk today about remote leadership and why that is different from traditional leadership. What remote leaders need to know. Eric, hello, welcome. Hi. Thanks for having me. Great to have you. Let's jump right in and start by talking about how remote leadership is generally different from leading an in-office team. Sure. I think one of the things that comes to mind is my wife's field, psychology, and she's taught me quite a bit about it, and one of the most significant things I've learned from her is how people learn. The primary way people learn is really by observing the behaviors that the leaders they're around are modeling. Secondly is what is coming out of those leaders' mouths, what they're telling them to do. Then the distant third is negative incentives or punishments and that really doesn't work at all. I wouldn't advise doing that. I think leaders commonly forget about the first one. Another way to say would be, walk the walk and talk the talk, that phrase. But the idea for instance is, if you're telling them, hey, take vacation time or something like that. If you're not doing that yourselves, they're going to get a strong signal that it's really not okay to do that. You need to be cognizant of that, and not just take it, but almost do what some leaders find uncomfortable, which is advertise things like that. I happen to be about to take a stay-cation next week, and I've got it in my staff meeting and I keep reminding people whether it's a skip level meeting or something I thought, hey, heads up, I'm taking a vacation. It's not because I'm being flashy and letting them know that I get to take time off. It's that I'm signaling, hey, it's genuinely okay. We're telling people to take vacation, but also we're doing it ourselves, and that they should as well take care of their mental health, their family and these other things. I think this becomes even more important in remote environment because you have less time in front of your employees. You have to really pay close attention to those moments where you are in front of them and make sure you're modeling the things that you're telling them you want them to do. That's one. The other thing that it seems to be unique about remote work is that, I view detecting burnout as a management and a leadership responsibility. That is that much harder to see in a remote environment. When you're in-person or on-premise, you see behaviors like in engineering context where someone is showing up five minutes late to the stand-up every day in a week or something like that, and you pick up on these subtleties. You don't have those subtle avenues to get that information. You need to be more deliberate, need to be asking those questions in one on ones. You need to be looking for other behaviors and you really need to be coaching your employees to manage their own time, and their own burnout and schedule a walk in the afternoon or as I mentioned, take vacation time and whatnot, but be cognizant that that's going to become more of a challenge, just making sure employees don't burn themselves out. Another thing is when you're remote, you really have to focus on asynchronous work. People need to be able to work independently on things, and so so you have to focus on work breakdown. Take a large project, break it up into chunks. Something that someone can take offline for half a day, a day, a week, and come back with a result, and then integrate that result with the pieces that their teammates had been working on, so that you complete the project together. Work breakdown, or work shaping, is that much more important in remote organization. When people are working asynchronously, you have to be cognizant. Every time you're faced with a challenge or a new workflow, you have to think about like, how can we get this to work in an asynchronous fashion? But then also be cognizant that when that stops working, you do have to use synchronous modes of communication like a relatively expensive Zoom meeting, and I say expensive because if you've got people in different time zones, and you have to make sure all are awake and working at the same time, and that can be hard to achieve. You don't want to do that very often or more often than you need to. The idea is be asynchronous by default to work hard to create asynchronous workflows for new challenges and then be cognizant of when it stops working for you, and when you need to fall back to relatively more expensive modes of communication. Then another thing that we see, because people happened to be going remote in emergency fashion currently is, there's an instinct amongst managers that people might not be working as hard, and that they should purchase some form of employee monitoring software. What I would coach leaders to understand is that we actually see the opposite behavior. We're seeing people work much harder than usual, which means, I advise people, it's a natural instinct to have skipped the monitoring software and what we should actually focus on is coaching people to not work so hard that they're burning themselves out. There's a lot of stressors going on in the current environment and you want people to be productive over long time spans, not in fits and starts, or short bursts of artificial productivity. Be cognizant of that. Skip the monitoring software and focus on managing burnout, coaching, vacation time, those other things I mentioned. I think that the wish to monitor employees comes from a good place. It's wanting to make sure that you're leading effectively and that people are able to do their work, that they're able to be productive and that goals are going to be met. But it's different in the remote environments. When a leader is working through this transition, or getting ready to lead or distribute a team, what are some ways they can educate themselves and become more knowledgeable and prepared? That's well said, I would say it's just a crutch you can lean on when you're in an on-premise office environment. It's natural to use, the fact that you can see the production floor as part of your management style and just be aware that you won't have that when you go remote and you need to build a different set of skills to manage the productivity and engagement of your team. I think the GitLab handbook is a great resource. We published it for ourselves but for transparency we make it available to everybody and there's a lot of information in there. Caveat it and say that we're all remote and we've been doing this a long time so there is a level of detail in there that may not be useful for you depending on what time horizon you plan to be remote or what your long-term goals are. Try to focus on the things that are really important when you're doing this for the first time or if you're doing it in an emergency fashion. Remote is new so while there's hundreds of hours and business schools devoted to how to manage, how to lead traditional companies, there's not as much content out there. Aside from the GitLab handbook, lots of videos and other types of publishing that's going on, don't forget to talk to your network. Reach out on LinkedIn and mine the knowledge of the people you've connected with throughout your career. Try to draw from them what's working for them and then integrate that into your organization. Also, don't skip the opportunity to do this internal to the company. It's not just what other companies are doing, but it's about what other leaders in your organization are doing. One of the things that happens at a remote company is silos naturally develop because you don't have those opportunities at the water cooler in the hallway or at the lunch table to understand what's going on in different functions. So you have to be a lot more deliberate about broadcasting what your functional area is doing. Go and encourage other leaders to do the same and then make sure you and your people are consuming that information. Some of the things we've done at GitLab is we've developed this processor on daily group conversation. A group conversation is any functional bit of the org. They do a short presentation then it hopefully quickly goes into a Q and A about the things that they're working on, their priorities in the moment and what they need from other groups. This is specifically meant to take the place of the fact that you're not getting that organically from an office environment. So I encourage leaders to be very deliberate about that cross communication and making it happen in a somewhat formalized way. Well said that's an excellent recommendation and I do love those calls. It also provides a way for people throughout the company to get a little bit of an idea of what's happening. What are some other specific actions that leaders can take? Say they're entering a remote transition or planning to take on a remote team. What are a few specific things they can do right away? I think it's important to acknowledge that communication is a challenge. It's a challenge at any company. But I think it becomes more of a challenge in remote. We're big believers that being all remote is a net benefit to the company, but it doesn't mean every aspect gets easier and I think this is one of those individual aspects that gets harder. We've had to strategize around it. One of the things we've seen in engineering is we need managers and leaders to do what we call multimodal communication. Everything that is important that they need to communicate out to their teams, they need to be comfortable saying it three times in three different ways, let's say. The point of diminishing returns is really when they start to feel like they're repeating themselves. It's probably just far enough. We say that if you do multimodal communication, you have to work really hard and even then you probably realistically only reach to about 80 percent of people. When that change becomes real, you should still expect that one person at least to raise their hand and say, hey, I wasn't informed. You know that you've done your best if it's not you that says, oh, we did broadcast this out. It's one of that persons peers that says that to them, that's probably the best you can do. In fact, for something really important awhile ago we did a new process, we call it Hacker Acknowledgment. We literally set up a Google form and it had a description of what we needed people to understand whether I acknowledge it or I don't acknowledge this, so I need to ask questions, but we're uncomfortable doing that. The intention was literally to get to 100 percent of people. The nice thing about having a Google form is because we can track that curve. Sure enough, with a couple of weeks of multimodal communication, we reached roughly about 80 percent of people. So the 80-20 rule was a good guess there. Then it took another 80 percent of the total time to get to those remaining 20 percent of people. So communication is really hard. It's not unique to GitLab or being an all remote company, where you do have to work harder in the remote context for sure. Other specific actions I could think of are make sure employees are investing in their workspace. Not everybody has an office at home. If you've got an employee who is, let's say, sitting on their couch typing like this on their laptop, they're not going to be comfortable, they're not going to be productive, so I'd encourage you to look at your expense policy, it is a business expense I would advocate and make sure people are investing in having a nice webcam, having good lighting, having a workspace, maybe it's even outside of their home if they don't have the space in their home, if it's safe for them to do that and to treat that as a replacement for the benefits you're giving them if they're in the office. The other thing is that your version of your documentation culture is really important, we've all been in those meetings where people are, maybe it's a design change or something like that, and you realize you're talking past one another, everybody's got different ideas about what the topic is in their head, and then you have a designer come in with an artifact that everybody could look out and suddenly crystallizes, you're all talking about the same thing and you can suddenly make progress. The same thing is really important in other contexts, you need to work on your documentation culture, so you've got those artifacts, you've got the written version of whatever that process is or whatever that product change is, and it'll anchor those conversations. Another thing is, I think a lot of people view some sort of hybrid remote model as an iteration towards going all remote, but I think having an on-premise office is easy in the ways we've described and being all remote is also easy because it's a level playing field. Hybrid is actually a danger zone in between those two things, if you're treating it as a way to potentially go all remote, you need to be cognizant that it's actually more difficult than all remote. For instance, if you have a team that needs to be on-premise, maybe you've got a hardware team and they need to be in the office because they've got their hardware in the loop simulators or something like that and there joining calls, they might be tempted to go into that video conferencing room, sit around the table, but what happens experience-wise is the audio is always bad because half the team is usually far away from the mic and the team is laughing about inside jokes, something they shared at lunch or something like that, and then the people who are truly remote are unintentionally excluded from what becomes the company culture. A best practice if you're going to do hybrid is to treat your calls even if they're hybrid as all remote, ask those people who happen to be co-located to remote in from their own computers with their own headsets and their own audio, and then you'll create that level playing field and not unintentionally exclude anybody. Yeah, that's a huge, I think a very current misconception about remote is that hybrid can be in transition easily, there are a lot of things that we need to consider and we're learning those as we go, a lot of subtleties about this operation. Anything else that leaders should be aware of, that leaders may not know or that they should test out? Yeah, I would say being a metrics-driven organization is really important, I think it becomes important for every company when you get to a certain size, particularly in terms of headcount, I wouldn't advise that a 40-person company with a 10-person engineering team invests a lot of time in their productivity metrics because you can rely on the stand up and these other things to make sure that everybody's aligned to doing the right thing. But when you scale up into the hundreds or thousands of people range, if you're not using metrics to manage to at least some extent, you're going to miss trends. When that inflection point is triggered if you're remote, it becomes that much more important to keep people in line or maybe the other way to think of it is that if there's an inflection point for you, it moves up, I almost tipped over my water there. It would have an earlier in that timeframe because you are all remote. Metrics again, they allow you to confirm your instincts, they'll also tell you things that you are missing wherever you have blind spots and when people are distributed and they're working most of the day independently, and not in the same room with one another, if they can look at a chart, they can understand what they need to do, particularly, when they encounter an ambiguous situation, I'm confronted with some A, B decision that we didn't anticipate, what do I do here? Whether I'm designing a process or writing some code, if they understand the metric that you're optimizing for, they'll usually make the right A, B decision and get through that ambiguous situation. Yeah, very well said, excellent insight. Excellent insights throughout, I really appreciate your time sharing this knowledge with all of GitLab and also with our learners at Coursera. Thank you very much, and it's been great to have you. Thanks for having me.
