What makes something
‘GitHubby’.

After almost four years at GitHub, I’ve seen a consistent way of working + values here that transcends teams, products, and leaders. It’s hard to describe, but you know it when you see it. I’ve heard it called being “GitHubby.”

I created this doc to capture (my own fork of) the durable cultural characteristics that make GitHub special. These aren’t temporary trends or flavor-of-the-month processes. They’re the patterns I’ve seen persist across nearly four years at GitHub.

Inspired by The Zen of GitHub + other insights from @benbalter, and Lessons from GitHub by @swannysec.

#The pillars of GitHubby-ness

• 📚 We are all smart
• ❤️ Nerd with heart -> technical depth + empathy
• 🌎 Async-first humanity + respecting slow
• 🔗 Url-able truth -> transparency as infrastructure
• 👥 Open by default -> community as a core identity
• 🚢 Ship to learn -> Iteration over perfection
• ⚙️ Change is an opportunity to grow and re-focus
• 🔍 Focused curiosity

#📚 We are all smart

There is a scene in Zero Dark Thirty where a character calls someone smart, and the response is immediate: “We are all smart, Jeremy.”

This sentiment captures the baseline experience of working at GitHub. You are surrounded by people who are not just intelligent, many are experts in their area of responsibility (AOR). By default we assume + expect our peers to be experts within their AORs.

Operating this way changes how we work:

• Trust the expert: Believe in your peers’ ability to own their AORs.
• Strong opinions, loosely held: We bring our expertise to the table, but we balance it with the knowledge that others are experts, too. We challenge ideas, and we (attempt to) welcome having our own thinking challenged.
• Directness and good intentions: We appreciate direct conversations because they respect our time and intelligence. We strive to assume good intentions, but that has been an area for improvement in our culture.

The anti-pattern to this is that non-experts/performers within GitHub are often worked around instead of worked with.

#❤️ Nerd with heart -> technical depth + empathy

You don’t have to choose between being technically precise and deeply empathetic at GitHub. You’re expected to be both. Technical depth is only half the equation; it must be paired with heart.

This looks like:

• Precision matters: Whether you’re crafting a product spec, analyzing user feedback, debugging a race condition, or writing documentation, the details count. A thoughtful word choice can matter as much as a good piece of code.
• Listen before you build: Read the thread, search across repos, ask questions to relevant people. You’re solving problems for real people, and their opinions have value.
• Say what you mean: Skip the buzzwords. “We should sync up to ideate” becomes “Let’s talk about this sync because I don’t understand why we are even doing this work.”
• Credit costs nothing: When someone helps, say thanks. When you ship their idea, name them. It takes five seconds and matters more than you think.

#🌎 Async-first humanity + respecting flow

Your best work happens when you have uninterrupted time to focus. GitHubby means respecting that deep work requires blocks of time where you can get into flow state, and that your teammates exist across time zones with their own schedules.

Synchronous communication is an escalation path, not a default. A two-hour block of focus time isn’t the same as four 30-minute blocks scattered throughout your day. Protect your flow.

But async doesn’t mean cold. GitHubby is :sparkles: emoji, GIFs, and human warmth encoded in text. It’s professional without being formal, precise without being robotic.

#🔗 URL-able truth -> transparency as infrastructure

“If it doesn’t have a URL, it didn’t happen.”

GitHubby things have URLs not just for convenience, but as a philosophical commitment that every idea, decision, and artifact deserves a durable address in the universe.

This reflects a deeper belief: knowledge shared openly is valuable/impactful, while knowledge hoarded diminishes value/impact. When you work GitHubby, you can point to decisions, subscribe to updates, fork ideas, and build on what others have created.

Here’s the most GitHubby thing of all: this culture itself has a URL, accepts pull requests, and encourages you to fork your own interpretation.

This is an aspirational belief we often fall short of, yet has remained a core belief.

#👥 Open by default -> community as core identity

Your first instinct should be to work in the open, overcommunicate, and make work visible. This is rooted in the founding idea of open source + working in public. Open collaboration and work is the foundation of GitHub.

#🚢 Ship to learn -> iteration over perfection

“Demos, not memos.” Show what you built, get it in front of users, and learn from what happens next.

GitHubby isn’t about shipping perfect things. It’s about shipping things that teach you what perfect looks like. Most decisions are reversible. Most features can be improved. Most “final” designs get redesigned. So why wait?

You’ll be wrong. A lot. The question is whether you find out in six months of planning or six days of usage. When you discover you’re wrong, pivot fast. This faster cycle of learning from actual use (rather than theoretical guesses while planning) often results in better outcomes + impact. It validates your work through reality, not guesswork.

Here’s the tension: this isn’t permission to ship garbage. “Practicality beats purity” doesn’t mean “ship shit.” It means ship something that works but isn’t polished, then make it excellent through iteration, as you see through practice what is working (and what isn’t). Each release should be better than the last. Done and improving beats perfect and theoretical.

#⚙️ Change is an opportunity to grow and re-focus

Change is constant at GitHub. Like many fast-moving tech companies, we are always adapting to ensure our focus matches our top priorities. Priorities evolve, teams shift, leaders change, and structures adapt. At GitHub it happens often enough that we have an internal “When was the last reorg?” repository—a tongue-in-cheek tracker that illustrates how common this is.

