Best practices from distributed team management across 30 countries with Chris Overton of Elastic

Transcript

Ledge: Chris, thanks for joining us. Cool to have you here.

Chris: Great to be here.

Ledge: Can you give a two or three-minute introduction of yourself and your work for the listeners to get to know you a little bit?

Chris: Sure. I’ll start with where I am now and then I’ll kind of work back through my history.

I’m currently the VP of Engineering responsible for Cloud at Elastic. Elastic is a great distributed company. We have folks all over the world. Literally, I think we’re covering more than 30 countries in Elastic and have a pretty large team here in Cloud at Elastic. We’ve built that team, as I said it’s a worldwide for some various reasons which we’ll go into the details a little later.

My history. Obviously I’m currently a higher level engineering manager but I started out my career in a small startup as a developer. I think I was the third or fourth developer hired there and worked in that company for several years. The company was eventually acquired by a larger company in the security space.

Most of my background, before coming to Elastic, almost my entire career has been in some flavor of security software. Spent a lot of years working in the antivirus world, doing very low level stuff. Reverse-engineering of antivirus executables, and designing and developing, scanning and removal in quarantine engines for antivirus products.

Expanded out of that into the security portions of network scanning. I had to work for a company where we did a lot of content filtering and those sorts of things, and then back into the antivirus industry for a few more years doing a lot of data collections and analytic work. Ran their cloud environment. It was a good experience, and sort of shifted into the cloud world.

The last few roles I’ve been in over the last, I don’t know, eight years or so, ten years or so, have been more focused on cloud technologies – still with a little bit of a security bent because that’s where I started.

That’s me in a nutshell.

Ledge: Before we connected, I read some of your work online and articles that you’ve written about distributed team management and leadership. You talked about engineers across 30 different countries. I think remote and distributed now is becoming the must-have thing for people who are particularly in constrained technical labor environment.

So, just maybe talk about that. Some of the successes that you’ve had there. What works, what doesn’t, and how can people maybe dip their toes into just starting to grow a fully distributed team?

Chris: A good place to start here is just to talk about, what is a distributed team and what does that word mean? What does that phrase mean?

People have different concepts of this but for me there’s really two aspects to it. I can split this into two parts. You can split into a distributed team, which would be a team where not all the members of the team are in the same physical location, city, office, whatever. When you have a distributed team you’re typically dealing with at least more than one time zone, so that comes with a set of challenges and that’s one thing.

When you’re talking about remote employees, remote employees are by my definition, employees that primarily do not go to an office. They may work in an office one day a week or they may not work in an office at all. They may live in a location where there’s no office for their company available to them.

At most of the places where I’ve worked in the past, we’ve had some combination of both.

So, having defined the definition of what remote and distributed means to me, I think it’s worth answering the question, why? Why would you want to do that?

I think people that have worked in companies that have a traditional office environment can see the advantages. There are some strengths to having folks being in office but I don’t think that those strengths are anything that you can’t get with a remote and distributed team.

But, why might you want a distributed team? Well, the simple answer, there’s two main answers to that that I give people. One of which is the ability to find and hire the absolute best people in the world.

When you’re trying to hire people in these specific offices, you’re really pretty limited in terms of your candidate pool. You have to really choose from candidates who are either or already local to wherever your offices happen to be or are willing to move there. More and more that candidate pool is getting smaller and smaller.

People in the tech industry have learned that the tooling has gotten to the point video conferencing and Slack and some other tools like that have created an environment where you don’t really need to be physically sitting in an office. So, that’s that.

As far as the history goes, I have a long history with this. I’ve been a remote and distributed employee almost my entire career. So, I learned some lessons early on about how to make these things work, and then to some degree it also comes down to how you hire. So, having the world be your candidate pool is a big advantage.

At the same time, you have to consider how you think about these candidates and the types personalities of the people you’re hiring. What their priorities and how they approach thinking about how they come to work every day. How dedicated they are. There’s a certain set of personality traits that employee need to have to do well in a distributed and remote environment.

Having said that, I think these are things that can be taught. I don’t think it’s something you’re necessarily born with or just an innate part of your personality. I’ve had good success bringing in people that may not really understand the concept of how things work, and kind of showing them how we do things, and having them come in and be successful.

Ledge: Maybe jump into some of those techniques that you have to train people on that don’t come naturally, either based on their previous experience with an office culture or previous leadership experiences, because I know that happens a lot too.

We’ve talked to other experts about how the management paradigms have to be upgraded. They’re not different, but you do need to set different expectations.

Can you talk a little bit about those success factors?

Chris: I think the biggest thing, as I alluded to this earlier, you need to be trying to hire people that are really engaged. Bring people in the door that are really interested in the role, that are really interested in the company and the technology you’re working on. That’s number one.

Beyond that, once you’ve hired someone into a remote or distributed team the number one thing that I usually focus people on is communication. That’s not to say that people necessarily are bad communicators and that’s why they struggle in remote or distributed teams, but I think the key point is you need to think about you have to be much more diligent, and you have to be much more precise about how you choose to communicate.

