This is Joshua Wehner's archaic Blog

Working like a Hubber

GitHub’s Approach to Distributed Work as I Have Experienced It

When I told people I was joining GitHub, there was a familiar response from friends and colleagues: “tell us how they do it”. The general consensus outside of GitHub seems to be that a) distributed workforces are hard b) GitHub appears to do it in a way that “works” and c) no one outside GitHub really understands how they do it.

So, I thought I’d write a little about what I’m seeing at GitHub and why I think it works better than what I’ve seen elsewhere.


As of this writing, I’ve been “in the system” for about 9 weeks. I think there are things I’ve seen here that teams elsewhere could use (if they knew about – hence this document) but I think there are also things that we do that wouldn’t work (or wouldn’t work well) at any/every/most other places –

  • GitHub’s main product is a tool for distributed teams to collaborate on code. When we develop a new feature for the product, we enable it for Staff accounts long before we ship it to the “general population”. So, when we work this way, we are not just “dog fooding” – in the traditional sense of “gee, we’d better start using our own product” – we immediately get to work with the benefits of using our new feature ourselves. I mean, people here were using pull requests to build pull requests. It’s a bit meta, but if our workflow didn’t work, we’d already be building the tools to fix it.
  • A decision was made, at a very early stage, that they wanted to make GitHub a company that worked as a distributed workforce, for better or worse. They have deeply integrated this style of working into almost every aspect of “being GitHub” – and, at this point, they explicitly hire people who work this way. I suspect there’s maybe a chicken-and-egg problem – I can’t really be sure if this is the way we work because it works, or if it works because this is the way we work. However that shakes out, it might not be possible for an established organization to switch to any of the patterns we’re using – it’s possible it’s already too late for some of this to begin and take hold.

Mostly Obvious Background

As of right now, there are 211 Hubbers. There are 164 tagged as “remote” (ie, 77% of us have a home in a city that is not in SF). In SF right now there are 78 (36%) Hubbers (that’s a combination of residents at home and visitors abroad, so the two add up to >100%).

Once a year, the company brings everyone out to SF at the same time for “Summit”. This is, essentially, an all-company conference, not dissimilar to a higher-end Ruby event, like a RubyFringe or Nordic Ruby – there’s swag, there are lightning talks, there are fancy dinner parties, etc. (There used to be two summits a year, each a slightly different mood/focus, but the current discussion is going in the direction of only having one each year.)

Everyone is encouraged to come to HQ as often as practical (but keep in mind that even people who live in SF don’t necessarily work daily from HQ). Teams are encouraged (but not required) to organize “mini summits”, approximately quarterly. There are also organized Hack Houses and exotic Destinations, which are sort of like “opt-in retreats” (and might involve people you don’t regularly work with, per se).

So, while a lot of people here work remotely most of the time, there’s also a variety of outlets to meet up in person with other Hubbers. When a Hubber is speaking at a conference, they find another Hubber goes along as their “buddy”, so they aren’t wandering alone at the event.

I’d also like to point out that, with a few minor differences, everything I have seen here applies to everyone at GitHub. There’s no internal policy barrier where Developers or Designers are given special treatment. I mean, we make “is a Hubber” posts for every person we hire, not just the “techies”, and as far as I can tell, everything about the way the company works applies to everyone here.

I’d summarize the general guidelines for work here as something like: “work / discuss / decide in public, with a permalink, invite anyone to comment/collaborate, move on with it - repeat as needed”.

Everything has a URL

If there’s one thing that’s really strikingly different about the day-to-day work here, it’s that this company has created this “pro-actively pubilcize work/decisions with permalinks” style and managed to embed it deep into the fundamental company culture. A friend told me he once visited the old GitHub office and when friendly banter turned towards worky-things, he noticed the Hubbers became visibly uncomfortable, and only managed to relax when they were able to stop talking (out loud) and return to the chat room.

People here, at every level, have a powerful drive to share what they are thinking/deciding/working-on and invite discussion around it. There’s an enormous difference between “here’s a note from the boss explaining his decision” and “here’s a pull request someone started to discuss a new feature he’s asking for feedback on”. Not just the timing, but the tone: there’s generally a healthy attitude around discussions and tendency to treat ideas as equally valid regardless of source. That people here have an almost reflexive seeking of feedback is, in my experience, the rare piece that seems fairly unique about the way we operate.

