Distributed & Local: Getting the Best of Both Worlds
This is a modal window.
Das Video konnte nicht geladen werden, da entweder ein Server- oder Netzwerkfehler auftrat oder das Format nicht unterstützt wird.
Formale Metadaten
| Titel |
| |
| Serientitel | ||
| Teil | 48 | |
| Anzahl der Teile | 86 | |
| Autor | ||
| Lizenz | CC-Namensnennung - Weitergabe unter gleichen Bedingungen 3.0 Unported: Sie dürfen das Werk bzw. den Inhalt zu jedem legalen und nicht-kommerziellen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen und das Werk bzw. diesen Inhalt auch in veränderter Form nur unter den Bedingungen dieser Lizenz weitergeben. | |
| Identifikatoren | 10.5446/31242 (DOI) | |
| Herausgeber | ||
| Erscheinungsjahr | ||
| Sprache |
Inhaltliche Metadaten
| Fachgebiet | ||
| Genre | ||
| Abstract |
|
RailsConf 201748 / 86
1
8
10
12
18
19
23
30
35
42
49
52
53
55
56
59
65
74
77
79
82
83
84
00:00
Office-PaketAusreißer <Statistik>Rechter WinkelKonfiguration <Informatik>Endliche ModelltheorieURLCASE <Informatik>SoftwareentwicklungMultiplikationsoperatorStellenringProdukt <Mathematik>HybridrechnerGibbs-VerteilungBetrag <Mathematik>Open SourceDruckspannungSelbst organisierendes SystemUmsetzung <Informatik>Prozess <Informatik>KontrollstrukturMAPWeb SiteRPCRechenwerkDatensichtgerätFormation <Mathematik>BitTelekommunikationWhiteboardSondierungMereologieMaschinenschreibenSoftwareentwicklerKollaboration <Informatik>Gebäude <Mathematik>Zellularer AutomatRauschenOrtsoperatorMinkowski-MetrikAggregatzustandSoftwareDruckverlaufVerschiebungsoperatorDatenverwaltungLesen <Datenverarbeitung>EDV-BeratungPerspektiveTypentheorieUmwandlungsenthalpieZahlenbereichInteraktives FernsehenMusterspracheKartesische KoordinatenLeistung <Physik>KreisbewegungKomplex <Algebra>DifferenteGanze FunktionFokalpunktQuick-SortPufferüberlaufKeller <Informatik>Gesetz <Physik>ModallogikComputeranimation
08:23
TeilbarkeitVertauschungsrelationWhiteboardBenutzerschnittstellenverwaltungssystemMultiplikationsoperatorComputerspielPunktGemeinsamer SpeicherURLSchedulingSchlussregelEnergiedichteThumbnailKonfiguration <Informatik>ZahlenbereichRPCWellenpaketTouchscreenTelekommunikationGruppenoperationRechter WinkelVideokonferenzData MiningTotal <Mathematik>MereologieStreaming <Kommunikationstechnik>KreisflächeProgrammablaufplanArithmetisches MittelProzess <Informatik>Selbst organisierendes SystemOffice-PaketZeitzoneAuswahlaxiomGraphfärbungBitFlächeninhaltBildschirmmaskeMultiplikationInformationsmanagerStabilitätstheorie <Logik>Güte der AnpassungDreiCodeStochastische AbhängigkeitGebäude <Mathematik>Wort <Informatik>TabelleReelle ZahlDimensionsanalyseWechselseitige InformationLesezeichen <Internet>AggregatzustandNotebook-ComputerFeasibility-StudieModallogikQuaderProdukt <Mathematik>SoftwareentwicklerATMFigurierte ZahlLesen <Datenverarbeitung>GeradeAppletVerschiebungsoperatorComputeranimation
16:46
GeradeOffice-PaketMereologiePunktTVD-VerfahrenQuick-SortAnwendungsspezifischer ProzessorLeistung <Physik>Selbst organisierendes SystemTelekommunikationStandardabweichungTexteditorUmsetzung <Informatik>Rechter WinkelGruppenoperationMinkowski-MetrikFlächeninhaltSchlussregelMAPWorkstation <Musikinstrument>Message-PassingPhysikalisches SystemBenutzerbeteiligungMultiplikationsoperatorFlächentheorieChatten <Kommunikation>VideokonferenzKartesische KoordinatenWhiteboardWort <Informatik>RauschenProzess <Informatik>MatrizenrechnungDifferenteAggregatzustandZählenARM <Computerarchitektur>RelativitätstheorieEinsTabelleDiagrammEndliche ModelltheorieCodeLoginProgrammpaketDatenstrukturKollaboration <Informatik>RandverteilungVollständiger VerbandSoftwareentwicklerNeuroinformatikURLGerade ZahlCodierung <Programmierung>Multi-Tier-ArchitekturSoftwareHypermediaArithmetische FolgeSprachsyntheseGebäude <Mathematik>Ultraviolett-PhotoelektronenspektroskopieEinfach zusammenhängender RaumProgrammfehlerSchnittmengeProdukt <Mathematik>Automatische HandlungsplanungRechenschieberInstant MessagingStellenringRPCTouchscreenZweiRegulärer GraphComputeranimation
25:09
TelekommunikationProjektive EbeneGüte der AnpassungNormalvektorMultiplikationsoperatorDreiecksfreier GraphLesen <Datenverarbeitung>PunktSelbst organisierendes SystemKartesische KoordinatenGruppenoperationInteraktives FernsehenURLEinfach zusammenhängender RaumRPCSpieltheorieSoftwareentwicklerGrundsätze ordnungsmäßiger DatenverarbeitungKonfigurationsraumOrtsoperatorDatenfeldWorkstation <Musikinstrument>NeuroinformatikRechter WinkelSpeicherabzugMereologieVerschlingungWürfelTeilmengeOffice-PaketWhiteboardATMEvoluteFlächeninhaltSchreib-Lese-KopfWort <Informatik>ComputerarchitekturDatenflussMAPGebäude <Mathematik>Prozess <Informatik>DatenstrukturTwitter <Softwareplattform>RechenschieberFlickrCOMProdukt <Mathematik>EinsExogene VariableBandmatrixPeer-to-Peer-NetzFokalpunktComputeranimation
30:40
Projektive EbeneServerWeb SiteVideokonferenzParametersystemRechter WinkelExtrapolationMixed RealityDemo <Programm>Umsetzung <Informatik>SoftwareentwicklerTelekommunikationGüte der AnpassungURLWiderspruchsfreiheitMultiplikationsoperatorFokalpunktEntscheidungstheorieATMTypentheorieZeichenketteStellenringProdukt <Mathematik>HilfesystemFigurierte ZahlVersionsverwaltungSoundverarbeitungRPCPunktComputerunterstützte ÜbersetzungMinkowski-MetrikInteraktives FernsehenWikiCASE <Informatik>CodeNatürliche ZahlGesetz <Mathematik>Physikalische TheorieLokales MinimumGanze ZahlPuls <Technik>DimensionsanalyseVorlesung/Konferenz
36:11
XML
Transkript: Englisch(automatisch erzeugt)
00:13
I'm here to talk to you about local and remote teams. And who here was in the last talk as well?
00:21
It was an awesome talk, wasn't it? They really did a great job with that. I'm gonna cover some of the same things. It'll be a little different. It'll be from my perspective, but yeah, I really enjoyed listening to Glenn and Maria tell their experience as well. So my specific perspective on this is looking at hybrids, where we have team members who are local and team members who are remote and how to get the best of combining those two styles.
00:43
So I wanna start with a quick poll. If you would raise your hand if you today are primarily someone who works locally in an office, maybe not every single day, but most of the time you're in an office with the rest of your team. Okay, maybe half. And then how many of you are primarily remote?
01:00
The other half, makes sense. How many of you would like to do the other? Okay, so that's what we're gonna focus on is some of the advantages of each, why you might choose one versus the other. I think there's a lot of value in each one, and I've done both, and I enjoy both, and there's a lot to look at there.
01:20
So an introduction, a little bit about me first. My name is Ben Clang. I have been doing Ruby for 10 years, doing open source for 20. A lot of my appreciation for remote work comes from open source, where when you're doing open source work, most of the time it's remote anyway. Your collaborators are in other parts of the world.
01:40
Previously I founded a company called Mojo Lingo. We were a software consultancy. We were a remote first company from day one. About 12 people, not a huge organization, but definitely learned a lot from that experience. Today I'm vice president of business technology for PowerHomer Modeling. It's a much larger organization. About 2,000 people in the company, 51 in the technology department.
02:01
We have seven scrum teams, six states, four countries. And really about half and half when it comes to local versus remote, or local versus distributed. And again, I want to stress, this is my experience. It comes from what we've done in the past and what's worked well for us. I would say that everything you hear today
02:22
has come from something we've learned, something that hasn't worked. And I'm sure that some of the things that we do today we will find better ways to do tomorrow. And that's okay, that's just part of the process. So I want to start with a little bit of background. What kind of teams exist? What are we talking about when we talk about remote teams? And I want to emphasize that when I say team, I'm really thinking of a fairly small unit.
02:41
I'm thinking of three to five people, not the entire department, say, but the actual people that you depend on day to day, the kind of people where if they're not around you would end up blocked, right? So first of all, local teams. That's a pretty easy one, right? People in the same building. Not really in the same building, but in the same floor and in the same room even.
03:01
I remember reading that people who are just separated by as little as one floor start to lose some of the benefits of being a local team, right? Some of that face to face interaction is lost when you have to go out of your way to interact with them. So local teams, we're focusing on people who are physically co-located together, preferably in the same room.
03:22
Another one is remote teams. Again, pretty intuitive. People who are spread out in many different locations. Sometimes it'll be at home, sometimes it'll be in a coffee shop, sometimes it'll be in a co-working space. We actually do have one guy on the team who for some reason just loves coffee shops. He will spend his entire morning in a coffee shop. I don't know, I couldn't deal with the noise, but he works for him.
03:43
And then there's a third type, which are mixed teams. So this is a type of team where you have most of the people on one physical location and then one person who's kind of an outlier. This is, to me, this is an anti-pattern. I don't really want to talk about it much other than to say I strongly advise that you don't do it.
04:00
This can lead to isolation, right? This can lead to this one person being left out of conversation. This can lead to people not having the same level of understanding about what's going on within the business, what's going on within the team, what's going on within the software being developed. And sort of another spin on the same topic is where you have one team that is split into two parts.
04:21
So you have a part of the team in one location, part of the team in the other. Again, you'll end up forming cliques. There'll be small communication patterns, reference to Conway's Law earlier, right? When people are communicating together, the organization will develop that way. So again, I don't recommend this style either. So I'm gonna say something that may be controversial.
04:41
Maybe you agree with me. I just ask that you hold your pitchforks until the end, and I'll explain why I think this. But I feel pretty strongly that local teams win. They're the most effective, most efficient way to develop software. I don't think, I think that all else being equal, if you can control for everything else,
05:00
having everybody in the same room is gonna be the fastest way to deliver what you want. And I say this myself as a hired employee, spending about half my time on site, half my time working from home. I say it as someone who founded a business that was remote first and successfully remote first. I was very happy with that company. And I say this as a manager of three remote teams and one local team.
05:21
I think it's better for communication. I think it's better for camaraderie, better for brainstorming and for resolving issues. And even Scrum teaches, we follow Scrum pretty religiously, and one of Scrum's big things is get your teams co-located, right? So this isn't just me saying this. This is kind of the wisdom being taught. So then why even talk about remote teams?
05:41
If local's clearly the way to go, why would this even be a conversation? That's because we wanna be remote. A lot of us wanna be remote. Just from the hands I saw earlier, half of you are doing it, and another good chunk of you would like to swap whatever you're currently doing. So there's this really great Stack Overflow article, or rather survey, and it came up with 53% of people looking for jobs
06:04
want some kind of remote option as a top priority in seeking a new position, which means if you're trying to hire these people, this is a major competitive advantage for you. If you have remote options in your employment, then you have the attention of a very large number of job seekers right away.
06:21
Additionally, 11% of remote workers report higher job satisfaction, or I should say the job satisfaction is 11% higher among people who have local or remote options versus purely local. So it's not just about acquisition. It's also about retaining the teams that you have, keeping them happy. Happiness is correlated with productivity
06:41
and with longevity within the organization. So this is a big deal, right? And I do wanna touch on something I think that Glen and Maria said very well, which is that not every position can be remote, and within our organization, we've called out a few specific types of positions that we will not consider remote applicants. The two that are kind of obvious
07:01
are application support and infrastructure support, the people that day-to-day have to interact with some of the end users. We are self-hosted, so we have our own physical infrastructure, and we have the teams that manage that infrastructure. We want them local in case something breaks. They can unplug it and replug it as necessary. And the third one, which is a bit of a shift for us,
07:23
is junior development teams. So we actually, we did a first time for us, experiment a year ago, where we put together a team of developers who were junior and paired with them a mentor to bring them up to speed, and we did it as a remote team. And it was successful. I wanna say that the people who went through that program
07:42
are all with the company still today, and they're absolutely valued members of the team. But what we found was it was harder to support them and mentor them in the ways that they deserved. It was harder to establish the kind of communication, to jump over to the whiteboard and explain some kind of complex process than it would be if they were local.
08:01
So going forward, we've started saying that all junior developers, we wanna put them at headquarters where they can be mentored with other team members, and given the attention that's necessary there. So what are the benefits? What are the benefits of enabling teams to be remote? And I'll start with benefits to employers. First of all, obviously, it's a broader applicant pool.
08:22
If you're looking in one location, best case scenario, you're kind of saying, give me the best person within 50 miles. That's just a small pool to begin with, no matter where you are. If you can open that up and say, give me the best person plus or minus three hours, suddenly you have a lot more options to choose from.
08:41
And ultimately, what you really wanna say is, who's the best person for the job? So as your organization continues to expand, and as you can start to form teams in multiple locations, as you can start to organize teams around locations, you're not just looking at one geographic location or even one time zone, you can actually look around the entire world. This has a bunch of advantages.
09:00
It has advantages like taking better advantage of referrals. So the people on your team are going to refer their friends, hopefully. If you're a place that they want to work, hopefully their friends also want to work there as well. And if those friends happen to not be in your city, you might not have the opportunity to work with them. It definitely improves things like time to hire.
09:20
So as we grew, we had to grow, we doubled in size twice over the last two years, basically doubled each year. And the only way we could do that was looking remotely. We just couldn't get a big enough stream of candidates looking only locally. So that was a major shift for us. But it also increases the opportunities for diversity.
09:42
I think that the last talk mentioned this well. You know, if you're a mother with a newborn child, and you don't want to or can't easily get to the office, that's a limiting factor, right? When I was a single father,
10:00
my daughter would come home from school at 3.30, and I could be home to be there with her. That was a big deal for me. That meant that if I was tied to an office, I would have to drive home to do such a thing. That's not feasible, right? But if I was able to work from home, I could be there for her. So that was a big benefit for me. So let's talk about the benefits to the employees as well.
10:21
I talked about being home when my daughter got home from school, but it's more than just that. It's also a choice of lifestyle. For myself, I like living in the city. I like being in an urban area. I like not having to have a car. I like being able to walk to shops and restaurants. That's the quality of life for me. A very good friend of mine,
10:40
he had five kids, has five kids. They lived about two hours away from the office, so two hours one way to drive from his house to the office and at the time, the company we worked for, this was 10 years ago, they did not have remote options, wasn't on the table. So every day, he would drive two hours into the office and he would work a full day
11:00
and he would drive two hours home, so four hours of his day. By the time he would get to the office, he had already been up for at least two, probably three hours. He was tired from the drive. He was stressed from dealing with traffic and then even at work, sometimes he would be trying to figure out how to make his commute better, trying to find just the right time to leave to avoid traffic or started looking at train schedules
11:21
to try to figure out, is there another way for me to get to the office? No doubt that impacted his productivity. There's just no way you can be as effective when you're spending that much of your energy getting yourself physically to a location. So getting to live where you choose and being able to do so remotely gives you that flexibility, gives you the option of picking the lifestyle that's right for you
11:40
and being able to have the job that is right for you as well. So one size does not fit all. And then there are mutual benefits, things that benefit both the employer and the company. Life is not static. The one thing we can count on is that it will change. What has actually happened with a lot of our team members
12:01
is their life situations have changed and they have needed to move. So one of my favorite examples is a very good friend of mine. He was living in the UK. He got married to a Brazilian and they wanted to live in Brazil. If his employment had been tied to his physical location, then we would not have been able to keep him within the organization.
12:21
And he's a very strong developer. So that was important to us. Like having him be a part of organization while he still was able to live the life he wanted to do and allow his life to evolve in the way he wanted to evolve it, that's important. So that gives him the ability to transition his life while retaining the stability of his employment and it gives us longevity of someone
12:42
who's a valued team member, someone who knows and how we've already invested teaching him about the organization. Those are things that benefit both sides pretty well. So location independence adds longevity to employment, which is a win for both sides. All right, there are challenges. No surprise, right? Remote's not all easy.
13:02
I hope everybody brought a pencil and paper. I'm gonna give you the three most important bullet points for remote work. Everybody ready for this? Okay. Number one, communication. No surprise. Communication's the biggest challenge to remote work. What may not necessarily surprise you is that number two is also communication
13:21
and number three is communication. Right, got it? Okay, sweet. Communication challenge number one, my favorite, time zones. Love time zones, hate time zones. Time zones were the biggest factor in figuring out how and where to grow the team because while we don't particularly care where you live,
13:42
we do care that you have the ability to communicate with your team. We do care that you can support each other. We do care that you can ask the questions and get answers and get unblocked. So we have a rule of thumb. A team should not spread more than three hours total, not plus and minus three hours, three hours total.
14:01
So we try to group things, and these circles are not exactly representative, but the point is that we try to group teams such that no one is more than plus or minus three hours than anyone else in their team, and that gives a nice amount of overlap to the workday. Now, you'll notice that some of those circles are decidedly longer than three hours, and as I mentioned earlier, one of the benefits of smaller teams
14:20
is you can orient your teams in such a way that the teams themselves are within that three-hour rule, but across the organization, you can have multiple teams and you can spread the work around that way. So that does work. Communication challenge number two, being able to understand things deeply, not just superficially, but truly understand the work you're doing
14:41
and why you're doing it. I love this quote by George Bernard Shaw. "'The single biggest problem in communication "'is the illusion that it has taken place.'" So you might spend a bunch of time trying to explain what we're building and why, and depending on how you do it, you may or may not have actually been heard. I think this is one of the reasons we love whiteboards,
15:02
is when you can get up and draw something, a picture's worth a thousand words. It makes it so easy to explain relatively complex concepts when you can map them out like that. The problem is that doesn't really work so great when you're remote, right? You can't just pull up a whiteboard. I have tried lots of online whiteboarding tools, and they all are kind of disappointing in one way or another.
15:22
But you have to replace that somehow. So we lean a lot on video conferencing. We lean a lot on screen sharing. Screen sharing is huge. Code reviews are a big deal. And then my CIO's favorite, flowcharts. Don't be afraid of the flowchart. This maybe took me 15 minutes to put together.
15:42
There's no color. It's not very pretty. It's a bunch of boxes, a couple arrows, and a little bit of text. But it really conveys very quickly some things we're trying to get done. And so this has become part of our culture, and we're even trying to encourage more of it. The point here isn't to burden you with documentation. The point here is to communicate as clearly
16:01
as you would on a whiteboard. And if you start to build that into your culture, you can partially solve this problem of deep understanding. All right, communication challenge number three. Perceptions and distractions. Everyone knows Dilbert? If I can't see them at their desk, how do I know they're working?
16:21
It's a real problem, right? Anyone dealt with this? Yeah. Point to your bosses everywhere. There's a flip side to this, though. As a remote employee, my team lead is always multitasking. How do I know if she's taking me seriously? A lot of our communication happens in video conference. Video conference, for most of us today,
16:42
means working on a laptop. So if I'm speaking with someone on my team, and we're having a great conversation, it is really tempting, really tempting, just to Alt-Tab, pull up email, answer something, answer a quick, instant message. That is so destructive. It's so destructive if the conversation's happening. It's even worse when you do it in a stand-up or a retro,
17:02
and you're not paying attention to the team. That's something you have to fight. It takes conscious effort. It doesn't come automatically. You've gotta put that away. In addition, you need to make sure that, back to the first point about, if I can't see the team, how do I know they're working? You need to also make sure you proactively manage up.
17:22
Talk to your supervisors. Let them know what's going on. For us, a lot of that comes through dealing with tools like Pivotal Tracker and code reviews. A lot of it has to do with retrospectives, and, excuse me, stand-ups, and sprint planning. Those are opportunities to communicate within the team about what's going on, but also to communicate about progress so people know what's happening.
17:41
I'll talk even more about that in just a second. So that's kind of an overview of some of the benefits and challenges. I wanna be really specific and talk about how we do it. This next few slides are going to talk about what we do at Power to work through these challenges. We understand that there's value in both styles of work, local and remote. We understand there are business realities
18:02
of acquiring and retaining the people that we want on the team. And then retaining has a lot to do with happiness. So we needed to find a way to get the best of both of them. First, we looked at structure. Small teams, three to five people. That is a big deal for us, is keeping it small. And if a team starts to get too big, we don't hesitate to split it apart into smaller teams.
18:25
And also consistent teams. I'm a big believer in not trying to mix local and remote. You can put two people in one location on the same team. But if you do it, they need to act as if they're remote. They need to be on video conferences on their own computers so that they have the same, they have parity at the communication layer
18:41
with everyone else in their team. So it doesn't feel like there's just two people and then the rest of the team. Back up one, yeah, okay. Then we have process, Scrum. As I said before, we're a big believer in Scrum. And there's this sort of related concept of Shu Ha Ri,
19:01
which is where, in the beginning, you do it exactly like the book says. And we're probably at that point now. Most of what we do is doing our best to stick to the principles exactly as written without too much variation. And then the next step for that is Ha, which is where you understand the principles and you can start to bend the rules where necessary to adapt to your situation.
19:21
And then there's a mastery level, which is where you completely understand everything and why the rule exists in the first place, and then you can break the rules whenever you want, because the rules no longer exist. It's sort of like The Matrix, flexes his arms and the walls bend. I wanna do that. So for us, that process, daily standups and retrospectives are really critical parts for managing the communication,
19:41
ensuring the communication with remote teams. Standups, if nothing else, give you an opportunity every day to make sure you communicate with everyone on your team. It's really easy to do, right? If we were all remote and just focused on our pull request, it's so easy to get into the editor, push the code, move on to the next thing, and not even talk to anybody. But standups at least, if nothing else, will give you a chance once a day to communicate.
20:02
And retrospectives as well will give you kind of an early warning system. If things aren't going great, retrospectives will bring that to the surface. And it's just, again, another way to checkpoint communications, make sure they're happening regularly. Of course, you have to emphasize remote-friendly communication. We do a lot with code reviews.
20:21
Every single piece that goes to production has had a code review. It's one of the three criteria we require to ship code. Obviously, text chat, a lot of people use Slack. We have a tool internally called Connect that's the same concept, but it's critical not only because it facilitates communication within our development team, but also within the larger company. Anyone can talk to anyone at any time.
20:41
That's critical. Video conferencing and screen sharing, I mean, I've already given the examples for that, but again, without the ability to pull up a whiteboard, being able to at least look at the same thing and talk about it makes a big difference in facilitating communication. And then, as I said, diagrams. Love diagrams.
21:00
And then culture. Face-to-face meetings. It is my goal to, at least once every 90 days, spend some time face-to-face with everyone on one of my teams, just to have that personal relationship with them. We also do lunch and learns, and I gotta give credit to Jill, who's in the audience, and probably more defined than calling her out right now, but she did a lot to make lunch and learns
21:22
happen for our team. She did a great job with that. And that has been not only helpful for onboarding and bringing new people into the organization, it's also been really helpful in just getting people talking across teams. As we emphasize small teams and as we grow, we end up adding more teams. They don't necessarily communicate as much as they would otherwise,
21:41
so lunch and learns are a great way to get a larger group together. And then she was telling me yesterday she wants to do coffee dates, which I think sounds like an awesome idea, so I think we'll be doing that when we get back. All right, so we've talked about how we're doing it. I wanna talk about one more topic, which is how we optimize for the different styles. We'll talk first about optimizing for local teams.
22:02
For the teams that we have decided will be local, whether they are development or support or DevOps, there are a few things we can do to make them more productive, to maximize the benefits that they have. First, we built a headquarters that has a lot of collaboration space. I mean a lot. Probably, at least within our department's
22:21
area of the building, at least half, maybe more than half of the space is dedicated toward collaborative areas. Lots of whiteboards, lots of tables where you can pull up. There's power to plug in. There are, I don't know what those little puzzle piece chairs are. They're sort of like bean bags, but sort of not. But it's just a more casual space where you can discuss things.
22:41
And we use that space not only for internal conversation, and I think this is really important. We use it to also talk to the business. These two rather serious-looking fellows are from our talent acquisition department, and we're in the process of building some software to help them automate some of the work that they're doing. This is them coming into our area
23:00
and speaking with the guy in the red shirts in application support, and he's explaining some of the features we're delivering and some of the bugs that we're addressing. And so this is communication not only for within the team, within the department, it's also communicating out to the business. So there's a real danger if you have an entirely remote team that nobody can see that stuff just happens and nobody knows about it. This is part of our effort to make sure
23:21
that the business knows what we are up to and that they can appreciate and understand what we're prioritizing and why. And then on that same kind of vein and actually even more outbound, we have this area called the knowledge dojo, which is very much modeled on the Apple knowledge bar concept. We have this area which is outside. It's in a very public space,
23:40
a hallway where a lot of people walk by. And anyone who has a technical issue of any kind can walk up and ask questions. You know, I need help with a mouse or printer ink, or I have trouble with the application. And again, it's just putting a very public face on what we're doing and why. Ultimately, if you do this right, if you build the kind of connections with the rest of the business,
24:00
what it does is it lowers resistance. I don't know, I don't think I mentioned this early on, but the business we're in is home remodeling. And the company we're in is in many ways traditional. Very local, very much. People come into the office, you saw the people in suits. That's because they actually wear suits. And we're a little different. Not only do we not wear suits, a lot of us just aren't even there. So we need to manage that. We need to let them know that we're working with them,
24:22
we've got their back, and this kind of outreach is a big part of that. So it lowers the resistance to enabling remote work. And then finally, as developers, sometimes you just have to get away from the noise. So we have these little pods we built. There are 12 of them. For the people who are local, they become their office. And then for the people who are remote,
24:41
whenever they're at headquarters, they can use them as office space. They're quiet, they're away from the noise, and then the colorful lights, besides looking really awesome in this picture, have a purpose. If the light is red, it means you're busy. You don't want to be disturbed, and please leave me alone, come back later. And if it's green, you can come in and have a conversation.
25:03
All right, that's what we do for local. What can we do for remote or distributed teams? Daily standups. I'm just gonna hit that point again. That is a big part of how we manage the communication, how we keep the communication good. And we don't have to take them too seriously,
25:22
as Darren is showing you. What else do I want to say? The other thing I wanted to say about this is this is kind of an interesting team. This team has since been reorganized so that they are now entirely local, but at the time this picture was taken, three of the people were physically in the same location, and two of them were in remote locations.
25:40
But the reason I show this is, this is a good example of getting everybody on the same playing field. You'll notice everybody is at their own workstation on their own computer talking and communicating as peers. So the guy in the bottom left and the guy in the bottom center and the guy in the top right are roughly 10 feet apart from each other in their cubes but whenever it came to team communication,
26:00
they would level the playing field to ensure that. I talked about getting face-to-face as a way of enabling remote communication, and this is a big part of it. So it's not just for work. We do a lot of work. We do this three times a year. We call it create. We bring all the developers, all the remote workers
26:20
to headquarters. We bring in the application support teams that they work with. We bring in the infrastructure teams they work with, and we find that it's not a hackathon exactly. How would you describe it? Basically, we take goals and projects that are hard to get to in the normal cycle of development. Sometimes they're bigger picture architectural things. Sometimes it's a cool feature
26:40
that we just couldn't work into the normal flow, and we'll go build it. We'll spend a week building it. What's cool about this, and by the way, not something that we necessarily planned but was a beautiful kind of emergent behavior, was that the teams self-organized, and they did it in different configurations than their daily teams.
27:01
So when they're out in the field, maybe you have this group over here and this group over here, but when they actually came to this session at headquarters, they picked completely different people to work with, and that's beautiful for the kind of personal connections that are necessary to both grow and also to get questions answered beyond your team, and of course, it's not just work. It's social too, right?
27:20
So we have both structured and unstructured time where people can, we were doing some kind of weird game show thing. So that's one of the structured examples. We've done go-karting. Almost killed somebody, but it's okay. He's arrived. But it's important, right, because these are the things that are hard to do in your remote. It's hard to build those social connections
27:41
and the trust that comes from goofing off with somebody. All right, so in summary, there are three things I would say. When you have a local team, you want to optimize those face-to-face interactions. That's your core strength, right? You've got people there. You want to give them as many opportunities to communicate with very high bandwidth,
28:03
both internally and externally. Second, you want to develop the tools and practices that are necessary to make remote work successful, and this doesn't happen automatically. It takes effort. It takes conscious thought, and it takes evolution, which is the third point. Don't accept the status quo. Whatever you're doing today is great,
28:21
but there's always something you can be doing better, and the retrospectives and create are big parts for us for analyzing that process, finding ways, finding what's working, finding what's not, and then finding what can be better. I want to give you two links for further reading. I want to thank Martin Fowler for a really awesome article that guided a lot of my early thinking
28:41
about how to build distributed teams. This article's from 2015, not that old, but he goes into some more detail on some points I kind of glossed over here, highly recommended, and then weworkremotely.com, when we were hiring specifically for remote developers, this is where we would advertise, and got great responses. It's such a focused demographic, I think, that helped a lot.
29:02
It's also associated with a book that the guys at 37signals put out called Remote. The website goes along with that book. That's it, so my name's Ben Clang. You can find me at bclang, just about everywhere, GitHub, Twitter, et cetera, and thank you very much.
29:23
Okay, I'll try to repeat the question. So in one of the slides, I had a team that was hybrid, the mixed, that I said was a bad idea, right? And the question, I think, was, when we did bring them in to make them a local team, how did we handle that transition, and what happened to the people that were remote? Did I get that right?
29:40
Okay, so a couple things. One, one of the people just started coming into the office more regularly, and he was already in the area, but it wasn't a big deal to start commuting, right? The other one was in Australia, and he's kind of an interesting story. He came into the organization by a fluke.
30:01
To be really honest, I missed that he was in Australia when I started the interview process, but by the end of the interview process, I was so impressed with him that I said, we gotta make this work, and he was great, because he actually worked really hard. He, for probably seven months, eight months, lived on East Coast time in Australia, which, God bless him.
30:21
I couldn't do it, right? But anyway, we ultimately actually had sponsored him and had him move to the United States, so no one on the team was let go. We did reorganize to put them all together, but we made that happen organizationally, and they were all on board with it. That team in particular, it was a positive thing for them, right?
30:40
So to repeat the question, when you're in a mixed situation, and I'm not sure if you were the only person that was on the outside or one of a, okay, so you were in that picture where you had a bunch of you in one location and one person remote, and then, to your point, you were having conversations and decisions being made, sometimes without that person, just because they were spontaneous,
31:00
and then how do you deal with that? It's tough. If you find yourself in that situation, the only advice I can give you is that you have to be very conscious about it and try to force more of your discussions to happen in a mode where they can be observed by the person remotely. Text chat is probably the best place for that. I don't think there's an easy answer. I wish I could give you one.
31:21
Our philosophy has been just don't do it wherever possible. You can somewhat help that by keeping your team small. There's less of a risk of that if you're only having to manage three or four people. If you're keeping the team small, it's harder to have one person remote. You're either all gonna be remote, you're all gonna be local just by virtue of having a few people to adjust.
31:40
But yeah, I hear you. That's a difficult situation, and the best thing I can say is just try to avoid it. That's a good question. The question is are there certain types of projects or I guess to extrapolate certain kinds of work or projects? The technology type, okay, that are better suited to local versus remote.
32:03
Well, so projects that require you to physically touch things like putting a server into a rack, that's an easy one, and that's really what led us to wanting those teams on site. In the development space, I'm trying to think of any project where it's purely writing code,
32:21
where we have that issue. Nothing comes immediately to mind. Pretty much everything, once you get past that physical realm, as long as you have a way to communicate, I can't think of any, I think that either can be made to work effectively. With the proviso that you're doing all the other things that you're doing standups, you're doing retrospectives, and that you're gathering the team
32:40
so that the communication is occurring naturally. Oh, one thing I didn't mention is, besides just the three times a year, we also, if we have a big launch for a big feature, we'll bring the team to headquarters for a week and we'll focus on the stories for that feature, and the payoff for that lasts. We might spend one week on site like figuring all the pieces out, and then for three months, they have a really good, clear picture
33:01
of what they're trying to build, and that helps a lot as well. So the question is for teams that are mixed right now, what's my recommendation for getting past that? To make them work. When we did it, we had the same problems
33:20
that I've talked about, where people were felt isolated, people were left out of decisions, and what we tried was a lot of video conferencing, a lot of text chat, a lot of notes in wikis, in pull requests, written documentation, and then would try to encourage people to remember when you had a pull-up conversation
33:40
to go dump the artifacts from that into something that everyone else can see. It can be done. My personal opinion is you've just gotta be superstar, like focused on proactively pulling those people closer and closer to make sure that it happens, and I think that's hard. I just think human nature, it's too easy to have a quick conversation
34:02
and then to act on it without actually informing anyone else. My advice would be, if you can, try to reorganize such that you don't have the mix, and that takes time. I'm not saying it's easy or automatic, but like I said, it can be done. I just think it's hard, and I don't think we will do it again if we can help it.
34:21
That's interesting. So you're saying that in your company, it's mandated that you have teams that are mixed, some remote and some local, with the goal being to ensure consistent culture? Okay, and then, so what are the ways you can address the culture arguments while not doing it in a mixed team mode? Okay, so tactically, some of the things I talked about,
34:42
the lunch and learns are good, because they cross teams, and because they happen regularly, and in our case, every two to three weeks, depending on how excited people are about finding something to present, at least everybody's coming together for that. The other thing we do, and I didn't mention this, but the other thing we do is every week, we do demos on Friday,
35:01
and again, that's the entire department. Everybody gets together. Everybody sees what everybody else is doing, and everybody gets to ask questions, and in some cases, in this case, like right now, we have two teams who are working on alternate sides of the same feature, and so one happens to be local, and one happens to be remote, and in those cases, we are trying to do more.
35:23
We put them in a single chat room. Those are all really small answers to your questions. I think the bigger answer is, the answer to culture itself is culture, is getting people to understand each other,
35:41
to respect each other, and to want to communicate with each other. All of these other things grow out from that. I don't think culture's easy. I think it's conscious, and I think it can be done, and again, bringing people together so that they get that face-to-face time helps with that. Does that help?
36:00
Okay, good. Anyone else? Awesome. You've been a great audience. Thank you very much.