Remote Team Management

Dana Lawson, Shane Nolan, Peter Coppinger at UXDX Europe. Video: https://www.youtube.com/watch?v=QP4dDCU_vTQ

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Introductions

[00:00:00] Shane: Maybe before we start, I'm going to get Dana and Peter just to give a brief overview of who they are and what they do, for the folks that don't know you both. Dana, we start with you.

[00:00:10] Dana: Howdy. I'm Dana Lawson. I am the VP of product engineering at GitHub. I run product engineering at GitHub, that's what it sounds like, so it's all the customer and user experience pieces that you interact with at GitHub. Previous to that, I was at InVision, which is a design app, which I'm sure y'all are familiar with. And previous to that, I was at New Relic. I've had a long history. This is my 20th year in technology, and I've been working with a mix of distributed teams for the last 10 to 15 years, whether it be offices and satellite offices, or offices with remote, or at InVision, where we were 100% remote. There were no offices. And now at GitHub we have offices globally, but 90% of the engineering staff is remote and works from home. So, really versed in this area.

[00:01:03] Peter: Hi everyone. I'm Peter. I'm the CEO of teamwork.com. Teamwork is used by 22,000 companies all around the world to help them become efficient, organized and happy. And we make a range of five products. We call it the Teamwork business operating system. We make project management, help desk, CRM, knowledge base, and chat. So we compete with everyone, basically. We're self-funded to date. That may change because we have this huge vision we need to execute on, and we think we might need to accelerate and go even faster. I'm a recovering developer, trying to learn how to be a CEO and trying to crack the whip and go faster. And I've been doing the same job, I think, since we started out of college. We started as a consultancy and we pivoted it into product. So, since 1999. Never worked for anyone else.

[00:01:54] Shane: Peter, I'm very impressed you resisted the temptation to say that you're from Cork as well.

[00:01:59] Peter: I did.

[00:01:59] Shane: Okay. Just for your chance. Anybody who's not from Ireland, that's an in-joke.

Remote culture first at GitHub

[00:02:04] Shane: Dana, GitHub have this really nice tag on your jobs page that says, "We want to allow people to work where they're happiest." How long have you guys had that kind of ethos, and when did you introduce it?

[00:02:16] Dana: I've been at GitHub since January, so I'm fairly newish. I'm coming up to my 10th month. But the company has always embraced remote. We are a remote culture first. I always say global team, global product. And really, if you want to be the home of all developers, which is our mission statement that we truly believe in, advancing human technology by sharing and collaborating on design and technology, because it is what changes the world, it is by having people do their best in their best moments. And you'll find that having a remote culture, there are benefits as well as cons. But when you think about some of the opportunities that you have for underrepresented people, or people with other obligations, having the ability to have this remote culture really opens the doors and lowers the barrier of entry into building digital products. So we always started that way, because if you think about the nature of open source, it is distributed. You're already operating that way. If any of y'all work on open source projects, the workflow is an asynchronous, remote type of work. You have a maintainer, you open your pull request, you collaborate with anybody, any random person around the world, to build this awesome stuff. And then you have this workflow system, and we just mimic that. A lot of companies today call it inner sourcing, and there are many different versions of that. But we started that way. We're a remote culture first.

[00:03:37] Shane: Got it. And because you've always been culture first, have you guys ever, in a moment of weakness, toyed with the idea of getting everybody back to the one building? Or have you examined what the impact might be on either skills acquisition or retention?

[00:03:53] Dana: We give our people options. A lot of people get their energy off of interacting with other people in person, and so we don't want to stop that. When we say we want you to be your happiest, it's because when you're your happiest, you're going to be creative. When you're in a creative mindset, you're going to produce awesome customer features and value, not only for you but for the people around you. And so we don't put those types of constraints on it. We have options. So for instance, if somebody wants to work at one of our offices, we say go for it. We have an office in Tokyo, Amsterdam, Boulder, Colorado, and San Francisco. And if you want to work from home, we offer a home office stipulation so that you can be comfortable in your home office. We provide all of the technical gear that you need, and then a stipend so you can get the desk that you want, the chair that you want, the things that will make you comfortable. If you don't want to do that and you live in a city where we may not have an office, we offer a third option, which is co-working space. So we have a contract with a global co-working company that y'all have probably heard of.