While frequent change can feel daunting, long-term Hubbers re-frame it through a different lens: resilience. Instead of framing a reorganization as a disruption, many of us see it as a signal. It’s a mechanism for the organization to correct its course, and for you to do the same.

It means valuing being given the ability to:

• Re-align with impact: Use moments of transition to ensure your work maps directly to the company’s most critical investments.
• Focus on what matters: Shift your energy away from legacy projects and toward high-value initiatives that accelerate your career growth + compensation.

All that said, over the years GitHub has become (a bit) better at bringing work to existing teams, compared to reorging to achieve the same result.

#🔍 Focused curiosity

Hubbers are curious. Many contribute to open source, run side projects, or dive deep into whatever fascinates them. That curiosity shows up at work. People want to understand how things work and aren’t afraid to dig in.

But, with hundreds of millions of repositories and over 100 million developers on the platform -> you could spend forever being curious about everything. The most senior Hubbers I know are some of the most passionate and curious people I’ve ever met, yet they’ve mastered something crucial: knowing when to turn curiosity off.

Their curiosity is laser-focused on a combination of impact and passion. They go deep on what matters to their work and what energizes them personally. For everything else, they trust their peers to be the experts while staying focused on their own impact/passions.

#Putting GitHubby to action

#Some GitHubby litmus tests

Wondering if something you’re doing is GitHubby? Ask yourself these questions:

1. The URL Test: Can someone who wasn’t involved understand the context, decision, and rationale from a single link? Does this have a durable, searchable, discoverable home?
2. The Time Zone Test: Could someone in a completely different time zone participate meaningfully without synchronous communication? Have you made it easy for others to opt-in to context?
3. The Fork Test: Could someone take this and build on it, learn from it, or improve it? Can they submit a pull request?
4. The Feedback Test: Was input sought before the decision was made, allowing genuine collaboration? Did you consult and then decide, rather than decide and announce?
5. The Human Test: Would a peer/developer reading this feel respected, informed, and empowered rather than marketed to or talked down to? Is it conversational and authentic?
6. The Zen Test: Does it favor focus over features? Does it encourage flow? Is it logically awesome? Is anything possible?
7. The Visibility Test: Is the work visible? Can others discover it, subscribe to it, and understand its status and ownership?
8. The DRI Test: Is there a directly responsible individual who owns the outcome? Are responsibilities clear?

#Examples of GitHubby in the wild

Sometimes the best way to understand the culture is to see it in action. Here are a few moments that capture the spirit perfectly.

#The Copilot-Powered Furby

At GitHub Universe, Martin Woodward didn’t just give a talk—he hooked a vintage Furby up to GitHub Copilot. Why? Because he could. It was technically impressive, slightly ridiculous, and completely joyful. It perfectly embodied Nerd with Heart—taking serious technology and using it to make people smile.

#Open Sourcing How We Talk

Most companies keep their internal communication guidelines locked in a Google Doc. GitHub open sourced ours. By publishing “How GitHub Engineering Communicates” publicly, we turned our internal culture into a URL-able resource that others could fork, learn from, and improve. Thanks to @benbalter and @amatlack.

#Hackable Conference Badges

For GitHub Universe, we don’t just hand out plastic name tags. We give attendees badges like Badger 2040s, fully hackable, e-ink badges powered by Raspberry Pi.

#The Octolamp

Martin Woodward designed and open-sourced the Octolamp. It’s a 3D-printable, WiFi-enabled smart light compatible with Home Assistant, it includes full instructions for anyone to build their own.

#What GitHubby is not

• Not secretive: Hoarding information or having “you had to be there” moments
• Not (long-term) hero-driven: Success depending on one person rather than sustainable systems, any ‘heros’ should be temporary
• Not synchronous-first: Defaulting to meetings when async would work, or forcing synchronous interactions
• Not corporate-speak: Buzzwords over plain language, being inauthentic or formal
• Not pure without practicality: Dogmatic adherence to principles without pragmatism, practicality beats purity
• Not formal: Stiff, distant, or impersonal communication. We’re professional, not formal
• Not shipping to finish: Shipping without iterating and improving, or shipping slow things
• Not email-based: Using ineffective collaboration mediums that don’t capture and expose process
• Not committee-driven: “DRIs, not committees” for clear ownership and accountability
• Not invisible: Work happening without URLs + without ways for others to discover and participate
• Not blame-focused: Seeking to blame instead of a system to fix. Focus on learning, not punishment
• Not blocking: Creating hurdles that stop others from making progress. Non-blocking is better than blocking

#Key phrases that signal GitHubby thinking

If you hear these phrases, you’re in GitHubby territory:

#Further reading

• The Zen of GitHub: Ben Balter”s original articulation of GitHub’s taste
• Why Everything Should Have a URL: On the value of giving concepts URLs
• Why Async: Benefits of asynchronous communication + why we are async
• Leaders Show Their Work: On working in the open
• Meetings Are a Point of Escalation: When and why to meet synchronously
• How GitHub Engineering Communicates: Complete communication guide for Engineering
• Lessons from GitHub: Professional principles from 9+ years at GitHub Security written by @swannysec