Transcript
Shoup: I'm Randy Shoup. I'm a VP of engineering at WeWork. I want to talk to you today about high-performing remote and distributed teams. I've worked at a bunch of companies that have had some flavor of remote or distributed workforce. At Stitch Fix where I used to work, we had a mostly remote engineering team. At Google, we had sites all over the world, and also at eBay, we had a primary site in California, and then some sort of satellite sites. I've learned lots of different ways of doing these things. The TLDR is that there is more than one way to do it, but there are lots of ways to screw it up. Hopefully, we're going to try to figure out ways of learning from doing the good things, and not so much the bad things. WeWork, where I work, has a pretty distributed technology team. We're based here in New York City, so still the majority of engineering is done right here in New York, but through acquisition and also just general growth, we have teams in Tel Aviv, in San Francisco, in Seattle, in Montreal as of this week; lots of different places around the world. We definitely have this problem today.
What is remote? I have a former colleague from Stitch Fix who gave a wonderful talk here called the Effective Remote Developer two years ago, his name is Dave Copeland. Fantastic developer, and also a remote one. His definition, which I think is wonderful and I'm going to just straight away steal. Remote means you do not often interact face to face with the people who you work with. By that kind of definition, whether we call it remote, or distributed, or something like that, how many people in the room are in some kind of remote situation? Almost every hand went up. Great. Martin Fowler, who I can't help quoting because he's so brilliant: "Organizations that are able that make remote working patterns effective are going to have a significant and growing competitive advantage." Let's talk about why that's true.
First, let's recognize that there really is a spectrum of remoteness. It's pretty obvious on one side; you could have a single site where all your development team works in one particular location. It's pretty common for companies to be in this multisite situation. It's also increasingly possible to have teams that are fully remote, where nobody actually works in the same office as anybody else. Just an example to give you existence proofs for all of these different ways of working, Netflix and early to mid-eBay were definitely in the single site model. They were able to get a lot done. Actually, this bugged me because I just learned last night from Dave Hahn that Netflix no longer has this model, but I didn't update the slide.
In terms of multiple sites, WeWork as I just showed you, is a great example. Google also famously has sites in about 100 different places around the world. Remote-first - who uses open source software? All the hands went up. If there's anybody who's a skeptic, probably not in this room, but other people who you work with, who thinks, "There's no way we can build remote software," almost every piece of open source software is built in some flavor of remote, typically remote-first. As I mentioned, Stitch Fix is a commercial company that had a mostly remote engineering team, Basecamp, DHH is famous for tweeting and writing books about how one can make remote work effective, and then I just can’t not mention C4Media, which is the organization behind InfoQ and behind the QCon conferences; they are also in this remote-first situation.
There are a couple of anti-patterns, which we're going to learn about as we go forward. The first one, which I'll talk a little bit about is for example later eBay, where most of the stuff and all of the decisions are done in one central headquarters, and then the people who are remote from that headquarters get work doled out to them. There's a locus of control that's in one central place, but there's a little bit of work done outside of it. Then another thing that's a little bit problematic is where you have one or several sites where people work every day. Then you have a small number of people that are the exceptions, and are remote from this. We're going to talk about why these are anti-patterns as you go along, but these are very clearly not part of the models that I think work well.
Hiring and Onboarding
I have five different sections that I want to talk about. The first is about hiring and onboarding. Why do we even want to do remote or distributed work at all? It's because not everybody lives in New York, or in San Francisco, or in London, or in Berlin. Talent is evenly distributed, but opportunity is not. By leveraging the ability to have multiple sites around the world, or remote-first work, you can take advantage of that talent that does not live in one of these metro centers. There's a wonderful set of benefits that we get as a company and as a team from that. The first and obvious one is that we can now hire across different geographies. We can draw from the talent pool, maybe across the nation or across the entire world, you can play a different supply and demand, because if I were going to do something in FinTech, New York or London would be a great place to do it. If I want to do something in maybe consumer software, maybe San Francisco, cloud stuff, Seattle, so you can take advantage of the supply and the demand for talent in the different localities.
You can also - and this is I think underappreciated - hire in parallel. With a distributed system, we can grow each of those teams in parallel with each other and you're not bottlenecked on any other aspect, for example the recruiting process, or how big your recruiting or hiring team is going to be. We can actually grow. We've seen this at WeWork, where we've doubled over the last year, we’ve more than doubled our engineering team. It's now 1,000 people globally, because we've been able to hire in parallel in San Francisco, in Seattle, in New York, in Tel Aviv, in Shanghai, etc.
Then also, there's a little bit of a geographic hedge you can take advantage of. If, for whatever reason, hiring does slow down or has to slow down in one particular geography, you can hire more in the other ones. Another thing that I think is underappreciated is the effect that this can have on diversity and inclusion in your company, particularly when you can make available remote-first work. There are lots of people who otherwise would not be able to either move to your main line location, or work a solid nine to five hours. They can find eight hours in the day to work, but they won't all be in a row. You can obviously think of people who are primary caregivers for children or for elderly people. That makes a huge advantage that we saw at Stitch Fix in terms of being able to attract and retain a far more diverse workforce.
You definitely get the advantage of geographic and cultural diversity, because people are from around the world, or at least around the country. Also, I think, even under appreciated if you appreciate this point, is the ability of neurodiverse individuals to be able to work productively. People that are on the spectrum can often have anxiety issues with dealing with large groups of people and interacting one-to-one. A model where there can be a remote-first workforce where there's very structured communication, not zero communication, but structured communication with other people, can be a really effective way of giving people opportunities that are more neurodiverse. Again, we had that situation at Stitch Fix very directly.
The other thing is about retention. If I can hire somebody who is not in one of these high-demand, very competitive situations, it's not only easier to hire them, but it's actually easier to retain them. You absolutely have the advantage of employee satisfaction when people can live and work in the place that they grew up in. There are some definite productivity benefits for being able to be remote. There are also challenges though, of course. It can be challenging to hire in different places around the world. We've definitely seen that there are different ways that one would recruit, say, in New York, versus in San Francisco, versus in Tel Aviv. Also, you have to be really conversant in the local labor laws. In the U.S., it's mostly hire and fire at will, but that is not true for most of the planet. Being able to recognize people's notice period from leaving their previous job, as Pat Kua said earlier in this track, what situations you might need to put into place in order to let somebody go, what are their expectations around severance? All those things you really need to know before you dive into this stuff.
The other thing is about local compensation. If you remember nothing else about this point, you need to have a disciplined and principled philosophy of how you pay people. There are a couple of models that are principled, like pay everybody as if they were in San Francisco, that's a principled model, or pay everybody whatever the local market would do. You have to have one principled thing, because if you don't, it's going to be a mess. You definitely can't treat one class or one geo with one compensation philosophy, and another geo with a different compensation philosophy. Then also, very different norms actually about what benefits people expect, etc, and also depending on where you site in the world, you actually have to be aware of currency fluctuations in the country. That's the other aspect of the principle of compensation. Are you pegging people's compensation to the dollar? Or is it denominated in the local currency? If you're in one of those particularly developing countries where there are massive currency fluctuations, this actually matters a lot.
The other aspect is local regulation. The particular experience that I noticed - obviously, there are lots of different regulations around the world - actually was at Stitch Fix, where every time we found a new remote developer in say, in Iowa, or in Kentucky, or in Florida, that would actually expand what's called the taxation nexus for the company. We would actually start as a company to have to pay state sales tax in that state. We have to think financially about, "Does it make sense to hire this one person in Iowa, if we now have to pay sales tax?" We actually always ended up hiring those people, but we had to have those principle conversations.
Let's talk about onboarding those people. It's definitely possible to onboard people remotely - we've definitely done it - but I have found that it is hugely beneficial to onboard people all together. Bring a bunch of people to one of your local sites, or to your headquarters; that has the nice property of people bonding with their cohort of people who all join together and is a nice benefit of instilling the company and team culture into the people as well.
It's particularly important when you have remote or distributed teams to have some kind of structured mentor or buddy system for onboarding. One of the nice best practices that I've seen practiced at a bunch of companies is you have two mentors. One mentor who’s about their particular job - if I'm going to be an engineering manager, somebody else was my mentor who's an engineering manager or something like that, but also somebody who maybe is earlier at the company, even if they're not in the same role, but that can be a culture or organizational mentor. That's the person that you can go to ask, "How do the expense reports work?" and that sort of stuff. Those two different things are two different mentoring jobs. Having them be filled by two different people is great. Also, it gives particularly remote employees who might feel isolated double the amount of connection with other people straight away.
The other thing is - this is true, no matter whether it's remote or not, but particularly important when it's remote - is a very structured onboarding program that people can do at their own pace. Obvious things that I've done at a bunch of places is, whenever somebody does a deep dive about some particular technology, or some particular system, we record it, and then we put that someplace on our wiki, or the internet, and those deep drives and recorded introductions become a grassroots assembled onboarding program. Then something that one of the other teams at WeWork is working on actively right now here in New York is what we call WeWork Developer University, which is a structured onboarding program, which is going to have a mixture of classroom-related stuff, or they're in person, but also recorded stuff.
Employee Productivity & Health
That is the hiring and onboarding part. Now, let's talk a little bit about everything from the employee perspective. Let's talk about employee productivity and employee health, because I think that second part is really important. Particularly if you're working from home, but really anywhere, you need a productive workspace. It's pretty important that, as a baseline, either you or your company provides video, audio, internet connectivity. For a number of people who used to work for me in remote-first situations, we would expense a My-Fi, which is when you have really terrible rural wired internet, there are ways to get internet. That expense was well worth it. There's just no way people are going to be able to do work without good internet connectivity.
The other thing is around the physical space. If you're expecting people not to work from a formal office that you maintain, it's still the company's job to make sure that they have a comfortable chair, a standing desk if that's how they like to work, whether they're setup in a home office or something like that. This will be my last pitch - coworking spaces, like the place that I work for, is a great opportunity for people to take advantage of. Lots of times I found that people who worked for me in these remote-first situations, particularly, by the way, if they were young parents, they like to sometimes be able to work at home, but sometimes also not work at home, and have a separate thing. Not everybody is able to have a home office and not everybody's able to have a soundproofed and childproofed - if you know what I mean - home office. I'm a parent of a 12-year-old, so he's totally fine now, but when he was younger and I would work from home, it's a difficult conversation to have with a young child to say, "Yes, daddy is here, but daddy needs to work." That's a trick. Giving people the option of working from a coffee shop, or a coworking space, or something like that, can be a real advantage.
Who has heard of this idea, Maker's Schedule, Manager's Schedule? Not enough hands. I'm going to tell you what it means. The reference is from a 2003 blog post by Paul Graham of Y Combinator called Maker's Schedule, Manager's Schedule. This is about the two different kinds of work that we have in our industry. There are the makers. You don't always get this, I know, but if you are a maker, meaning you actually produce real work for a living, whether it's writing, or code, you'd like to have a schedule that would look like this. You'd like to have a very small number of meetings, they're co-located either at the beginning of the day, the middle of the day, or the end of the day, so you have multiple hours of flow time. As we know, the engineers in the room - and believe me, I used to be one, but even though I'm now pointy-haired boss - you need that flow time to be able to get anything done; whereas, this is what the manager schedule looks like.
You should read this wonderful blog post. This is just a fact of life, you can't wish this away. For the manager who is over on the right-hand side, pointy-haired bosses like myself, you need to make sure that you don't pollute the maker time. For me, it doesn't matter whether I have my one-on-one with Tom at 8:30 in the morning, or 11:30, or 2:30, but it matters a lot to Tom who is actually a maker. Trying to be sensitive to scheduling is really important. If you don't do this, particularly in a remote environment, you really can disrupt people's workflow and remove all the productivity advantages that I'm about to talk about, being in flow. If you don't believe me, then I strongly recommend that you go get this book called "Making Work Visible," by Dominica DeGrandis. It's all about time management. She uses a lot of the lean manufacturing methodologies and approaches to thinking about how to do time management, not just personally, but also as a team. It's really well worth it.
What you want to do to, really get the advantage of people being able to be remote and distributed, is you want to make sure that they have that flow time. Respect that maker's schedule, manager's schedule distinction, and also help and encourage the remote employees to develop their own productive routine about when they go in flow, maybe they do Do Not Disturb on Slack, or whatever, and then they come back out of it. Like that, as a manager, you want to make sure that people are able to be productive. Then the other the related notion, not just as a manager, but also as an employee, is encouraging the setting of boundaries. As I mentioned, trying to do meetings either at the beginning of people's work day, in the middle of their workday, at the end of the workday, not in the middle of flow time; if you want to have open conversations that are unscheduled, setting up office hours can be a good way of doing that. Leveraging Do Not Disturb to be very clear about, "Yes, I'm working, but I'm in flow right now." Then encouraging people and as a manager, consciously managing those interrupts.
There are some great advantages, productivity-wise, as you can imagine. As a remote or distributed employee, I have some geographic flexibility. Maybe in a multisite environment, like at WeWork or at Google, I could choose the location that I work in, I might be able to reduce my commuting burden. If it's remote, I might be able reduced that commuting to zero, that would be nice. Also, I can maintain some proximity to my family, both local and extended. The other benefit here, of course, is around work-life balance. I can maybe integrate my home life and my work-life better together. When I'm working remotely, in my own personal life I go at 3 p.m. and go pick my son up from school. I live in San Francisco, so 3 p.m. for me is 6 p.m. here, so the end of the New York work day. It's actually not disruptive and wonderfully advantageous for me to be working for a mostly New York-based company, taking advantage of caregiving and time flexibility. Then also, again, trying to make sure that we can maximize our flow time and have a have a good personalized work environment.
These are the benefits: geographic flexibility, work-life balance and productivity. By the way, these benefits also apply to headquarters employees. If you are as in Stitch Fix headquartered in San Francisco, but mostly have a remote engineering workforce, I was able in San Francisco, even though I came to work in the office most of the time, I could work from home, and it wasn't really disruptive, because I'm chatting with people over Slack, and over video. It has benefits even for people who aren't remote. The challenges are, geographic flexibility, work-life balance, and productivity. Let's go back and do those "one step at a time."
Geographic flexibility. I get to live not in San Francisco, or not in New York, that's great. But the expectation, which we'll talk about later, is that, in order for the team to be productive and sustainable, we are going to have to have people regularly travel back and forth and see each other personally. If it's all the time, then we're not doing it right, but if it's never, we're also not doing it right. We're going to talk later about thinking about getting everybody together in terms of summits, and retreats, and something like that. Also - I learned this from Charles [Humble] at InfoQ, he gave a wonderful talk on these similar ideas - no commute means no exercise. That is the thing that, as a remote employee, you think about; make sure you make time in your day to take a walk, or take a run, or something where you get yourself out of the office and into some other environment.
From a work-life balance perspective, being able to integrate home and work together is a wonderful advantage, but it's also a real potential disadvantage, because some people - and I've had this experience myself - want to keep working and other people are working, so you need to keep doing it. It can be a challenge to make sure you set proper boundaries between home and work. Time management is a really important aspect there. The other thing, particularly if you're in a remote first situation, is that you really need to watch yourself for effects of not having a lot of human contact. Solitude and isolation can be a real challenge if you're working from home and not interacting with other people who don't live in your house with you. Coffee shops and coworking spaces, and just other ways that we'll talk about later, can be good for mitigating for that.
Then the other thing is you really do need to make sure that given all these things, you're taking good care of your mental health and your social connections. From a productivity perspective, mostly it's great to be able to stay in flow time. Sometimes, there are lots of people, not everybody, who get energized by being in a work environment where other things are happening. When you're in a work environment that's very static, for some people, that's actually a productivity reduction.
I want to talk a little bit about how one might manage remote teams and be a manager. The first thing that I would say is, it's really great if the managers themselves are remote, because then she would develop empathy for the people who work for her. She also demonstrates that there are career advancement possibilities. It's not just the worker bees being remote, but the fancy managers back at HQ or something like that, and setting an example for, not just as a management example, but also how to do the time management stuff that I mentioned.
It's particularly important in one of these distributed and remote situations to have a lot of structure around how one communicates. It's particularly important to have very crisp clarity around goals, around expected outcomes, around what's a high-priority, and what tasks need to be done. You need to make sure that most of the communication is done written, or at least reinforced written. Then also making sure that people do a good job with time management and be accountable to their work. Management behaviors that are particularly important in this remote environment are maintaining a steady cadence of one-on-ones. If my team's watching this, I'm not always great at this, but I'm going to get better. One-on-ones need to be sacrosanct. It's not just important to do one-on-ones with your direct people that you directly manage, but also, if you manage managers, doing regular skip levels with the other people who you don't get to see regularly.
Why are we doing this? It's because you don't get to have the advantage of management by walking around. You do not get the advantage of implicitly gleaning what people are struggling with, how hard they're working, etc. I should do better at this myself, but one-on-ones should be less of a status meeting and more of a check in to make sure that as a manager, I'm doing the best that I can do to make my employee productive. The other thing that I can't emphasize enough is doing the praising and correcting in the right way. It is extremely important always, but most important in this remote situation, that as a manager you praise in public. That could be on Slack, that could be in a meeting, but praise in public. Overpraise, because otherwise people aren't getting feedback. But when there are corrective things that you need to do, do those corrections in private.
Leveraging Remoteness
Let's leverage this remoteness. Remoteness can be a challenge, but it can also be a huge advantage. One of the ways to leverage remoteness is to make sure that those remote teams are all full stack, and fully autonomous, and fully self-sufficient. Regardless of remote or not remote, I think this is a good thing to do in organizations. I've talked about this for years, and I still strongly believe it, but it's particularly important in a remote situation because you need to make sure that in our example, the people in the Tel Aviv team have the full autonomy to get their job done without having to constantly check back with New York, or San Francisco, or Shanghai. It's even more important, because the communication costs are so high, that the individual teams are self-sufficient and able to make forward progress. That has lots of implications. That means they need to have a clear set of goals, they need to be full stack, so they don't need to rely day-to-day on other people's work, and that they co-locate the product, the design, all that engineering, all that stuff together.
The other thing that's super important is goal alignment to the business. We want to form these teams, not like, "Let's have the remote team that is the DBAs," but a remote team that is aligned around a particular business problem with clear goals and metrics that actually matter to our customers; that they have a well-defined area of responsibility, both in terms of the business domain, but also in terms of the services and applications that they support. This is, I think, true of all modern organizations, but it's more true even in a remote situation.
Let's leverage those remote teams. The first thing I would say is, on a team by team basis, let's make it all local. A team should either be, for example, all in Tel Aviv, or all in San Francisco, or it should be a remote-first team where everybody is remote from each other. I say this team by team. It's perfectly ok and common to construct a larger organization, or a larger product area, or group, however you want to say it, out of individual teams that are maybe not collocated. A strong recommendation that I have reinforced over and over again in my experience is a team should be collocated in a physical space to take advantage of that, or everybody on the team behaves as if they're remote, even if they happen to be in the same place. The anti-pattern or the ones that don't match this are mostly people are in the same site, except for Randy who's remote. That never works. It works for a little while if you already know you could trust Randy, but over time, the isolation and the separation is very difficult.
When you have humans all together, we are social animals, and so it's going to be very difficult to avoid having the local quick architecture conversation and design conversation, and then informing Randy later, or maybe even forgetting to inform Randy later. We've all had that experience, that doesn't work. That's why I strongly say that at the team granularity, squad, whatever you want to say, it should be all in single site or remote-first. The other thing that is hugely important is work distribution. I want to reemphasize that if you have a situation where headquarters is handing out tasks and you're using the remote teams as a job shop, that is never going to work. That's classic outsourcing. If you read the "Accelerate" book in the state of DevOps report, that is highly correlated with terrible organizational and engineering performance.
I mention this all the time - this is actually how eBay first approached you doing offshore work. eBay was headquartered, still is, in San Jose, California, so basically a single site. eBay opened up in about 2006 a development center in Shanghai; amazingly strong engineers from all over China, top universities, incredibly go-getter, really good engineers, but the way that eBay used them was they never gave them really anything to own, but doled out task by task. That was very frustrating for the Shanghai team, who kept saying, first a polite way, then still polite, but more strident, "Please give us something to own." There was this terrible vicious cycle of, "They've never owned anything, so we can't give them anything to own."
The really sad end to this story is the team grew to about 500 people. We had some new leadership come in in the part of the organization that I work with, who looked at the situation and said, "Those are great engineers. We clearly are not using them well. We should just let them all go." We gave them a good severance and everything, they weren’t out on the street in one day. The sad truth was that they were so mismanaged from the HQ that we shut that site down with no impact to productivity at all. Five hundred of the top engineers in Greater China, because they were not being used effectively, were basically providing net zero value, which was awful for them and awful for eBay.
The other thing I want to talk about are some ways you can really get benefits from teams being remote. One is the obvious follow-the-sun idea where when you're working on some issue, for example, you can have round-the-clock triage, you can continue to make progress. When I'm asleep, maybe the Sydney team is making forward progress. Then particularly if you have operational responsibilities as I hope you do, on-call handoffs when the hours overlap. The other thing, which I think is may be less appreciated, which we absolutely do at WeWork is, we have buildings all over the planet and we have those development centers all over the planet, and we take advantage of that. The Tel Aviv team works very closely with the coworking buildings that we have in Tel Aviv, and actually builds on a very tight feedback loop tools that those community managers locally use.
Similarly, the team that I have in Singapore has built a bunch of local implementations of payment methods that are really common in Southeast Asia, like GrabPay and a bunch of local payment methods that are otherwise not widely used around the world. It was something that they saw an opportunity in the local environment to be able to make forward progress on. The other obvious thing is just having empathy for customers around the world where you do your business.
The last thing I want to say here is, you can use individual sites and natural experiments. The Tel Aviv team at WeWork has done some great work on a really structured hiring and interviewing and onboarding process, which we're now actually replicating and copying in the rest of the world. The Singapore team that I mentioned has made some great strides in terms of maturing engineering practices, which we’re stealing and borrowing in the rest of the world, experimenting with new tools and frameworks, that sort of thing.
The downside, of course, is managing the different time zones. The most important idea that you can give as a manager is to make sure that people respect other people's time zones. That seems like a really simple thing to say, but just recognizing when, "You know what? 9 a.m. in New York is not a great time to invite Randy to a meeting because it's 6 a.m." It turns out that I do that all the time, but that's all right. Then even when you have the nine hours difference, say from San Francisco to Shanghai, be really respectful of that, the 10 hours difference that I have in San Francisco to Tel Aviv, really thinking carefully about respecting other people's time zones and their work hours, but also, when we have an overlap, really exploiting that overlap a lot. Then the other thing is just respecting people's calendars as well. If somebody says, "I'm not available," I respect that. Not every organization does that. It's really critical to being able to make this stuff work well.
Communication
The last section I want to talk about is communication. One of the other great things that Dave mentioned in his talk about being an effective developer is this idea of trust. The half-life of trust, according to Steve McConnell of Code Complete, is six weeks. It means that I have some level of trust with you right now. If we haven't had a significant interaction in the next six weeks, maybe my trust has gone to 50% and then 25%. This is just how humans work. This is just how we all are. It's very important that we use a bunch of critical tools to make this stuff work. These are some of the tools that we use at WeWork. We make heavy use of Zoom. Every meeting essentially has a video link. We make heavy use of Slack. Every team, every project, even every outage has its own Slack channel. We use a ton of Google Docs where we collaborate, GitHub for our code, Jira for managing our projects. There are substitutions for all of these, of course, but these are critical. You have to have some videos, some chat, some collaborative docs, etc.
The written communication and in-person communication really have very different characteristics. I want to talk about what's the best way to take advantage of these in a remote situation. I want to first talk about written communication. If you remember nothing else about written communication from this talk, I'd ask you to remember these seven words. It is saying in your doc or in your pull request, what problem you're trying to solve. That is the context that you need to set that maybe if you were in person, you wouldn't have to share, but because you are remote from the person, you have to be very explicit about, "I am doing this PR for this reason, and here's the solution that I'm proposing." Being very clear about why we're having this doc, why we're having this meeting, why we're doing this pull request, a very clear structure to the document that you put together, whether it's a design document or something like that, try not to use super fancy language, particularly if you're dealing, as I often do, with people that who aren't native speakers of English. Then also, being careful about being too clever, because a lot of phrases can be very easily misinterpreted.
I can't say enough that you need to, particularly as a manager, over communicate, because you don't have that constant reinforcement of seeing people in person. Then also, one of the reasons why we write something up is to get feedback, so for a design document or something like that. One of the things that can be very difficult for some cultures, and I feel this myself, is that sometimes when you might feel like if you ask a question, you're showing that you don't know something, and then you're showing that you're not good at your job. There are definitely cultures were asking a question is a first order admission of weakness. You’ve got to make that not a thing in your work culture. A culture of, "I don't know how this stuff works," and ask that in public. A great way to do that as a manager or a senior person is actually model that. Show the vulnerability. "You know what? I actually don't know the answer to this question. Does somebody know?" Then also model the "When in doubt, ask." Try not to assume stuff, but just ask if you're not clear on something.
The flip side is, as a writer of a document, be very open to other people's feedback, and assume that they're doing it to help you. Most of the time, maybe all the time, somebody is doing a code review or reviewing a design doc, and even if they say something that you might disagree with or you wish they said it in a different way, they took the time to do it. They're actually genuinely trying to help, typically. The other thing that's, I think, really important, is to be very specific. In a design doc, for example, be very specific about the kinds of feedback you're looking for. You have to be open to everything. If you write something up that's 10 pages long, maybe not everybody is going to read it in detail, or maybe not everybody is going to read every page and every paragraph in detail. Be very clear on, "I would particularly appreciate feedback on this particular area."
The last part of communication I want to talk about is meetings. It's very important to have a strong discipline around meetings in a remote situation, so being very clear on what is the purpose of this meeting. We're starting to do this modeling the way Amazon does it, by sending out prereads ahead of time for other people to read. If we haven't been able to do that - this is something that Amazon culture does - have everybody sit there and read the doc together. If you maybe have an hour long meeting, you can imagine the first 10 or 15 minutes is, "Here's the document that we're going to go over. Everybody sits quietly and read it." It can feel weird the first couple of times you do it, but it is so valuable to have everybody be on the same page at the same time when you actually have a discussion.
We have found some good value out of meetings that we have regularly, having a template for those things. Imagine a status meeting where the super simple template is all the different sub teams and status from Team A, status from Team B, that kind of thing. Then if there's not a purpose for a meeting, if there's no agenda, then have a culture where you can actually cancel the meeting. When we are discussing in the meeting, it's very important for a senior person to be actively moderating the discussion to make sure that we're making good use of everybody's time, but also that it doesn't go off into a tangent, managing the time, managing the agenda of the meeting. Also, setting the expectation that if there was a preread or something like that, people come prepared. Then making sure that when we exit a meeting, we have some explicit action or next step so that we don't just leave things hanging. Either, we need to make a decision, or we need to continue the discussion, or we need to have more investigation.
In terms of etiquette, I'll just say respecting the remote people. That means not setting up meetings that are in inconvenient times for people, have a video link in every meeting by default. Ideally, if you have a meeting with a bunch of remote people, everybody dials in from their own machine, and everybody behaves as if they're remote because then you don't have some people in a room who have one kind of experience, and then other people are remote and can't hear.
The other thing is enabling catch up offline. Not everybody can make every meeting, particularly if you have a global organization like WeWork. Having a culture of writing up simple meeting minutes, even taking notes while things are going along, maybe recording or transcribing the meetings if it's particularly important. Then the other thing that I want to emphasize is making sure that there's a little bit of social connection in addition to the business. Allow people at the beginning to be chatting with each other, to reinforce social bonding and to make small talk. As my former colleague, Dave, likes to say, the only way to have real talk is to have small talk.
The last thing that I want to talk about very briefly is in-person meetings. There needs to be an expectation both for the remote employees and management and finance, that people might be doing some travel. We do that to make and renew social bonds, typically. One of the great things we did at Stitch Fix was we had regular physical meetings. We also do that at WeWork as well. Kickoffs, close collaborations. Also, when we're doing something really deep together, we might send one person from New York to Tel Aviv, or Tel Aviv to New York. Then one of the huge things that we did at Stitch Fix that was really valuable for this mostly remote culture was doing regular quarterly summits. Our goals here were actually not to achieve normal work. The goal here was to foster and reinforce social bonds and connections in order to reinforce that trust among people to use it for high bandwidth communication. Also, to the extent that we were going to do work together, it was going to be non-normal work. We wanted to make sure that those were done at a regular cadence. We found a quarterly cadence really worked well for us. More often it was really disrupting people's home schedules. Less often we were suffering from the half-life of trust. We also found that it was pretty important to plan those things well in advance so that people could schedule the travel and stuff. Then we also tried to rotate the locations pretty regularly.
As I mentioned in the beginning, and as Martin Fowler believes, and I believe, really modern organizations need to take advantage of the fact that talent is everywhere. Hopefully, you've taken away some ideas about how you might be able to do that in your company.
Questions & Answers
Participant 1: Can you talk a little about what you do to make good use of time when you have an onsite summit, like what type of activities to plan?
Shoup: I had more that I wanted to say than I actually had time to say. This is what we did at our summits. We would do it for five days. We ended up refining over time, something that really worked for us. What worked for us was one day of everybody learning some new thing together, sometimes it was sort of product-related stuff, or project-related stuff, or some technology, but we would spend most of the time prioritizing team building stuff. That can seem like a waste, but it really isn't. It so pays off in terms of the trust and the collaboration that people do going forward. With Stitch Fix in this example, we took advantage of the fact that our business partners were all in San Francisco. When we brought everybody to San Francisco, people were able to collaborate in-person with those people. At WeWork, the headquarters are here in New York. When we've done summits, and summer camps, and so on in New York, we take advantage of that.
We also found that having some part of those five days be top down organized content, and then other parts be team-wise, like, "Individual teams, this is your day to collaborate with business partners, do some fun activity," etc. Then another thing which is a great way of getting engineers to bond, particularly if engineers are awkward or neurodiverse, is to do some structured activity together that's about coding. We have found a huge advantage of that. A hackathon is one way of doing it. I have lots of thoughts about good ways of doing hackathons. My main line thought there is, we found it hugely valuable to have a theme about it, as opposed to everybody do something cool. Instead, we would have some theme or maybe two themes that would be relevant to everybody, and then self-organize, first problems that we wanted to solve, and then maybe half a day of figuring out what things we wanted to solve in detail, and then a day and a half of people hacking away.
The other thing that one of my colleagues at WeWork is organizing right now is an Internal Technology Conference. Like I said, we have 1,000 people all over the world. We actually have a critical mass that we're actually going to organize some kind of single or double track conference, TBD, but should be fun.
Participant 2: In situations where everyone can't be local, or everyone can't be remote, or for teams who have remote employees who are not all local or not all remote, what strategies would you recommend?
Shoup: The question is, if some people are co-located but others are remote, how do you do it? In that model, I like to have everybody behave as if they're remote. What does it mean to behave as if you're remote? It means you join calls on video, it means you communicate with people over Slack as opposed to in-person, it means that what you would otherwise do on a whiteboard, you do that in a doc or something like that together. Everybody, even if they happen to be at a physical co-located location, behaves as if they're remote. We do that a lot at WeWork. We did that a lot at Stitch Fix. That's the way to do it. There are these two attractors of this thing where the middle doesn't really work well. Everybody co-located and you double down on the co-location part, or everybody is remote, and you double down on the remote part.
Participant 3: When you're having meetings with multiple teams which are located and distributed, how do you encourage participation from everyone? Because let's assume that the core of the people is in one location and you have people from other locations also participating. How do you encourage them to participate and jump in?
Shoup: That's where the active moderation that I mentioned can be really helpful. When somebody is leading one part of the meeting, let's imagine that I'm talking about something that my team is working on or trying to get feedback, something that's really good is passing the mic so I could say something like, "Charles, do you or your team have something to add?" Or we always say stuff like, "Anybody from Tel Aviv? Tel Aviv, what do you guys have to say about this? Shanghai, what do you have to say about?" Very explicitly asking for that. That's one thing.
The other thing is - and this needs to be modeled - you model that it's ok to ask a question, and you model that it's ok to interrupt somebody. The interrupting can feel very rude, but you just have to set the idea that, "You know what? The internet is horrible. We're lagging all the time." Often, when somebody is talking, you might want to go back to something that they said a minute ago, because you didn't realize they were finished with that section of their talk. Setting the example. To do this as a leader, to model this, it's ok to interrupt Jason with a question, even if you have to backtrack a little bit.
See more presentations with transcripts