[00:04:54] Shane: Would that be the W?

[00:04:55] Dana: Maybe. We like it a lot. I don't know about the press, but we offer the opportunity, because we have nomadic people that work at GitHub. Some people live in vans, which is my dream, to live in a van, very millennial style. And so we'll have people that take the opportunity to have that co-working pass, where they can globally go into any of those spaces and work and get that human energy.

Written culture and asynchronous work

[00:05:20] Shane: And does it make it difficult if you've got a portion of your workforce that's nomadic and you want to do some kind of agile meeting, and you don't know whether Mary or Joe is on route to the next beach?

[00:05:33] Dana: You have to really establish a written culture when you have a distributed team. You have to think about it. I like to think about the health care industry. When you think about nurses, you have a nurse that goes in, and then they come off shift and they have their orders and they say, "Here's what we've done." If you think about agile, and once again that open source type of workflow, you're going to be writing things down and passing stuff asynchronously. And so we try to bridge the gap by really giving tool sets that allow for those moments. We utilize Slack to do probably the majority of our communication. And we have Hubot, which has plugins that record daily stand-ups, that have night stand-ups. You can go and put what you're doing. We also embrace agile demos, where we have short two-to-three-minute demos that are produced every Friday. So you can sit back and see what all the distributed teams are doing. And it's pretty fun, because it also helps you understand what other things are going on, because people utilize different methods and mechanisms to take in information. And so we try to hit them all, because when you have a team that comes from every background and every culture, English is not always a first language.

[00:06:41] Dana: So really it's about being creative and always trying new things, because as you scale out your team, what worked with a smaller organization may not necessarily work as you continue to expand. Dunbar has a theory that after 150 people, you lose interpersonal connections. And my engineering team is well over that size at this point. So we find creative outlets to stay connected and be able to produce iterative software. But when you are building iterative, agile software, you're not striving for perfection. And so you want to give a lot of agency. When you're hiring engineers, treat them like adults. That's the best thing I say: treat them like adults. Bring them into the experience. And when we think about the design process, getting that engineer as a partner, that trio, that three-legged stool with their product counterpart and their design counterpart, they're going to have the agency to make autonomous decisions because they know and understand what they're building. And so it's really working on that whole paradigm of, you all own the problem space together. And so we make it work. Is it perfect? Absolutely not. Are there days where I'm like, oh, I just want to get everybody in the office? You better believe it. But we do get together regularly too.

Hubs, values and keeping culture consistent

[00:08:00] Shane: And Peter, you guys, even though you're growing very, very fast, have kind of a blended approach. So a mixture of adding new hubs in certain talent hotspots, but also allowing some of your team to work remote at the same time.

[00:08:12] Peter: Yeah, we do. We've 250 people right now, so we're much smaller at the moment, but next year we'll be scaling much faster. We've a really good employer brand in Cork, but the rate at which we were getting great people just wasn't fast enough to keep up with our ambition. So we talked a lot about remote work, and we certainly support remote work, and we've lots of remote people in the company. And I think you have to nowadays if you want to get great talent. You just have to support that and let them work wherever they want and let them work from home and all this. But in addition to that, we selected five locations around the world where we were going to build out hubs for Teamwork, because we've tried models of having 100% remote teams, and having 100% located in the same location teams, and everything in between. And what we have found in our experience works best is when 50% of the team is located in one place and creates a hub, and 50% of the team could be based anywhere. And sometimes people will go and spend two years traveling and will come back to the hub again. And you can work from any of our hubs. So we have Belfast, Barcelona, Buenos Aires, Boston and Amsterdam as our main hubs, and Cork of course.