The example I like to give people is that, you’re not just going to bump into somebody at the coffee machine or at the water cooler or in the break room if you’re a remote or distributed employee. So, if something important pops into your head during the middle of the day, you have to be very disciplined in the way you communicate. You have to force yourself to stop and go and ping that person, or make a note, or send an email at that moment or in that moment.

What I’ve seen is that, in an office environment you can get away with going, “Yeah, I need to talk to Joan or John about this issue but I’ll probably run into them later, so I’ll deal with that later.” You can’t do those kinds of things in a remote distributed team because all those things will just fall off your plate.

Ledge: And the toolsets obviously make a huge difference.

Now, you’ve been doing this longer than there was reliable video chat, longer than there was Slack and tools of that nature. I wonder, have you seen it evolve to the point where the UX is much better, and that you don’t have to try maybe as hard just to get around the issues with that?

Chris: I think so. In the early years of me doing this we were all on the phone. We were using traditional teleconferencing to have meetings.

This idea that you can do real-time video conferencing with people all around the world, people on the opposite side of the world from where you happen to be, it’s really a powerful tool for getting these done. Obviously, I’m living proof that you can do it with less sophisticated tools but, yeah, the tooling has certainly improved.

The other thing that I would say about the way you communicate, and the way you manage projects and the way you do things in a distribute team, is that we lean much more heavily on asynchronous communication methods than a typical team that’s co-located in an office would do.

So, for example, I think one of the things that I try to help people learn when they come into one of the teams that I’m helping manage is, you don’t need a meeting for everything. In fact, if you’re thinking about scheduling a meeting, the very first thing you should is stop and go, “Do I really need this meeting?” because in my experience some large percentage of the time the answer is no.

Really, I think people get in a habit of leaning too much on face to face meetings, when in a lot of cases it’s actually more practical, and more beneficial to the way we manage projects, to write these things down. Put it in an email or open a ticket in your ticketing system, or do something along those lines. Document it in some sort of document and share the link to that document with everybody. Versus having to actually pull everybody into a meeting at any given time.

So, that’s one of the things we focus a lot on, is really asking meetings and enabling the team, not just the managers but everybody in the team, to go, “Hey, do we really need a meeting for this?”

No is not a bad word when it comes to scheduling meetings. If you really don’t think there’s a need for a face to face meeting for this thing, say so. It really empowers the entire team to be able to make the best use of their time, and it forces everybody to think through how they communicate.

Ledge: One of the arguments that we sometimes get against asynchronous communication tools is that, well, it’s going to slow my cycle time if I have to post a message and wait till tomorrow for an answer for an ongoing issue. How do you go around stuff like that?

Chris: For some things, it’s true, asynchronous doesn’t work. If you’re having a production outage, obviously you can’t work a production network outage, for example, in an asynchronous way. That’s a situation where you really need to get everybody at least in something like a Slack channel or potentially even on a video conference.

I think that’s the bigger challenge, is helping people understand how to treat all these things and understand which are things are appropriate to use asynchronous communication for and which aren’t.

Ledge: How do you handle reporting and how do people show their progress? It’s really easy to get to the point where you’re like, “Jeez, what is Chris doing? I haven’t heard from him.” It must be a lot about trust and delegating authority down the chain, but then how do you know what’s going on?

Chris: Obviously, when it comes to tools and technology, a project tracking or ticket tracking system is a must in this environment. You have to be able to look at things. Most of the cases where we assign work to people it’s tied to some issue tracking or ticket tracking system, so you can always see what things are assigned to people.

It’s pretty straightforward with Git, and we use GitHub at Elastic. It’s pretty easy to go through there and see what folks are doing and it’s pretty obvious when people aren’t making progress, if you’re paying attention.

I don’t know that there’s any advantage to having a person who is either struggling with a project, not making progress – or if you have a person in your team that’s just really not all that motivated and isn’t working all that hard – I’m not convinced you could actually tell that by looking across the office and seeing them sitting at their desk, versus having to do the kind of things we have to do to keep track of projects in a distributed team. Does that make sense?

I think my point is, there’s not that much of an advantage to being able to just walk up and talk to them about it, for tracking and those kinds of things.

Ledge: Sure. I think some of those old thought patterns just endure.

How does it change the way that you act as a manager? Maybe you’ve had great leaders for remote teams and maybe not so great leaders who kind of don’t get it.

What’s the difference there? Can you talk about that experience?

Chris: The difference between great leaders and not so great leaders. It’s a good question.

As a leader in a remote and a distributed team, one of the things you absolutely cannot be is a micromanager. If you’re that kind of leader, it’s probably not going to go well for you trying to lead a remote and distributed team.

It’s an environment where you have to try to hire, as I said, the best people you can find. People who are motivated and really engaged in what you’re trying to do, and empower them to make decisions and trust them to come back. That’s the other thing I stress a lot with the teams that I work with is, don’t be ashamed to come and say, “I’m having a problem.” It’s really important to do that early and often in those cases.

You have to set the tone in your team. That if you come to me and say, “I’m struggling,” that’s going to actually be celebrated versus looked down upon. It’s one of these things where the team actually runs the project. As soon as, as a leader, you start thinking, “I’m in charge and I have complete control over what’s going on,” that’s the first step to your own doom, in my opinion.