In practical terms, in my experience: Emails are rare, Google docs are endangered species, Hangouts are unusual (and are often transcribed after for anyone who wasn’t involved). Campfire chats and GitHub notificataions are the most common communications channels. (More on this in a bit.)

Possibly related: when we build internal communication tools, people actually use them, for real, and not in a half-assed way. We have an “internal twitter”-type thing, but people actually use it (unlike some Yammer experiments I’ve seen elsewhere). We have an “internal blog” to announce other internal tools / less visible work, and people actually use it to triumphantly announce what they’ve been working on – even things like “Gave a talk” or “Shipped payroll for August”.

Sharing is baked in and contagious.

(Almost) Everything is a PR (or Issue)

Almost everything we do happens in a PR or Issue. Have a question about using company trademarks? Create a PR on the legal repository. Have a question for the communication team about an article? Put in a PR on the PR repository. Want to order a new MacBook? Send a PR to the gear repository. Want to order business cards? There’s a PR for that…

This enables the Notifications-based communication channel I mentioned above to work reasonably well, but mostly, I think it’s about having a long-lived host for the conversation. Emails are transient, chat transcripts are out there but are needles lurking in haystacks. PRs and Issues can be referenced, automatically linked to, watched/unwatched, closed and reopened, and new comments notify any interested parties. So there’s a record of the situation that’s relatively static (unlike email), but well-integrated with the rest of our tools (unlike Google docs) and can evolve as conversation happens via ongoing comments.

(Almost) Everything is Opt-in and You Can Opt-in to (Almost) Everything

Campfire, PRs and Issues are generally all public information, and I’ve already mentioned that the company culture actively promotes discussions. But what I’ve seen here is that the discussions are really open – anyone who’s interested is welcome and encouraged to contribute. It’s more like having a bunch of internally-open-sourced projects. Want to weigh in on the new office lighting system? Want to help with documentation? There’s basically no boundary to participating on anything internally.

This is one thing we do that everyone can and should copy right away: Instead of the mode where your teams are built around user access privileges, add some teams that are built around “tuning in to interesting topics”.

Examples: we have a JavaScript team, a finance team, a legal team, a performance team, etc. Building a new, JS-heavy feature in an obscure product with a small team and want some extra eyes on the code review? Mention the @github/js team and bring the interested parties to where you are. Working on integrating various services? Tag the effected teams. Wondering if there’s a way to make your new feature perform better? You see where this is going.

During onboarding, we are encouraged to follow along with things like pr, hiring, and legal, as a way of absorbing company background happenings. People follow along with topics that are interests or passions even if they aren’t things they’ve been explicitly hired to do, and helps to avoid the “missing watercooler” problem, where remote employees don’t have access to the same back-channels as on-site employees. Want to know more about front-end dev? Join the JS team and do some code review! Want to weigh in on obscure legal issues? Same answer!

One key seems to be that these teams are all opt-in, and that there are no real limits on what you opt into (other than your own attention span and desire to get work done). Opt-in seems to work better than opt-out. In opt-out systems, everything is overwhelming, so you set up filters to whisk away things until you have some sanity. Then, when someone actually wants to get your attention, they have to figure out how to break through the filters.

(Almost) Everything Works via Hubot

Every tech company I know has used Campfire and most of them have setup Hubot. But I’ve never seen anyone use Hubot the way GitHub does – here Hubot is not just funny images and mustaching, it has real power to do things, and people depend on it.

Hubot at GitHub is like having a shared, company-wide command-line. It can run CI, deploy to staging or production, scale dynos, read or change environment configuration settings, query and display graphs from graphite, etc.

Sure, there are non-Hubot interfaces to do these things, but with Hubot:

  • Everyone sees what command I used
  • Everyone sees the same results I see
  • And it’s automatically stored in the chat transcript