[00:09:16] Shane: Okay. So you've got the first two letters of the alphabet licked. Then you've got to make your way through the rest.

[00:09:21] Peter: Absolutely.

[00:09:22] Shane: Is Zanzibar sometime around maybe 2030? And from chatting to folks over the past 24 hours, from the audience here, about this particular session, the one question everybody asks without fail is culture. If you have that blend between a number of people working from home and a number of people in the office, is it difficult? Do you have two different sets of constituents as a result? And how much effort needs to go into making sure there's a consistent culture?

[00:09:52] Peter: A lot of effort. I think as you scale, you reach different thresholds where you have challenges in the company. One of our challenges was remote people didn't feel like they were part of the company. So we've worked really hard over the last two years to completely change that, to make everybody in the company feel like they're a really important part of this. So it starts with the values: having your values codified, having your culture codified. Everyone in the company knows what we stand for and what we don't stand for. One of our values, for example, is don't be a dick, and you can call anyone in the company out for that. Another one of our values is never ever argue over chat of any sort, or any sort of text. And it's a firing offense actually, if you do it. If things are getting heated over chat, just pick up the phone, video call each other, and it'll sort things out instantly. So we've built that into our entire culture, and that really works.

[00:10:39] Peter: Other things we do: we live stream every single event. We invite everybody back to the main office once a year for what we call the Grand Council. We get every team to go off and do their own offsite, which they self-organize. We encourage people to just use budgets to get together. Some of our team might fly over to California, get together, have a shindig about where they're going with the product, and bring that back to us. And also we have a budget for conferences like this, to get the team together out of the office.

The tools that hold it together

[00:11:10] Shane: Got it. And I know, Dana, you mentioned a couple of tools that you use, like Slack. Okay, it's a lot of work to maintain that culture, but what tools have you guys found work best for facilitating that? Maybe Dana, start with you.

[00:11:23] Dana: Like I said, we just do so much with Slack and GitHub. Believe it or not, we do everything in repos. Like everything you can imagine. It's, oh, let's make an issue for that, we're going to make a pull request for that. Which as a developer is awesome. As somebody that's outside of the development cycle, they're like, "What? Y'all are crazy." But we use GitHub itself as a platform for communication. We use Slack and we use Zoom. One of the things that we do, in the same sense, to establish some of the boundaries and constraints of being able to not have that fear of missing out, because we do have offices and some people do go into the office, is that when we do remote calls, everybody dials in independently. So the conversation is on the same page, so that people feel that they're not missing out or missing that water cooler talk. And so we get creative with that.

[00:12:08] Dana: Other tools that we utilize: we use Figma for design, so we collaborate using that tool. Being an ex-InVisioner, that's a tough one, but it is what it is. And we're always looking at ways that we can find places to connect where we miss a gap, because like I said, everybody learns in different ways. So we have an internal tool that we built for ourselves called Team, where we do team posts, and anybody can go in there and write about what they're working on. And it's almost like an RSS feed of what's going on in the company, from what people's dogs are wearing, because that's a really important thing to know, the dog outfits. I like it a lot. And then we have Slack channels for everything. But I think it's about not just doing one thing. You have to hit all angles. All of our all-hands are streamed. Doing those asynchronous videos. The tool set really is your typical tool set. We use GitHub, we use Slack, we use Zoom. Those are the three core things to us. And then we build bots to do everything else.

[00:13:10] Shane: Got it. Peter, similarly, you use Team, you should use Teamwork.

[00:13:15] Peter: We use our own products, of course, to try and run everything. We have a product, our own Slack, called Teamwork Chat. Completely free, by the way, and it's better. But in that, it's kind of how you use it. We have a wins room and we have a fails room. The wins room is obvious, everyone in the company celebrates the small wins. But the fails room is equally important to building that culture. We challenge everyone in the company to post something in the fails room in your first year of working at Teamwork. In addition to that, we have an internal blog, and every department in the entire company has to share a blog post, which are just written by different people every month, and it kind of gives the inside scoop on what's going on.

