Prior to the first day at GitHub, like any anxious developer would do, I read their engineering blog. Specifically, their well-known post on “How to communicate like a GitHub engineer” ↗.

I read the principles, nodded along, and thought to myself, “Sure, I know how to write an issue and use Slack. I got this.”

But then reality sets in. As a matter of fact, over the course of the last few months working at the company, I have learned the following survival skills and unspoken rules.

1. DMs are where knowledge goes to die

In all the companies I have worked at, the default mechanism to ask a question is to send a direct message (DMs) to the concerned individual. However, at GitHub, the default mechanism to ask a question is almost an anti-pattern.

If you ask me a question in a direct message, only the two of us benefit from the knowledge you are seeking to understand. However, if you ask it in a public slack channel, issue, or a discussion, the entire company benefits from it. It becomes searchable index material for the next developer who encounters the same issue six months from now. Default to public is not just a nice phrase to have on a wall; it’s a daily practice to avoid hoarding knowledge.

In the office setting, you can point at the screen. In the async world of GitHub, context is everything, and the hyperlink is your main weapon.

I learned very fast that you can’t just say, “that bug with…” You need to say, “the bug described in #4502, which comes from the PR #4498.” Every statement you make, every question you ask, and every proposal you make needs breadcrumbs. If you’re not cross-linking issues and PRs and internal documentation in your daily communication, you’re making your coworkers play detective.

3. Fewer calls, more focus

As you might expect, GitHub is a massive organization, and as such, everyone has their own playbook. The team I ended up in has shockingly few synchronous meetings, maybe two or three meetings a week at most.

We do not have Zoom or Teams meetings for the sake of having them. We save that precious live time for unblocking someone who’s really stuck or for raising the red flag early before something goes wrong. When you take away the constant distraction of these meetings, you’re left with massive chunks of uninterrupted time. And that’s where the real work happens.

4. Silence is a feature, not a bug

Coming from the fast-paced world of synchronous communication, the async world of GitHub took some getting used to. I’m in a timezone that’s 5 hours ahead of San Francisco, and I know that if I open up a PR or ask a question, I’m not going to get an immediate response.

First off, the lack of response was like being blocked, but eventually, one understands that the need to wait for a response is not a blocker, but a chance to switch context and pick up another thread. One gets used to detaching one’s productivity from the need to get a response, and the silence is used to do deep work.

5. Agile methodologies? Not exactly.

In almost all companies I have worked for, “Agile methodologies” has been the buzzword that has governed the way we discussed our work process. In my current team? We do not adhere to any such methodologies. No backlog for us! No tasks assigned to us in a sprint 😱.

Is this to say that there is chaos and everyone works in a silo? Far from it! It simply means that the entire process works because of the sole dependence on communication. Since there is no daily stand-up or planning session for you to be forced into giving any updates to the team, the system has been built around radical autonomy. You need the seniority to determine the most critical tasks that need attention and, more importantly, the discipline to inform the rest of the team about the areas you are focusing on. You do not get assigned any task; you need to determine the most impactful problem and inform everyone transparently in the open.

6. The Main Point

The GitHub blog has some great content, but the actual work environment at GitHub is a lot less polished than what you’d read about on their blog posts. You need to build up some muscle memory for over-communicating (leaving all of your thoughts out there for everyone to see), and treat your written word with the same level of care as you would your code.

To communicate better with your team, you don’t have to be at GitHub; just stop hiding all the context from each other through DMs, link everything so people can see it easily, and understand that writing is part of engineering.