What to read before starting (or interviewing) at GitHub

TL;DR: If you’re starting (or preparing for an interview) at GitHub, here are a few of my favorite posts to help you understand how GitHub works, its culture and communication patterns, and what it’s like to be a GitHubber.

3 minute read

Over the years I’ve written a number of posts about GitHub’s culture and communication patterns. If you’re joining (or preparing for an interview at) GitHub, here are some of my favorite posts that might help you understand how GitHub works and what it’s like to be a GitHubber:

Intro to GitHub for non-technical roles — GitHub isn’t just for software developers. If you’re in a non-technical role, you can use GitHub to follow along, collaborate with your team, track your work, and share information. This brief guide includes everything you need to know to get started confidently with GitHub.
15 rules for communicating at GitHub — Asynchronous communication through high-fidelity mediums like issues and chat eliminate the endemic “you had to be there” aspect of most corporate workflows, and reduces the need for a dedicated management class to capture, collect, and shuttle information back and forth between business units.
The seven habits of highly effective GitHubbers — GitHub has a unique work culture. Here are seven traits that I’ve observed in successful GitHubbers over the years that I think make GitHubbers more effective. Specifically, professional, but not formal; ship early, ship often; if you see something, say something; curiosity and self-improvement; always be willing to help; contribute to the appreciation economy; and honesty, integrity, and authenticity.
Eight things I wish I knew my first week at GitHub — A short list of tips and tricks I offer to new employees when they join GitHub. Specifically, ship something in your first two weeks; spend your first month learning how to learn and how we communicate; about one month in you’ll get overwhelmed; the challenge is in deciding what not to do; GitHub wants you to grow and learn; just do it; professional, not formal; and share your past experiences, but be prepared to unlearn things.
Why everything should have a URL — By naturally capturing and exposing process and sharing it as widely as is appropriate for the subject matter, URLs render organizational context time and location agnostic allowing knowledge to move more freely within an organization on an asynchronous, discoverable, and opt-in basis.
Why you should work asynchronously — Asynchronous work allows for remote work that’s enjoyable and that actually works. Async increases inclusivity, produces better outcomes faster, encourages discoverability and permanence of context, creates space for learning, shifts knowledge workers to higher value work, improves work-life balance, empowers distributed teams, and enables parallelization and flow.
Leaders show their work — Absent working within systems that naturally capture and expose process, transparency takes effort. Leaders should hold one another accountable for spending the additional cycles to show their work through communicating not only what decision was made, but also how the decision was made, and why.
Meetings are a point of escalation, not the starting point of a conversation — Default to transferring context asynchronously. Hold colleagues accountable for being async first. If you receive a meeting invite without context, an agenda, or a read-ahead doc, consider politely declining.
Seven ways to consistently ship great features — Developers that I see consistently shipping great, user-centric features over communicate; write features first, then code; get it in users’ hands, not on main; ship the smallest delta possible; appreciate that “Next iteration” doesn’t mean “never”; always open issues; and optimize for users.
Four characteristics of modern collaboration tools — Today, open-source-inspired collaboration tools are open, linkable, asynchronous, and naturally capture and expose process. Ask yourself if you’re working the way you’d like to work, or just the way everyone else does.
Tools of the trade: How I communicate at GitHub (and why) — How I think about the tools we use to communicate at GitHub across issues, projects, discussions, documentation, Google Docs, Slack, Zoom and in-person meetings, and email.
How I manage GitHub notifications — I use web notifications for everything but @mentions, which I have pushed to me via email. I subscribe to lots of repositories to ensure I don’t miss anything, but unsubscribe from any thread not immediately relevant to me to keep noise to a minimum. I also have a few tools I’ve built to customize GitHub notifications for the way I work.
The six types of pull requests you see on GitHub — Whether collaborating on code, data, or prose text, there are lots of different strategies for using pull requests on GitHub. Specifically, just a heads up, sanity check, work in progress (WIP), early feedback, line-by-line review, and pull request to a pull request.”

And if you’re a Product Manager, Technical Program Manager, Chief of Staff, or Engineering Manager:

Twelve things a product manager does — Product managers aren’t allowed to have excuses, serve as team captain and user advocate, prioritize and sequence, communicate, coordinate, and facilitate, solve for what the customer’s underlying needs, ensure the team ships v0.1 not v1.0, don’t confuse urgent or measurable with important, capture every idea in an issue backlog, conduct research and strategic thinking, and keep up with industry trends
Nine things a (technical) program manager does — Technical Program Managers are responsible for communication, coordination, and facilitation, capturing and tracking the work that needs to be done, identifying, analyzing, and mitigating program risk, reporting up and across, managing relationships, resolving conflict, driving consensus, boundaryless engagement, and doing what needs to be done.
The seven things a corporate Chief of Staff does — Chiefs of Staff manage the office of the CXO, improve organization effectiveness, solve problems without regard for organizational boundaries, manage the CXO’s portfolio of responsibilities, shape organizational strategy and culture, serve as trusted counsel and advisor to the CXO, and manage the CXO and the organization’s relationships and overall brand.
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 software development?

If you’re looking to learn even more about how GitHub works, it’s culture, and what it’s like to be a GitHubber, you can also check out some of the books that have significantly influenced my time at GitHub that I often recommend to others.

Of course, these opinions are my own, and please take the publication date in mind when reading. GitHub (and I) have changed a lot since 2013, and as organizations grow and mature, cultures and communication patterns naturally evolve. If you have any questions, feel free to reach out.

Originally published February 1, 2021 | View revision history

If you enjoyed this post, you might also enjoy:

Ben Balter is the Director of Engineering Operations and Culture at GitHub, the world’s largest software development platform. Previously, as Chief of Staff for Security, he managed the office of the Chief Security Officer, improving overall business effectiveness of the Security organization through portfolio management, strategy, planning, culture, and values. As a Staff Technical Program manager for Enterprise and Compliance, Ben managed GitHub’s on-premises and SaaS enterprise offerings, and as the Senior Product Manager overseeing the platform’s Trust and Safety efforts, Ben shipped more than 500 features in support of community management, privacy, compliance, content moderation, product security, platform health, and open source workflows to ensure the GitHub community and platform remained safe, secure, and welcoming for all software developers. Before joining GitHub’s Product team, Ben served as GitHub’s Government Evangelist, leading the efforts to encourage more than 2,000 government organizations across 75 countries to adopt open source philosophies for code, data, and policy development. More about the author →

This page is open source. Please help improve it.

Edit