[00:13:48] Peter: And one of the most important things we do is we use an anonymous feedback survey tool, which surveys the entire company every single month. So we can see how we're performing across multiple categories. But the important thing is we can have an anonymous two-way conversation with every employee. And back to the culture: every single employee in the company, when they start, we sit down and we have coffee with the founders with them. We take 10 employees at a time and we have a coffee with myself and co-founder Dan, and we go through the values with them. And we say to them, "At some point it's inevitable that the company or your manager or a process or some change is going to upset you. And our ask, and we repeatedly make this ask, is that you never ever let things fester." And it works.

Agile across time zones and minimal viable bureaucracy

[00:14:30] Shane: The second most common question people asked when I spoke about this session was, how do you do agile with remote teams? And particularly, we've got massive time zone coverage. So Dana, I know you've pretty much got full 24-hour time zone coverage. How do you guys manage the agile development process?

[00:14:49] Dana: We put in, I don't want to say them laws, but it's really about constraints, and it's about being able to build repeatable systems at scale. And then also being smart about how you staff. So if we have a particular engineering team, we don't want to go too many time zones different, believe it or not. So we have global teams that are everywhere, but you want to try to bridge the gap and have some constraints there. Now, is it always perfect? No. We still have some people that are further outside of that, especially when they're traveling, but we put that on them, because we don't want people to work really odd hours either.

[00:15:23] Dana: People have natural circadian rhythms, and I do think development is an art and about being your creative best. So for instance, we try to say, okay, if the core of the team is in, let's say, New York City, then three time zones to the left, you don't want to have people over there, or three time zones to the right beyond that, because it just makes it a little bit more difficult. But it does happen, and I come back to having that open source philosophy about how we work, and then putting a lot of the autonomy on the individual teams. We stack our teams in a way that I like to call mini startups. So you build, own and operate, and so you're the ruler of your domain. And so we have the engineering leader, that product leader and that designer all working in tandem to make decisions, and the engineers have a seat at that table. And when you're doing iterative work, you don't strive for perfection.

[00:16:09] Dana: In addition to that, really, really, really heavily invest in your tool set. It is equally as valuable to have a tool set support your product development to be successful. So having those repeatable things that people do, and having them have the ability to self-serve. So having self-serving provisioning pipelines, being able to go and not have to call somebody on the infrastructure team if you need something. Giving people the autonomy and the right tools to be able to operate independently is key to being able to successfully have an agile distributed team, at least for us at GitHub.

[00:16:45] Peter: Yeah, I'd echo that, but it is a challenge. We allow every team to be autonomous, and you have to for the remote distribution to work. But we have a concept at Teamwork called minimal viable bureaucracy. We are very afraid of turning our company into this just slow-moving bureaucracy as we scale. So we kind of rally against it. We're like, okay, we definitely need to put in some process here, but what's the minimum set we need to introduce? So we insist, for example, that you have to have daily stand-ups. But when you do your daily stand-ups is completely up to your team, and you're welcome to try different things and move them around. So for example, we have one team that do their stand-ups at 5:00 p.m. to cater for one of their guys who's based in California. We have another guy in California, he gets up at 6:00 every morning, he chooses to do this, so that he can be connected with his team in Ireland. I actually really like your time zone thing, so maybe that's something we should be looking at at Teamwork.

[00:17:30] Dana: Yeah, but to your point, you have to separate the foundational pieces of your culture, which are somewhat sacred, and then your situational ones. So if a foundational piece is we have daily stand-ups, cool, everybody does that and you have those constraints there. But the situational aspect of it is you have them at the time that the team indicates is good for them. And so having those kinds of bylaws, like you said, like I like that minimum viable, helps people have a sense of agency and self-form and organize. Because productivity in today's market, no matter what industry you're in, you have a competitor. The barrier of entry to building a digital product has been so much lowered, and you see it in every industry, that there are 15, 20, 100, how many ever startups out there. So thinking about how you can retain high quality with repeatability, in a fast way where your developers are the most productive, that's your key.