Using Hubot this way, our Campfire rooms are more like command centers, or virtual war rooms. Everyone has access to the same set of information – graphs, deploys, etc. – shared and available to the entire room by default. It’s stuff we use on a regular basis, but it really comes together in a crisis – everyone involved is on the same page, and thanks to the “opt-in” culture, any/everyone can get involved and pitch in. I haven’t really seen post-mortem documents created here, just internal posts that link to the beginning of the event in a chat transcript.

Aside: we also use Hubot as a way of reaching out to team members beyond the chatroom. When someone mentions me by my “@username”, Hubot checks if I’m in the room and, if I’m not, I’ll a get a message on my phone. Also, if we’re discussing a PR or Issue in chat, Hubot will post a comment linking back to the chat transcript.

Everybody Works on Whatever They Want to Work On and Somehow It Works

There’s a rumor outside the company that GitHub has no managers. On the inside, we prefer to say that everyone is a manager. Everyone is fully vested in making the company work, and, as much as ability and interest allows, you’re allowed (and encouraged) to work on the thing that you most want to work on.

I think everyone is surprised by how well this actually works, in practice. My personal theory is that this works as well as it does for two reasons:

  • Employees are, from day one, connected to a small(ish) team – so roles are small(ish), broad enough for comprehension but focused enough to get work done, and strong interpersonal ties move the team forward.
  • Our hiring is built around finding people who want to do the thing the company wants to see getting done – during interviews, I was frequently asked variations on: “if you had all the time and money in the world, what would you do?”

It isn’t a perfect process, but, in general, it seems to work: people here are often deliriously happy to be allowed to work on things that we could have asked them to do, but nobody had to ask.

Some Examples of This in Action

A team in the late stages on an amazing future product is thinking about possibly making it open source instead of a paid product. There’s a PR where they are discussing the merits of either approach. Along the way, the conversation turns into a discussion about larger company goals. There’s an early consensus, but the conversation has nine articulate participants from all over the “org chart” and takes three days to run it’s course.

Someone starts a PR on the gear repository. Their laptop is getting old, they provide the specs they’d like for the new one. First commenter: “they are rumored to be bumping this line of laptops in a few weeks, can you wait that long?” Second commenter: “I have a company laptop with these specs that I’m not using, want to have it until the upgrades?” This isn’t the IT Department (there isn’t one, yet), it’s just people talking.

The Support team was struggling, held a meeting, decided that weekends and evening shifts were needed to even out the workload and keep everyone happy. Then they built an internal app to visualize and maintain a schedule of who’s-working-when. No one was assigned to a work schedule and somehow it all worked out amicably.

My team recently, after a lengthy multi-channel chat decided to scrap a couple of months work and go in a very different direction for our project. Some of the team may even split off onto other projects for a bit, given the demands of the new focus. But no one seems bummed about the lost work, there’s been very little loss of velocity, we’re excitedly moving on to the next phase.


I’m only 9 weeks in, but I can already see where there are potential downsides to this approach:

  • It’s stressful – several people I’ve spoken to here compare it to consulting or freelancing, but with a more reliable paycheck. When I started freelancing, I loved that I could work whenever I wanted, take as much vacation as I wanted, etc., until I realized that no work got done unless work actually got done. Without a Big Mean Boss, I have to talk myself out of procrastinating and have no one to blame but myself if I get into trouble. (Well, that last bit isn’t entirely true: I’ve seen my team already [figuratively] jump onto grenades, push people to take more time away, etc. Good people help, but it’s ultimately still my decision as to how I manage my time.) It’s manageable, enjoyable even, but it’s not always easy.
  • Not everyone works well this way – a few non-Hubbers I know out there who I admire and respect, they’re excellent developers and designers, but I’m not sure they’d be happy in a company run this way. Some of them are senior people who’re looking for a job with an authoritative title. Some are just getting started or would otherwise prefer more guidance in what to work on and how to approach new problems And “lone wolf”-types would struggle, too – there’s a ton of team communication and shared responsibility. People that do well here are the types that seem to thrive in open source – driven, passionate, and open to collaboration with a wider, virtual team.


If you’re interested to learn more about the way GitHub works, here are a few other sources you might try:


Thanks for reading this! Also, thanks to Jonathan Hoyt, who provided extremely valuable editing, and has also written a bit about working at GitHub.

Permalink • Posted in: workPost a comment