We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Working Distributed: How Does It Even Work?

00:00

Formal Metadata

Title
Working Distributed: How Does It Even Work?
Title of Series
Number of Parts
96
Author
License
CC Attribution - NonCommercial - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
I've been fortunate enough to work for a distributed team for the past 3 years. But for developers or teams who are considering this option, what does this actually involve? How can you maximise your chances of success? How can you actually be productive and happy no matter where you are? In this talk I'll cover many topics which are near and dear to my heart, which are: Working From Home - how to be happy and productive Supporting Remote Work - tools, advice and guidance for making your workplace more flexible Distributed Teams - how teams across different timezones can actually function
Moment (mathematics)Multiplication signGoodness of fitTwitterProcess (computing)UMLComputer animation
Dean numberInformationHuman migrationPhysical systemFatou-MengeMereologyControl flowMobile appBitInternetworkingPoint (geometry)RootInformationDatenautobahnDot productComputer animation
MereologyTelecommunicationProcess (computing)Decision theoryPlanningBoss CorporationOffice suiteQuicksortRemote procedure callTerm (mathematics)Multiplication signAnalogyLaptopOpen setCurveSoftware developerTime zoneSupremum
Office suiteOpen setPlanningProgrammer (hardware)Noise (electronics)Multiplication signInformation technology consultingArchaeological field surveyMeeting/Interview
TrailData recoveryAverageOffice suiteTask (computing)Condition numberStatisticsProgrammer (hardware)Archaeological field surveyPlanningTime zoneQuicksortInformationDisk read-and-write headOpen setIntegrated development environmentOffice suiteInternettelefonieComputer animation
Staff (military)Observational studyControl flowCodeLink (knot theory)Multiplication signBitQuicksortComputer configurationBoss CorporationCall centreSpacetimeStress (mechanics)Remote procedure callField (computer science)1 (number)Sound effectCommutatorStatisticsCASE <Informatik>Water vaporMereologyOnline chatEmailObservational studyOffice suiteRandomizationSelf-organizationVirtualizationProcess (computing)Virtuelles privates NetzwerkHand fanBookmark (World Wide Web)CoroutineStaff (military)Latent heatLaptopProgrammer (hardware)Physical systemFirewall (computing)Group actionInternetworkingWebsiteWeb serviceComputer animation
Numeral (linguistics)Online chatClient (computing)Computing platformMereologyWeb pageInformationQuicksortOnline chatMultiplication signProjective planeOffice suiteComputer animation
EmailGraph (mathematics)BitRoboticsSI-EinheitenInformationEmailOnline chatQuicksortPhysical systemINTEGRALProjective planeWeb pagePunched cardUniform resource locatorSoftwarePoint (geometry)Instance (computer science)Multiplication signDemo (music)Information overloadMereologyWebsiteComputer animation
Focus (optics)Computer animation
Asynchronous Transfer ModeTime zoneComputer iconFrequencyMultiplication signComplete metric spaceComputer animation
Open setComputer fileDocument management systemMessage passingKeyboard shortcutReading (process)VideoconferencingQuicksortMoment (mathematics)FrictionVideo gameBijectionBoss CorporationSystem callPoint (geometry)Uniform resource locatorOnline chatLatent heatMereologyLogin1 (number)Shift operatorMultiplication signReal-time operating systemEscape characterMeeting/Interview
Web pageQuicksortEvent horizonStreaming mediaOffice suiteMultiplication signRow (database)MereologyTime zoneSource codeComputer animation
Uniform resource locatorClassical physicsQuicksortBitMobile appArithmetic meanHyperlinkInformationWebsiteShared memoryEvent horizonOffice suiteServer (computing)Integrated development environmentComputer animation
EmailConcurrency (computer science)Code refactoringHydraulic jumpBitProcess (computing)WindowComputer animationJSON
EmailConcurrency (computer science)Code refactoringContext awarenessDisk read-and-write headSoftware developer1 (number)CommutatorPower (physics)Right angleComputer animationMeeting/Interview
Office suiteLine (geometry)Chemical equationOffice suiteCommutatorComputer animation
Row (database)CoroutineFlow separationVideo gameChemical equationBoundary value problemInheritance (object-oriented programming)BitProper mapSpacetimeQuicksortCrash (computing)CoroutineOffice suiteArithmetic meanControl flowData structureComputer animation
ProduktraumSpacetimeMultiplication signRemote procedure callTime zonePlanningLocal ringFunctional (mathematics)DistanceEmailSineComputer animation
Heegaard splittingDisk read-and-write headProjective planeTask (computing)Direction (geometry)Time zone1 (number)Different (Kate Ryan album)Right angleComputer animation
Event horizonLaptopTime zoneMereologyLattice (order)Multiplication signLimit (category theory)FeedbackQuicksortComputer animation
VideoconferencingTouchscreenSpacetimeMultiplication signBitSpecial unitary groupImpulse responseArithmetic meanChemical equationSpacetimeQuicksortCodeRule of inferenceHeegaard splittingTouchscreenTime zoneDifferent (Kate Ryan album)FeedbackMereologyDefault (computer science)Point (geometry)Computer configurationClosed setFocus (optics)SynchronizationInteractive televisionHydraulic jumpShared memoryProcess (computing)Akkumulator <Informatik>WritingWordHost Identity ProtocolSubstitute goodReal numberComputer animation
Game theoryMultiplication signQuicksortBitOffice suiteTask (computing)LaptopOnline chatQueue (abstract data type)Different (Kate Ryan album)Computer programmingCodePoint (geometry)Storage area networkInductive reasoningContext awarenessView (database)Remote procedure callLatent heatInteractive televisionNumberEndliche ModelltheorieState of matterHybrid computerIntegrated development environmentProcess (computing)1 (number)Type theoryVideoconferencingChemical equationInclusion mapCombinational logicVideo gameSource codeComputer animation
Computer configurationMereologyCellular automatonQuicksortLaptopCollaborationismMultiplication signOnline helpTelecommunicationEvent horizonCodeOffice suiteSelf-organizationTouchscreenBitContext awarenessDifferent (Kate Ryan album)Line (geometry)AirfoilOnline chatComputer animation
QuicksortTerm (mathematics)Context awarenessWebsiteVirtualizationMultiplication signTime zoneBitOpen setVideoconferencingWindowComputer animation
CASE <Informatik>TelecommunicationMultiplication signSet (mathematics)Computer animation
Computer animation
Transcript: English(auto-generated)
A few people coming in a moment. I will fill some time while we wait. So good morning, everyone, and welcome to NDC Day 2. Thank you for being up so bright and early and coming to attend. My name is Brendan Forster, and I come all the way from Australia. Yes, I will do silly Australian phrases for you
whenever you want, but that's not what I'm here for today. So if you guys are on Twitter or GitHub, my handle is shiftkey. I work at GitHub as a senior engineer, and I've been at GitHub for almost three years now. What was interesting about GitHub was it was my first real remote job, and there was a lot of learnings and a lot of mistakes that I've made along the way.
But ultimately, I really enjoy the ability to kind of work from wherever I feel like, and so that's kind of what I want to talk about today. So currently, GitHub itself is about 580 people. This is a little screenshot from one of our internal apps, and you can see that we are scattered around,
basically, various parts of the world. All up, we have, I think, technically 321 remote people, and we consider remote to be not based in San Francisco. So give or take, as people move around, it's probably about 55% of the company. So I'm one of those people. I've been in Europe for the last month doing a couple of talks and working,
but generally, I'm kind of based in Australia. So to kind of break the ice a little bit, I'm going back to a joke that was made a few months ago. The willing to relocate to San Francisco meme that was going around the place. Lots of people had a lot of fun with this, but the actual roots of this were in a joke. So information superhighway,
you know, the grand promise of the internet being able to kind of do whatever the hell you like, but we're still in this situation. People want for working tech companies to relocate to San Francisco, and my heart just breaks. This one here, I won't name the company that's being made fun of, but you guys can probably connect the dots.
And so once this happened, everyone kind of got into the groove of things and everyone had a lot of fun, and the whole point that was missed there that we didn't question why this is so. I do know some people at so-called company. Yes, it's fine. So anyway, this is a talk about my experiences
of being remote and all the stuff that we've learned being a remote team at GitHub. I have colleagues in the US and Europe, so we have iterated on a lot of stuff over the time, and ultimately we believe it's a successful way of doing work. But the three things I want to focus on today are how you would support remote workers in your company,
what's it like being a remote worker, how do you actually do your job well when you're not in the office, and distributed teams. Because of all the fun of time zones, there's a whole bunch of extra stuff that we've had to learn over the years, and I kind of want to share that stuff with you. So, lots of people have tried doing remote work,
and lots of people have told me stories about how things have failed. To give you an idea of how easy it is to fail at doing this stuff, I'm going to tell you a little anecdote. So here's a team of, let's say, four developers. They all work in the same sort of office. They share cubicles, open office plans sort of thing. They all talk to each other. They don't really need to kind of do any fancy tooling.
They get stuff done, and ultimately they're a happy team. But then a curve ball happens. Bob, one of the people on the team, is going to become a dad. And so he says, oh, I would like to kind of work from home and support my wife and new child. He goes up to the bosses and he says, can I do this? They're like, sure, go nuts, take your laptop home.
And so he does that. He moves out from the office, takes his gear home, and he's doing his job in the spare room at home. The big problem here is that nothing else changed about the situation aside from Bob relocating home. The normal day-to-day stuff that happens, the office is still there,
Bob is trying to fit in with the team, but ultimately he's not feeling like he's a member anymore. So he gets sad. He's concerned that the team doesn't know that he's actually trying to work really, really hard on stuff. He's also missing out on discussions and important decisions being made. He's not feeling like he's a part of the team anymore. Of course, over time, as these stuff,
things don't get resolved. Bob gets sadder, his morale is down. It's, yeah, it's a shitty spot to be in. Flip side of that is that the team don't hear much from Bob either. He's, you know, they believe he's around. They think he's doing stuff, but they don't really know. They get angry at Bob.
And ultimately, because of this communication breakdown, either the experiment fails or Bob quits or gets sacked. It's so easy for the stuff to fail because we assume that we don't actually need to change our habits. So rather than getting so sad about that, I kind of want to reframe the situation. So there's two phrases that I like to hear being mentioned when we talk about remote working.
So remote-friendly and remote-first. I like the latter term because it's actually really, really strong. It emphasizes that you know that this is a problem and you do really want to take steps to address it, whereas lots of companies will say that they are remote-friendly. So let me use carrot-and-stick analogies
to kind of go through how you would sell this stuff to your boss. So show of hands, who works in an open office plan? That is a lot. Awesome. How many of you like working in an open office? Okay, so about two-thirds of the hands went up and then I reckon about a half of those hands went up for actually liking it.
Yes, there are benefits to a open office plan, in particular, being able to kind of work alongside your colleagues and work synchronously on stuff. That stuff is very cool. But how many of you actually own a nice pair of noise-canceling headphones? There's my hands. So programmers hate open office plans because of distractions. I own a lovely pair of noise-canceling headphones
from my days as a consultant and I definitely use them a lot. You might think that it's not in a significant amount of time, but there are some surveys out there that kind of dig into this. So this was from a company called Get VoIP. They pulled together all these details about the downsides of open office plans and for me, the stats were just amazing.
So about a quarter of the day, you spend trying to get into the zone. For people like programmers and those people who are very detail-focused and needing to carry a lot of information in their head, you can see why they kind of hate open office plans. Distractions every three minutes. I do remember those sort of distractions coming up.
I didn't realize it was that bad, but ultimately, the last stat that I found down there, I really, really loved. So 75% of distractions are totally unrelated to your work. This is the sort of environment that we kind of tolerate. Let's put it that way.
There are also various monetary downsides to all these distractions, how you would scale that out. I think this is based on US data, but ultimately, we deal with these costs of doing work and we don't really question why we do that. So that's the stick side of things. Let's talk about the carrot.
So by enabling remote working as an option, there's all these tangible and intangible benefits that come up. People are actually more productive, people are happier and healthier, and there are benefits to the business as well. Everyone kind of assumes that because you're working remote, you're gonna be slacking off, but that's not really the case. So what sort of things do we have?
People who are working remote and have the ability to kind of work on interesting work will be more productive. For fields such as call centers or ones that you might not necessarily associate with working remote, they actually get more work done than their colleagues who are based on site. Morale also helps with remote work.
So people will work harder when they are happier, they'll work longer when they're happier. These things actually add up. But I also love the non-work-related benefits that come up when you are working remotely. Who likes a bit of an extra sleep-in on the weekend? That's it, that's it.
The fact that you're no longer commuting definitely opens up the whole bunch of your day for other things. I love that stat down below here that when people are commuting longer, things in their personal lives are impacted. The ability to kind of say like, you know, I'm no longer going to commute an hour and a half a day,
these things are a flow-on effect from not having to commute. Business side of things, it is kind of easy to quantify the ability for people who are working remote to save businesses money. This study comes up a fair bit. I'll get to that last one.
So less office space, less electricity costs, smaller office spaces. The ability for people to work remotely leads to lower absenteeism. You know, people are taking stress leave or taking significant time off work. That stuff goes down when you have a bit more of a flexible work routine.
Retention of staff also comes into this. Having the ability to work remotely is appealing. And you can also bring in new people by supplying this option. So this study, the last link there, was from Cisco's Internet Business Services Group. They did a study on working 50% of the time with 2,000 people across six or so countries,
and they found significant benefits. Like, there are these options out there, and we just kind of neglect them. So let's say that sales pitch worked with your bosses and they want to kind of dig into how you would support remote working. What sort of things do we need to think about?
So the first thing that I'd suggest thinking about is what gear you need to do to get your job done. For most of us who are programmers, it's fairly straightforward. You know, you need a laptop sort of thing. But there's also other things to keep in mind. Do you need to access work systems? Are they gonna be available outside the firewall? Are there specific processes like VPNs or something that you need to use?
If they're not there, we gotta talk to IT and ask, beg, grovel, whatever, for that access to do your job. What about if your devices get stolen? What's the process for that? Data sovereignty and things like that that come up. Hopefully you have the ability to remote wipe the device.
Like, these things are out there, but generally IT might not be such a fan of implementing it. And yes, I have dealt with a whole bunch of IT departments in the past who have been fairly conservative with their thoughts. Hopefully it's gotten a bit better since those last days, but ultimately it'd be nice to kind of have them come to the party.
So the other thing that is important when creating remote culture is the culture side. So when you're in the office and all working with each other and all this stuff, there's various things that happen which are rather cool. Beer o'clock is probably one of my favorite things because it's on a Friday.
Random discussions that come up, like all this stuff happens organically in the office. How do you go and recreate that in a virtual aspect? So, fun fact, if chat was not such a thing at GitHub, I probably would have thrown in remote work a long time ago. For us, everyone is in chat,
everyone is hanging out there doing work and not work. The ability to have everyone in one spot has been amazing for my sanity and just the ability to kind of feel part of the organization. And yes, you might think that people use it for slacking off at times. We have an Australia chat room that all the Aussies hang out in and no work gets done there.
Lots of inappropriate jokes, that sort of stuff. Yes, chat can be used for slacking off but that's part of the puzzle. The water cooler aspect of the classic office, you can recreate that in chat. I will also say that chat is not a replacement for email but I will have another rant about that in a little bit. So we use Slack at GitHub, we use Campfire before that.
I don't really care what stuff you use for chat but I wanted to call out that the client should be available on all the platforms so that everyone can be included. So we've set up Slack and we kind of just like
let people go off and organize themselves however they want. I wanted to call out, yep, I wanted to call out, these are the sort of rooms that we set up in chat. So for organizing projects and working together, we'll spin up specific rooms and all hang out in there. We'll also have social rooms for whatever hobbies or interests people have outside of work.
The region-based stuff is interesting. So we have support people who are scattered around the world. We have offices in Amsterdam and Tokyo and Colorado and we let those people organize themselves geographically. I mentioned before the Australia room, I hang out in that one despite not being in Australia that often.
I also wanted to call out private chat there. So there are times when you do need to have chats off to the side but for the most part I consider them to be in the minority of things. So the more information you are discussing publicly with people, the more that everyone can get onto the same page.
So the other cool thing about having chat plugged into or having everyone in chat is that we can integrate other systems. So this is a page from Slack's integrator sort of things just to give you an idea of what's there. So we have build systems. We have other sorts of pieces
of information flowing through our chat. Of course these can be noisy so I definitely recommend experimenting with it and trying stuff out. But we also set up specific rooms where the chat integration is off to the side. So humans and non-humans, like that's sort of the stuff that we do.
And if you've been living under a rock for the last couple of years, GitHub has had a project called Hubot going. Hubot is our little bit of a robot butler, let's put it that way. He sits in our chat rooms and we tell him to do stuff. The simplest way to kind of explain that is with this little demo. So this is my colleague Andrea asking Hubot,
where is everyone in this room? Because we are all scattered around the world, it's easier to ask Hubot than to ask everyone else. So the dot there is our token to tell Hubot, like this is a command you should be looking at. Hubot goes off, he checks some things and he returns with this lovely summary.
So he's found a few people who are in the room, further down the page, he's drawn us all on a graph. All this stuff was automated, all of the data was already there. We didn't have to do anything manually. So what's fun about this is that it plugs into my Foursquare account. So as I'm traveling around the world, I'm punching in coffee, conferences, whatever, that sort of stuff.
That then flows back to our internal systems and so Hubot then knows my most recent location. This stuff is really nice because it's, again, we don't have to think about it, stuff just works and people don't have to ask me where the hell I am. They just go and say, where is Shifke? So I really like Hubot as a concept
because we plug in everything into him. We let him do deployments of software. We let him set up infrastructure. We let him do silly little things like remember jokes. We have teams, other teams that stuff, build their own customizations, sales, HR, support, they all have Hubot integrations. Rather than having to do stuff manually or do stuff as a human,
we set that up so Hubot will do it and then everyone else can do it. So while I'm in here talking about Slack, I'm going to go off on a little bit of a tangent. So I've been familiar with chat and team chat for all my time at GitHub.
And as everyone has fallen more in love with Slack, there's been a theme of people falling out of love with Slack. They look at things like information overload, distractibility, and just the fact that you find yourself in there all the time. I don't believe that's a fault of Slack itself, but it's kind of like a fault of how you use Slack.
So if you've ever complained about having too much email, I think the same problems with email you will have with Slack. So I think this is like a discipline thing to manage and I'll give you some tips that I've learned from having to deal with Slack. So I think at this point I'm in about 20 different rooms on the GitHub Slack instance.
It's noisy, but ultimately, like, yeah, for the most part, I keep things simple. So important rooms that I follow, I focus on them. Everything else is just kind of thrown into the background. Remembering that chat is asynchronous, no matter if the person is actually online,
the ability to kind of just distract someone is definitely a thing. And people will leave Slack running all day, which is OK. But also knowing to kind of shut Slack off when you need to get some work done, I think definitely helps. I have to throw in some more GIFs. So the concept of the fire hose.
Lots of people who get started at GitHub will describe their first couple of weeks as drinking from the fire hose. It is totally true. There is a whole bunch of stuff going on that people will feel overwhelmed about. What does that mean? Beautiful. Yes, discipline and knowing when to shut things off and get work done, I think will help with managing this stuff.
Another little anecdote. I took a month off in Japan and I thought I'd disabled Slack completely. A notification got through to me and I just got angry because I was really in the mood for avoiding work. I had a chat with Slack support team and they were like, oh, we have this thing coming up, it's called Do Not Disturb.
I'm like, cool, when's it out? So it came out a couple of months later, but they have the ability to snooze your notifications for a period of time or my favorite feature is setting a time period. So midnight to 7 a.m., I disable all my notifications. That's good because there'll be a whole bunch of stuff happening in the US
and I will just get spammed overnight. So I switch that stuff off, I sleep really well. I also found this little nugget recently. Markwall is red, is available for Slack. Shift-escape and just move on with your life. I generally look at just like notifications that mention me or specific keywords
and for the most part, I will just close stuff out and just move on. It's okay to let Slack kind of just go into the background. So on top of chat, we use video conferencing stuff. The one that we use at the moment is called BlueJeans and so every GitHub person has a BlueJeans URL
that they can then share and do video calls. So this is me looking very grumpy at like 7 in the morning or whenever it was, having a chat with some of my colleagues. Marcus is in Sweden, Amy is in New Zealand at the time, Josh is in New York. So we're all kind of like up and about but ultimately we just kind of want to catch up and talk.
This is the point when we were doing like weekly hangouts around a certain project and so it was good to kind of just hang out on top of our regular chat. We also do things like, of course, one-to-ones with bosses sort of thing. We also have like book clubs and reading of academic papers. We do that stuff via video conferencing because the real-time aspect of it is really rather nice.
And the thing that I really like about the BlueJeans stuff is it doesn't require a login. So I can give this out to people who are outside of GitHub and they can participate without having any friction. Internally, we also do a whole bunch of recordings for events.
We have dedicated AV team who will stream out stuff that happens in the office and also record it. The benefits for this is that despite not being in the office or even in an appropriate time zone, I feel like I'm still part of the company because I can catch up with things after the fact.
We also do things like Q&A. So we run up a little thing called Commish. We can send questions in whether we are in the office or not and they will get fed through to whatever event is on now. Basically building out the stuff so that remote people can be part of the company is, I think, really important
to ensuring everyone is on the same page. The events that get published up will turn around in like a couple of hours sort of thing. So it's really fast and really helps. So this was like my first week at GitHub. I ran into this guy, Maddox, he did a little talk.
The fact that information is easily linkable, you know, the classic sort of hyperlink sort of stuff, means that things can be disseminated, shared around, discussed. If you're in a traditional sort of work environment, quite often you'll have, do I make a SharePoint joke here?
Sure, so your SharePoint server, things go in there and they don't necessarily come back out. Having everything driven from the website of things, I think, is really important. So Slack discussions can be linked to from GitHub issues. GitHub issues can be linked to from show notes for events. Having the stuff that we can kind of share around means that it's kind of available for everyone,
whether they are in the office or not. So I'm going to talk a bit here about the GitHub side. There's some interesting things that I think are interesting around how these guys, how we organize ourselves. So one of the things I look after at GitHub is the desktop app.
So this is the desktop team at GitHub. We structure things so that they're reasonably easy to understand and so you should be able to find the right team. So if you need something from the desktop team, you just mention it like that. And that's what it looks like inside a GitHub issue, this one was. So bold text indicates it's a valid team.
Someone can click on that and see the members of the team and the notification gets sent to us. Fairly straightforward. But we have a lot of teams in a GitHub. These are a few of the other teams that I follow. Let's put it that way. Technical support, Windows, the API side of things. We're allowed to kind of jump in and out of teams
that are relevant to our interests. I cover a fair bit of stuff around the Windows side, so being on the Windows team definitely helps. We don't have restrictions on what teams you can join. It's up to you to kind of opt in and out of that. The fun side of this is accessibility. There are all these teams that pop up around little niches
and so we can then pull them into specific issues. So rather than mentioning specific people on a team in an issue or a PR, we mention teams. So everyone who gets a notification can then jump in and help out. For teams that are scattered geographically, this is a great way to kind of speed up the process.
The other important thing when you mention a team is to give context so that I know whether I actually need to go into this issue or what you're expecting from me. Coming back to this original example here, it could be okay. I've obscured the context there for sanity. But ultimately, maybe the desktop team just needs a heads-up on this. Maybe there's a whole bunch of stuff that we need to do that isn't quite clear.
The context around when you kind of pull in another team, I think, is something important. All right, so we've talked about the tooling side of things. We've talked about getting the business on board.
Let's say that they're happy for you to go ahead. You've got the permission to go and work remotely. What happens next? So another gift I had to include. Getting started with the remote work does sound glamorous. The ability to work from home on the couch, not even having to wear pants.
No one's checking your desk when you're there at 9 a.m. The commute from the bed to the couch is fantastic. All of these things... Yeah, sorry. Rest development. They all sound very cool, but it's an easy trap to fall into. So this was a paper infographic that was published by the Office apps team.
Office 365 team. They were celebrating the way that their tools could be used everywhere. And for me, this kind of hit home a whole bunch of stuff that I have done around working remotely that are kind of bad. All this stuff around always being available, working weird hours,
destroying work-life balance and stuff. Technology enables us to do this. And so I'll show you the stuff that I've done that kind of lines up with this infographic. So that first one there. 19% of people have worked when going to the bathroom. I have not done this. There is just a line there that I can't cross. A third of people have worked to or from the commute.
Yes, I have done that. 47% of people have worked when they were on vacation. Yes, I have done that. 20% of parents have said they've worked at a kid's activity. I haven't done that, but that's because I don't have kids. 20% of people have worked when they've been out eating.
So dinner date, phone buzzers, someone gets it. I have done that, but that is definitely one of my pet peeves these days when people do that. Again, work-life balance separation, been there, done that. 44% of people have worked when watching TV. Yes, I have done that. 27% of people have worked when they've been in bed.
Yes, I've done that. All of these things can creep into your life when you have no boundaries between work and the rest of your life. And, of course, if these things continue to be unresolved, it ultimately leads to burnout. I had a nice little crash last year, let's put it that way.
It's absolutely shitty to deal with, but setting boundaries around work versus life definitely helps. So my first advice for people who are working remotely is to have a routine. Treat it like a normal day. You may not be going into the office, but still think about it in that way. Working from the couch in your pajamas is cool,
but it's not healthy, let's put it that way. Things like eating at your desk over lunch because it's going to shorten the day, don't do that. Actually take a proper lunch break, shut the laptop, and go somewhere else to eat. The cool thing about being able to work your own hours is that you will slack off. You'll do a bit of work here, a bit of work there,
and before you know it, it's 11 o'clock at night, and you don't seem to have done anything. If you're familiar with the Pomodoro technique of 25 minutes of work, 5 minutes of break, repeat, repeat, repeat, try something like that to structure your workday out. Hopefully you'll get a whole bunch more done by the end of the day, and you'll feel less inclined to come back and work in the evenings.
Again, another thing that I kind of was terrible at was having a decent place for work. So 2015, I kind of went nomadic and jumped around between conferences and traveling and all that sort of stuff, and I never really had a desk, so I would work from hotel rooms
or people's couches or things like that. Having a workspace that lets you get stuff done means that you have the space for work, and then you leave the space. So shout out to Troy. Is this your space now, Troy, or is it something else? Old house, cool.
So back when Troy was in Sydney, this was his workspace. It might look ostentatious, having four months and all that stuff, but Troy took some time out to invest in what he believes would be a productive space. I would definitely recommend doing the same. You also had a nice chair. I think that was being discussed. You're going to be there for a lot of the time each day.
Make it actually a nice space. The flip side of this working from home is that it's easy to get isolated. I was kind of fortunate living in Sydney and Melbourne that I had a lot of contacts in the local dev community, so it was easy to go out to user groups, got coworking spaces. Making sure that you kind of get out of the house and remain a functional member of society
is, I think, important. One more lucky gif in there. Jack Nicholson from The Shining. I know that mood. It's not great. No, no, it's not great being that character.
So we've gone through the remote side of things. We've gone through the tooling. Now we're looking at expanding out our plans for world domination. So distributed teams deal with time zone related issues on top of everything else.
So they're still remote, like they're not working in the same space, but ultimately they're a lot more distant. So there's things to kind of keep in mind that we've learned from our experiences around being a distributed team. So first thing up is being aware of time zones. People work when they feel productive.
People live in different time zones. Therefore, the overlap is not going to be 100% between you and someone else on your team. The fact that people work flexibly means that they can be hard to get to. This sounds like a recipe for disaster, right? No one gets anything done because no one's talking.
No, not so. So hopefully your team has a goal or some project that they're working on. Hopefully they have a bunch of tasks that you're all taking, contributing to. There are ways to kind of split things up so that then when people are working asynchronously that they can all head in the right direction.
So I have three time zones on my laptop in the corner. This covers the eight or so people at GitHub that I work with most days. Just knowing what time of day it is in that part of the world is, I think, rather important. So if I'm up in the morning and my colleague Phil is around,
it means it's like afternoon PST. So I can catch up with him on some stuff, but if he's not around, I'll go and do something else. So a quick note in there. Yes, my calendar had something on at two in the morning. I did not go to that meeting. Yeah. So with our team being distributed around the world,
there's two sort of distinctions. So the time when we overlap and then the time when we don't overlap. We call this, like, golden time because there's so much stuff that we can do when we're working together. We can bounce ideas around, we can get feedback on stuff, we can get reviews done, or we can just kind of talk.
This time is really, really valuable, but it's also kind of limited. And with us being scattered around the world, it does kind of feel like passing the baton in a relay race. So let's say... Come back to the example with Phil. Let's say that Phil and I are on at the same time.
Let's work together on something. So kind of the process that I'd recommend doing for this is keeping it simple, keeping it fast, keeping it brief. So if we're online at the same time, let's jump in and do something now. If we're not online at the same time, let's find a time slot that works for us. Morning Australia time is afternoon PST, roughly,
so that's generally like the sweet spot for catching up. Once we know we've got a time slot, let's actually use the tools and get things going. Sometimes chat is just good enough for talking about stuff. Other times, let's jump into screen sharing and run through some stuff.
But the goal here is to kind of keep things focused. Having things drag out is not the greatest, and it can kind of become a crutch for people if they are kind of dependent a lot on working synchronously. And of course, let's say we get some wins, we'll close it out, we'll celebrate, sort of thing, and then we'll kind of go back to our specific zones.
This sort of way means that we kind of like get the best of both worlds between working together and then working apart. Because for the most part and most of the day, working asynchronously is the default. Some people kind of like this, other people struggle with it for a time.
I love the fact that my work day is like split half and half. The mornings, I'll catch up a lot with the people in Europe and US, and then they'll kind of go off into their evenings and I'll have the afternoon to kind of work on my own. This is really nice because there's different things that I can do at different points of the day. The stuff that is a bit more meatier, complicated sort of things,
I'll do that when people aren't around. If I need to focus without distractions, I can do that stuff in the afternoon. If I have important questions and things I need to raise, I can do those in the morning. Having both options available means that I definitely think a bit more about how I structure my day, but it kind of means that I get to have a nice balance of both.
And of course, because we're all asynchronous, we do need to have a lot of initiative. So knowing what stuff needs to be done, what stuff is urgent versus what stuff is optional, that stuff really...
Yes, so knowing where to spend my time, I believe, is really important to the overall scenario. The team has a goal, they've got stuff they're working on, we know what the priorities are, we're all adults. Just, yeah, get stuff done.
One of the early things, early GitHub quotes was this thing called the tyranny of the sun. Because people are always working, whether it's because of time zones or because of the yowls that they keep, there's always something happening at work, and so there is this impulse to kind of be around and participate. Letting go of that, I think, was really important to my sanity,
let's put it that way. At one point, I was doing kind of a split day, I'd do some stuff in the morning, I'd have the afternoon off, and then I'd do the evening, do some more work there. It wasn't that sustainable, because I would kind of do work in the afternoon as well, and so then I'd have like a 12, 16-hour work day.
The fact that there are other people around, again, work-life balance goes to hell. So acknowledging it, I think, was a good first step. But generally, cutting up your work day into a simpler process, I think, was really good. The other sort of things that we do as a team,
we make sure to not mention people are less really important. So this is a little quote here. Because my handle name kind of gets mentioned, we space it out, and so then it doesn't get a notification. They're talking about me, but they don't really kind of need to pull me into this discussion. Lots of stuff will happen overnight, and when people are away, we'll pull in those discussions
into an issue or some other spot so that other people can catch up later. Another thing that I didn't put on here was code reviews. So we have a general rule to say no self-mergers
and no fast mergers. So because we're all scattered around the world, we want to give people a chance to give feedback on certain pull requests. So for things that are kind of controversial or big or significant, they will sit for like 24 hours, sort of thing, to give everyone a chance. The fact that we all have different time zones and we might not be able to get stuff immediately,
then kind of impacts how you guys work together. The other fun of being a distributed team is that we have little ways of kind of talking with each other. So the isolation of being a remote worker, the time zone differences, like all these things kind of conspire to attack morale,
let's put it that way. So we have this little internal phrase called real talk. I'm just going to talk candidly about this stuff. This is a tricky topic to talk about. It's a way for us to kind of just say, all right, guys, I'm not doing okay. Can I just talk about this stuff? Because there are times when you need to vent,
and when you are working remotely, work from home, the isolation can hurt. I do like the fact that if I'm having a bad day, I can just say, guys, I'm having a bad day. I'm taking some time off to kind of recharge. This stuff is nice because we get to be honest with each other. When things are good, that's good. When they're not so good, we kind of bring that stuff up.
Yes, the ability to kind of acknowledge this and take steps to address it rather than slogging on through the stuff that's there definitely helps. And, of course, us being a distributed team, we have a lot of time spent writing, whether it's chat issues, pull requests, GitHub,
that sort of stuff. There is an art, I think, to writing succinctly and, yeah, to writing succinctly. I think there are ways to inflame a situation by writing stuff and just shooting from the hip. I like that now, Drew.
The cultural differences between people can be exacerbated by just writing. I love to use Australian slang. I probably shouldn't in this stuff, but that stuff can confuse the writing and make situations unclear. And, of course, you can just write too many words
and waffle on, so the lovely TLDR summary in your issues can definitely help. Writing in a distributed team is so very important. Take time to think about the stuff that you're doing. Draft it up. If it's something that's controversial or tricky, put it down for a bit, go for a walk, take some air,
come back, do you still feel that way? No? Cool. Have another go at rewriting it. Taking your time with your writing, I think, is also important, because it means that you're a bit more thoughtful, but you're also taking time to ensure that the stuff that you say is meaningful. And, of course, we are a distributed team,
but we catch up every now and again. So one of my colleagues, Marcus, is on the booth this week. We caught up a few months ago. We were in San Francisco. This stuff is not a substitute for actual interactions. It's always nice for us to kind of catch up and do stuff that is not work-related.
So one of my examples here was back in March when we were in San Francisco. We spent the night just kind of playing games in the office. It was really cool because, A, we didn't do any work. B, some whiskey came out. And C, we just kind of did stuff that wasn't work-related. I definitely recommend if you guys are a distributed team
or you do find that path, make time to catch up, because those sort of bonds and friendships definitely help when you go back to your regular work. So I've got a bit more time up my sleeve, and I'm just going to summarize and do a little bit of a rant now. So the tools are so important to your team to ensure that they fit in.
I definitely recommend experimenting with tools and making sure that you find the right ones. We've talked about replacing the, or recreating the cultural experience using chat, video, AV stuff if you want to go really, really hardcore. These things can be used, and they can recreate the environment,
and yeah, it makes remote working a whole bunch more fun. And we've talked about how being a remote worker is not as glamorous as all the promotional material suggests. Treat it like an actual job. Make sure that you are disciplined about things,
and make sure you do unplug at the end of the day. The last thing there I think is really important, the colleagues that are alongside you, even though they aren't physically alongside you, are really important for this thing to succeed. There will be good times, there will be hard times, and knowing the person alongside you really well definitely helps.
Yeah. So the last time I did this talk, I had a lot of questions at the end. I know this is NDC, and it is infamous for being quiet. Let's put it that way. But do we have any questions?
I thought I'd get one. Yes! Yep. As a matter of fact, we are a distributed team, even when we are in the UK office.
Our stakeholders are 35% in the States. I find really hard at the beginning. I was asking if you find the same situation where I work in the afternoon, and I find something that I don't know I have to ask, and no one is going to be there to give me an answer until the next day if I'm working in my life.
And because we are a focused team, I can't really do anything else. What do you do? Okay, so the question was, let's say I get blocked by something in my workday, and there's no one going to be around for 12, 24 hours sort of thing.
What do you do? So for me, I've generally got a whole bunch of things on the go, like the number of tasks to do that sort of stuff. I find myself context switching. So let's say I'm waiting for a view for someone else, a review for a PR for someone else. I put that aside. I then pick up something else. Where you're blocked on something is definitely fascinating.
I think it's always, if it's appropriate, to ask if someone's around. If it's dependent on a team rather than a certain person, there might be someone else able to help. But the trick is, I think, is to not get bogged down in that sort of stuff. The fact that it might take 12 hours to get an answer, I'm okay with, because people will be back fairly soon.
It's not like I have to wait until the next business day sort of thing. Yeah, I definitely have things that are blocked. At one point, I had six different code reviews for stuff, just in the queue sort of thing. Keeping balls juggling, I think, was nice, but definitely when an important thing gets blocked,
I'd see if there was someone else that could help me. Mahesh. Yep. So the question was, do you have an induction for new people at GitHub? So we have two weeks of people coming to San Francisco
to kind of get set up with all the non-work-related stuff and to just get a feel for the place. We will have a mentor or a buddy there from their team for the first week to show them the ropes around the various sorts of things. So generally, the first week is mostly just all the getting set up.
And so then the second week is us actually kind of sitting down and getting stuff done. So kind of go, this is what the team's doing, blah, blah, blah, blah. So making sure that we're going to get a combination of the San Francisco experience and the headquarters experience, but also having someone on their team there to kind of show them the ropes. We're kind of trying to balance both,
because ultimately, when they go back, we want to make sure that they still feel like they're included. I found out, well, my onboarding week was two weeks long. I came back to Australia, and then we let a bunch of people go. That was not great for my morale, because I was new and I was getting straight into the remote sort of stuff. I was really worried that I would be next.
Yeah. Yeah.
So the question was, do you see personality types that like working remotely and distributed versus others that don't? I think there are some people who are extroverted, who feed off sort of the presence of other people. I think those people do struggle a bit with the remote stuff,
whereas like introverts definitely kind of, they get to control their interactions a bit more. I see that's kind of like probably the archetype that I'd see, but I know plenty of extroverts at GitHub that hang out. It's not necessarily straight down the middle sort of distinction.
Yes. Okay, so the question was, have you ever seen a team go from centralized to distributed? I have seen that work. It's been a specific team sort of thing versus like the whole company. It's a good way to kind of prove the thing out,
is to take a team and scatter them out. The guys at a company in Melbourne, they did distribute for a while, and it was okay for them, but so they kind of went to kind of a hybrid model sort of thing. So they've still got an office in Melbourne, and the team can work from wherever, but it's like 50% of the time sort of thing.
Like there are ways to kind of introduce this stuff and find out what fits for the people, rather than mandating like, everyone take your laptops and go home. I think like making sure the thing succeeds by doing it carefully is definitely important. Yeah. My team, not so much,
mostly because we haven't found a great tool. There was a tool that was done. Oh, sorry, the question. So pair programming, tools that have been good. I don't really have a good recommendation from that. Let's see if I can jump. Screen here I think was the one.
Didn't they get bought out by Slack, or am I thinking of something else? Yeah, okay. So yeah, screencoder was the one that a person up here recommended. I've not used it. I know some other people have used it, and they're like, it's okay sort of thing. Yeah. I think that's kind of one of the things that I do miss, but yeah, on the whole, there's other ways for us to kind of collaborate.
Yeah. Yes. So the question was, do you see issues with people who are, a situation where people are co-located and people are distributed? I definitely do see that stuff, because what you'll see is people will fall back on old habits,
discussing things in hallways and not discussing that stuff in chat. So a whole bunch of stuff will then be only visible to certain parts of the team, and it's then like the communication breakdown sort of stuff that happens. Getting people to kind of either summarize that stuff back in chat so that people see is tricky. It's easy for the people to kind of just turn around and say, oh, what do you think about so and so and so?
Like, and then that stuff gets lost. Making people work remotely at least part of the time I think would encourage people to kind of do that stuff. But it's, yeah, it's a tricky thing. So how do you think you can overcome it?
I think making everyone work remote a bit of the time at least so that they feel the same pain. I don't think it's about mandating that everyone should be remote, but like giving people the option, I think, and also getting them to feel a bit of empathy for those people who do work remote. I think just, yeah, awareness of these differences and the fact that it's easy to exclude people
when you're in that situation. Yeah.
Okay, so the question was along the lines of moving the technology people is one thing. Moving the rest of the company is also another thing.
I don't really see a distinction between the two. For some people in those traditional sort of teams like HR and sales sort of things, they do kind of prefer being in the office, but I think giving them the option to work remotely like a part of the time is actually really, really nice. So some, I'll bring up our AMP Sam office because Baz is down the front. Some of the sales people will say in the morning,
I'm not coming in, I'm working from home today. Just having that option I think is really, really nice. Selling that to the stakeholders is, if we're all running decent laptops and that sort of stuff, it then becomes a whole bunch easier to do. Again, probably newer companies versus more traditional companies, that sort of stuff.
Yeah, I think like technology people, it's an easier sell because of all the lovely distractions, but I think other parts of the organization would jump at it. Let's put it that way. Real quiet. A few minutes.
Yes. So the question was how much do I travel? It's rather atrocious, let's put it that way. I have a trip at looking after all my itinerary sort of stuff and for the last couple of years, I've been on the road for seven months of the year, for consecutive years. So it's crazy and I don't recommend it, but yeah.
Yeah.
Cool. So the question was when you use a lot of text-based chat, you miss a lot of the feelings and emotions behind things. I think the perfect foil to that is emoji. We definitely abuse emoji on GitHub, the website. We abuse emoji in Slack sort of things. Like throwing in that little extra context, like just a little smiley face, a troll face,
that sort of stuff, I think is a good way to telegraph emotion. But I think in terms of like people's writing, once you know fairly well what they're like, you can pick up on these cues where people are angry, sad, feeling a bit down. There is a lot that you can read from text, I think once you know the people that you work with really well.
Yeah. No. So the question was have you experimented with virtual windows? No, we have not. There's been a couple of times where we've had an open video conference for stuff.
So before we were doing the launch for GitHub desktop, we were just basically in a war room scenario, just hanging out, making sure everything was fine. So there were like ten of us in this room. It was a bit like the Brady Bunch, but full of nerds. We've done that sort of stuff because it was kind of good to bond and make sure that everything was there. But just as a general sort of day-to-day stuff, yeah, we don't. I'd love to kind of experiment with that, but time zones quite often just, yeah, don't make it as feasible.
Yeah. Yep.
I definitely hope that's not the case. So my onboarding experience was we went to a conference just before onboarding, and so I got to hang out with my team and then do the GitHub onboarding and then do that stuff. So ultimately it was like almost a month of like getting to know my team. I think in general like making sure that you check in with new people on the team
and make them feel welcome and included and all that sort of stuff. Yes, it can be isolating, and this comes through like communication breakdowns and everything. Yeah, it's tricky. A couple of minutes left. If you guys don't want to ask questions publicly,
I'll be hanging around. Otherwise, thank you for your time.