Overwork, the four-burner stove and time off

[00:18:28] Shane: I'll go back maybe to a point that you mentioned about people working crazy hours. We had a similar panel session last year, and I suppose it's indicative as to how much the thinking on remote working has evolved, because back then a lot of the questions were debunking some of the myths around productivity and remote working. And one of the speakers, who was from Nearform, said that actually his experience was kind of slightly counterintuitive, in that his challenge was stopping people working crazy hours. Have you guys found that, and how do you intervene in those situations?

[00:19:04] Dana: I think there's this myth that if you allow, especially if you're going from a traditional butts-in-seats culture where it's like, I'm the boss, I have to physically see you to make sure that you're productive, there's this kind of bias that people are going to be at home left to their own devices and going to play video games and maybe daydream.

[00:19:25] Peter: There are a few people that do that.

[00:19:28] Dana: The reality of it is, you put people in their comfort zone, they're actually going to have, at least me personally, because I enjoy what I do, that issue with disconnecting, and saying, oh my gosh, I've just spent 16 hours chugging away, because you get in the zone, you get in that flow. And so you really have to encourage people to take breaks, and find healthy means. And really there's an insecurity that comes from working remote, because you know that that stigma exists, that people think that you're just effing off. And people end up burning themselves out.

[00:20:00] Dana: And so there's this concept called the four-burner stove. Have you heard of this concept? The concept that I like to think about when you have a remote team is that you do not have an endless supply of gas. You're a human, you do not have an endless supply of gas, and you are the ruler of your destiny. And so if you're a stove and you have one burner that is your socialization, your family, your work, your health, your exercise, you cannot have all four of those burners going on at full blast. You will burn yourself out. It will happen. And so really what you have to enable as a part of the culture is for people to be adults. Most people need a job. The world runs on money. It's amazing that if you treat people like adults and give them commitments and have them own it, they will do it. But also encouraging them to turn those burners on and off at their own leisure.

[00:20:48] Dana: So for instance, I hate going to the grocery store right at 5:00 p.m. when everybody's getting off work. I just hate it. I'm just like, I'm going to Instacart this, because I don't even want to go. But for me, for my personal burners, I'll go to the grocery store in the middle of the afternoon with all the old people, because I'm like, shoot, yeah, I can mill around and not feel pressured and like I have to get in there. And I think it's about having that autonomy of turning on those burners as you need to, but being very mindful that you can't be blasting them at all times.

[00:21:22] Dana: And when you have a team working from home, there just is that imposter syndrome, that people are going to think you're not pulling your weight, but you see the opposite of it. And so it's about checking in frequently and reading that body language, saying, "You look tired today. How many hours are you pulling? What are you working on? Take a break." And encouraging it. We have unlimited PTO, which is also another scary thing. PTO, time off. People say, oh, it's a curse, and it's also not. But we have it because we find with remote work, people actually are pulling more hours than typically people in office, just because of that insecurity. So you have to really encourage the culture to say, take a break. Because you want the best of people.

Spotting underperformance

[00:22:06] Shane: Got it. And Peter, the flip side. Remote working is great, but it's not the panacea. It doesn't protect us from disengaged team members and stuff like that. Is it more difficult to identify underperformance in remote teams, and when you do identify it, is it more difficult to make an intervention?

[00:22:26] Peter: It's the same really. At the end of the day, we try and organize the company into autonomous teams, where you have a manager or leader who's managing no more than 10 people, ideally seven, and he or she still has to do the performance reviews and check-ins. And we insist on one-to-ones every two weeks. And much of that, honestly, is the same. But back to the previous point, we definitely have people in the company that overwork, and we're constantly telling them to please go take a holiday, or your spouse is going to come in and batter us. But I don't actually believe in the unlimited vacation thing, because I think it...

