I’m live blogging one of the morning keynotes at this year’s Devs Love Bacon conference. Coby Chapple of online developers’ forum, Github, is talking about Remote by Default: How Github Makes Working Remotely Not Suck.
As you may well know, I’m not a developer. I don’t even come near being one. But Mint CEO Cameron Price told me about Github a few years ago, and I’m interested in the way it works as a remote platform for its community: it’s a flexible working thing, and that all feeds into my interest in how technology enables us to work differently, the way we want to (see the Beach with Wifi blog for some examples).
So it’s nearly midday, and here’s Coby. Please keep refreshing this page for updates.
1206: Github is a tool to help developers work better, says Coby. So as you can tell from my accent, I’m not from San Francisco – I work in Northern Ireland.
So I’m going to start off talking about eggs – it’s Bacon, right? I get up every morning, I grab my boots (it’s Ireland – it rains a lot) and small dog, and walk down to my neighbour’s shed and grab some eggs. There’s an honesty box there and my neighbour trusts me to put the right money in it. I can get eggs whenever it suits me. It’s asynchronous, it’s cost-effective. I get to help out my neighbour. There’s a lot of trust. This is exactly how to make remote working work.
1210: Working remotely should be a first class experience. To pull this off, you have to change the way you think. You have to be constantly mindful of the conversations you have. Being remote has to become second nature. You can’t do it partially. You have to completely commit to it if you want it to work.
Essentially you’re offering people flexibility and autonomy. Many places say they want to hire great people and then go to micro manage the shit out of them. You want to become a sought after place to work. That gives you ability to become more diverse, and to adapt to change more easily – which means you become more competitive as a business.
There are some industries where remote isn’t possible and that’s fine. But in our industry it can work brilliantly, so that’s what we’re banking on. You always need a range of stuff – you need informal watercooler stuff as well as work processes. At Github we’ve come up with a range of tools that help us do this well.
1. Chat. We’ve use wildfire for a while. From the early days there were a lot of remote people in the company. In fact when Github started we didn’t have an office, everyone was remote. Chat makes everything visible. When I wake up in the morning, I can see a complete list of all the things that happened overnight. The goal is to put the tools into the conversation. No matter what’s happening, you can always ping someone who might be able to help out. Chat works on many different levels – formal and informal.
2. Team is anther app that helps us to communicate in formal and informal ways. It’s like an internal Twitter. People use it to update their location, and as an internal blog. One of the issues with remote working is when things aren’t visible to the company. There’s an internal blog where people can post what they’re working on, and ideas – even if they’re very basic. Lots of Github’s internal products started up this way.
3. We use Github a whole bunch, as you might imagine. And you can Google tons of stuff about how Github uses Github to build Github! All these conversations create a kind of social glue. We use github/toasts to celebrate any wins – people post photos of themselves pouring a drink. Obviously as a remote team it’s hard to celebrate together. Sometimes people get competitive about how weird their toasts can be. We’ve put them together to make an animated gif. This helps us celebrate as a company.
4. We run mini-summits and video chat remotely. Beer:30 is really popular – a series of Friday night informal chats about whatever people want. Beer:30s are held on a Friday in San Francisco – and they’re streamed so people can either watch live or download the next day. We tried scheduling Beer:30 at a more internationally-friendly time but it didn’t work. I like watching Beer:30s on a Monday – but I love that Friday night atmosphere.
5. Don’t shortcut your communications. It’s how you use the tools that matters. It’s not just the remote people who need to be good at this. Always remember who isn’t in the room.
6. Everything should have a url. The hardest thing is: every conversation, check yourself, and think is this conversation visible, how can we give it a url? When you’re remote, being able to pass links around is vital.
7. Open up your creative process: using asynchronous tools really helps Github to do this.
8. Show humanity in your words. Remember there’s a human on the other side. We use Emogi (?) a ton. You have to be good at getting your emotions across. Asynchronous does not mean that other people are always available. People have to learn to be patient. You need to make it ok for things to sit for a day or so while people take their time to respond.
9. Fight the urge to be a cargo cult. Tackle things from first principles. Create something that works for you and your team first. Presume you have blind spots.
10. It’s not always awesome. These things work for us at Github but they might not work for you – the key is iteration (as with all software). The things that work for you will change. Learn to be adaptable.
1234: Now questions…
Audience: How do you manage work/ life balance?
Coby: It’s really difficult to do but it takes practice – there’s no shortcut. You just get used to it.
Audience: We get impatient with things being in a wait state – how do you cope with that state? It’s hard to be productive.
Coby: We’ve started to do more of things like weekly radar charts – before, it was really disrputive. We’re trying to work better as small teams and surface the things that are blocking us within the teams. To be honest, there’s still huge room for improvement.
[There were a couple more questions but I missed them – anyway, great talk, even for a non-developer like me – Github seems to be a shining example of remote working and has lessons that all sorts of companies could learn from]