I tend to describe the way I try to work with teams as being a servant leader. My intent, my purpose here is not to stand over everyone in the team, and not to try to dictate every detail of what everyone should do. Rather, I would prefer to have discussions about what we try to get accomplished and trust folks in my team to make the right decisions or come to me for help in cases where they either are stuck they can’t. That they have some sort of an issue, they’re not sure what to do, you have to be able to trust your team to come back to leadership in those cases.

Ledge: What are some of the symptoms where maybe you need to pay attention and somebody isn’t working out? That they can’t earn the trust of being remote and of getting their work done? How do you know and how do you mitigate that, and maybe even have to just let them go?

Chris: Having done this for a long time, there are cases where people just don’t work out. Interestingly, in all the years I’ve done this, I have seen very few people that are really trying to game the system – people that are really trying to just not do any work and get paid for it. In fact, I don’t remember any examples of that.

The examples where I have had cases where people didn’t work well, it is more around places where people have either…

There are some people who struggle a remote environment. Not because they can’t do the work but because there are certain people who crave a little more of that kind of in-person contact. They actually like being in an office. They like going to lunch with their coworkers. They like going out for drinks or dinner, whatever, after work with folks they work with.

For that subset of people, they’re probably better fit in an office but I don’t think that’s specific to the work. In fact, I don’t think any of it is specific to the work or how we manage projects or get things done.

I’ve been lucky throughout my career that I’ve had a very minimal set of missteps in terms of hiring people. I’ve pretty much always been lucky enough to hire really good people, and find good people.

There have been a handful of folks throughout my career that, no matter how good a job you do trying to vet people during the interview process, you’re occasionally going to run into someone who it turns out is just not a very good technical fit. Their skillsets and their strengths don’t exactly match what do you need for that role.

In those cases, my first approach is to always try to develop those folks. Because, obviously, we saw enough in them during the interview process to make us want to hire them, and we’re in a situation now where their skillset and their abilities don’t really match the job we’re asking them to do.

So my first question to myself is really always, is there a need in the team or in the company that they are a good match for? And if that’s the case, we’ll try to align them to that, and have some discussions with those folks if they’re interested in doing those things and try to work with the person to get them to a place where they can be successful.

In other cases it may be that they just need a little help. They may need some enablement or some additional training. So I try to go in those directions. That’s usually what I tend toward.

Again, that’s not something that’s different in a distributed team. The only thing that’s different is, how do you figure out that they’re not doing well, or that they may be struggling in a particular area? And again it comes back to communication.

It comes back to communicating with the people in the team, doing the one-on-ones and skip-levels occasionally, and just keeping a pulse on how their work output has been, the level of quality and whether or not they’re able to do things in what’s considered a reasonable period time.

Again, with the technology that we have today, it’s not hard. It’s always really obvious when people are struggling, regardless of whether you’re in a remote distributed team or in an office.

Ledge: Well, what are the daily things that someone should when they’re a member of a remote team? What should they undertake so that they can be successful and make sure they develop that trust?

Chris: So, habits – good habits for remote and distributed people – sounds like that’s what you’re asking?

Ledge: That’s right.

Chris: So, I think a lot of the things I’m going to say will overlap with things you should be doing anyway, no matter whether you’re remote or whether you work in an office.

I think it’s important to have a plan. It’s easy sometimes, when people get busy, to fall into the habit of just dealing with whatever fire crops up next. And obviously fires have to be put out but, at the end of the day, the way you can be the most successful is you start with a plan.

So, if you have a set of work or things that are important… The way I personally do some of this is, I have larger project plans and initiatives and documentation plans around that but as far as a day to day kind of thing, I keep an action items list for myself that I review every day. I sit down every morning and I’ll look at the things that I think I need to try to attack during the day. If there’s anything that has come up over the last few hours since I stopped work yesterday, those things get added to the list. Then I try to stack rank those things and try to make sure that I’m making progress on the ones that really need progress in any given day. That’s one piece of it.

The other habit to get into as a remote distributed employee is just to create yourself a bit of a routine. That doesn’t necessarily mean you always have to sit in a home office.

I think it’s actually one of the real benefits of being a remote employee, is it gives you some flexibility. You can go work in a coffee shop, or you can sit outside on your porch, or you can choose to work from the couch on certain days. But I think having some routine, certain hours of the day that you’re going to be working.

Dedicate certain hours of the day to doing things like email or updating issues and issue tracking systems. It helps a lot when you do that because it can cut down on the distraction. If you go in and block your calendar and say, “For this hour of the day and for that hour of each day I’m going to be working on catching up with email but I’m going to reserve time in between to actually sit down and do design or do coding.”

You may have certain hours of the week you reserve for meetings. To try to create some boundaries, so that one set of work task doesn’t constantly create a lot of noise that overwhelms other things and cause things to fall off your plate.

Ledge: Great tips. Well, Chris, thanks so much for joining us. Really good to have you on.

Chris: It’s been a pleasure. Thanks for having me.