[00:23:02] Shane: People won't take it.

[00:23:03] Peter: As long as you get them to take it, that's great. But we actually just give six weeks holidays, which is pretty generous, and then you get the extra statutory ones on top, and we just really encourage you to use it.

[00:23:13] Dana: Yeah, the US isn't as good about taking holidays as Europe. It's like, you get four days off a year, go. So we're trying to bridge that. But as far as performance, you can tell when somebody's being productive. I'm not going to go count commits. I'm sure people will be like, "Oh, look at that commit graph." I'm like, no, I'm not going to do that, especially when a lot of stuff is in private repos.

[00:23:37] Peter: Something like graphic design: somebody could spend 10 hours on a design and they could hate it and throw it away, and then in one hour, when they're in the zone, produce something amazing. It's very hard for you to gauge that.

[00:23:46] Dana: It's just about owning commitments. Putting real resourced and thought-through commitments in place. I don't care how long it takes you. Just do your job. If you're crushing it and you can do it quicker and do it with quality, good on you. If it's your ambition to advance your career by doing more, go for it. But for me it's just, if you've committed to doing something, you ship it. And you have a way of seeing out performance. It makes no difference, in office or at home, as long as people really own their commitments.

[00:23:58] Peter: Yeah, we're trying to build a culture as well where you do that, since it's a duty to the rest of your team, and it's in our values that we want to be a high performance company. And we will get feedback where people see that team members are not pulling their weight or are slipping or whatever, and we will dig in with that. But we've a pretty good culture overall.

Payroll, compliance and hiring globally

[00:24:35] Shane: Cool. Maybe one last question before we throw it open to the floor. Again, when we ran this session last year, folks came up afterwards to say, "What I really wished you'd asked is what are all the hacks and tips and tricks for keeping the lights on and doing payroll and managing compliance when you've got a distributed team? That's what I'd really love to know."

[00:24:57] Peter: So I've two big ones that I love to share, because we struggled with this. We were doing pay across multiple countries and dealing with government and rules changing and all this. And we finally found payslip.com, who kind of take care of all the bureaucracy and just make it a lot easier. And the second tip I have is that if you have multiple people employed in the States as a European entity, you have to register a legal entity in every one of those states, and it's just incredibly burdensome. You have to provide benefits and all this. And last year we stumbled, I think another founder told me about it, there's a company Justworks who kind of do co-employment and take care of all the benefits and all the compliance. And it's fantastic. Check them out.

[00:25:39] Shane: Cool. And maybe a penultimate question, or last question even: as you hire teams globally, do you find that there's an opportunity for maybe immigration or hiring arbitrage, that there are certain parts of the world where, even though you might like to hire folks there, it's just too difficult?

[00:25:59] Dana: I mean, yeah. The global laws are changing all the time, and there may be ambitions, but that's when you work with the individual. Maybe you do visa sponsorships, find ways where they can work in countries that fulfill it. Especially if they're bullish about joining your team, you have to get creative with creative solutions, and still have those bylaws. And that's why you open little entities and have that flexibility there. But it's a moving target, and it's something that you just have to be mindful of. And sometimes it just doesn't work. You just have to say, well, it doesn't work, and then you put that on the person, and then you help to accommodate if it's really somebody that you want on your team. You find ways to make it work, and within a legal way.

[00:26:44] Shane: Of course. Yeah, we're not recommending anything illegal on the stage. Or in the sidebar discussions off the stage.

[00:26:51] Dana: Definitely.

[00:26:53] Shane: Any of the same for you guys?

[00:26:54] Peter: I'd agree with that. You'll find a way to make it work, but there are definitely countries that have fairly severe, hard to work with laws that we'd just rather avoid at our size. We just can't deal with the administrative burden. But there's always an alternative.

[00:27:08] Shane: There's always a way around.