What to read before starting (or interviewing) at GitHub

Your first few weeks at any new company are an exercise in pattern matching—figuring out the unwritten rules, the communication norms, the things everyone “just knows” but nobody thought to write down. GitHub is no exception, except that we’ve been unusually intentional about writing those norms down (it’s kind of our thing).

Over the years, I’ve tried to capture what makes GitHub’s culture tick—how we communicate asynchronously, how we ship, and how we think about leadership. If you’re joining GitHub, preparing for an interview, or just curious about how a remote-first, async-by-default company actually operates day to day, consider this your unofficial reading list.

Culture, communication, and getting things done#

GitHub’s operating system runs on a few core principles: communicate in writing, work asynchronously, and show your work. If you’re coming from a more traditional, meeting-heavy, synchronous organization, the shift can feel disorienting at first—like switching from a monolith to microservices. The architecture is different, but once you internalize the patterns, everything clicks.

These posts cover those foundational patterns—the habits, tools, and mental models that help GitHubbers thrive.

• Intro to GitHub for non-technical roles — GitHub isn’t just for developers. Everything you need to follow along, collaborate, track work, and get started with confidence.
• 15 rules for communicating at GitHub — How GitHub uses asynchronous communication to eliminate the “you had to be there” aspect of most corporate workflows.
• The seven habits of highly effective GitHubbers — Traits I’ve observed in successful GitHubbers, from shipping early and often to contributing to the appreciation economy.
• Eight things I wish I knew my first week at GitHub — Tips I offer new employees, from shipping something in your first two weeks to knowing when the overwhelm hits.
• Why everything should have a URL — When knowledge lives in people’s heads and inboxes, it doesn’t scale. URLs make context discoverable, asynchronous, and opt-in.
• Why you should work asynchronously — Async is what makes remote work actually work. It produces better outcomes, improves work-life balance, and unlocks flow.
• Leaders show their work — Great leaders don’t just communicate what decision was made — they explain how and why.
• Meetings are a point of escalation, not a starting point — Most meetings are just information downloads that could’ve been a doc. Treat them as escalation, not the default.
• Seven ways to consistently ship great features — The best developers over-communicate, write features before code, ship the smallest delta possible, and optimize for users.
• Four characteristics of modern collaboration tools — Modern collaboration tools are open, linkable, asynchronous, and naturally capture process.
• Tools of the trade: How I communicate at GitHub (and why) — How I think about the tools we use to communicate, from issues and discussions to Slack, Zoom, and email.
• How I manage GitHub notifications — My system for staying on top of 200+ daily GitHub notifications without losing focus.
• The six types of pull requests you see on GitHub — Not all pull requests are created equal. Six distinct strategies for using pull requests to collaborate.

Role-specific guides#

The posts above apply broadly, but if you’re a Product Manager, Technical Program Manager, Chief of Staff, or Engineering Manager, you might be wondering what those roles look like in practice at a company where the defaults around hierarchy, process, and decision-making are a bit different from what you’re used to. These go deeper.

• Twelve things a product manager does — What does a product manager actually do all day? Twelve responsibilities from user advocacy to strategic thinking.
• Nine things a (technical) program manager does — What a Technical Program Manager actually does day-to-day, from a PM who transitioned into the role.
• The seven things a corporate Chief of Staff does — The Chief of Staff role is poorly understood. Seven core responsibilities that make it indispensable.
• Manage like an engineer — If issues, pull requests, and project boards are the best way to develop software, should they not also be the best way to manage it?

Keep going#

Want to go further? Check out the books that have significantly influenced my time at GitHub—the ones I most often recommend to colleagues looking to level up their thinking about culture, leadership, and collaboration.

A couple of caveats: these opinions are my own, and I’d encourage you to keep the publication date in mind as you read. GitHub (and I) have changed a lot since 2013, and as organizations grow and mature, cultures and communication patterns naturally evolve. That said, the underlying principles tend to be more durable than the specifics. If you have questions or want to compare notes, feel free to reach out.