# Ben Balter

> Engineering leadership, open source, and showing your work

I'm Ben Balter — I write here about engineering leadership, open source, and showing your work. I wrote Open & Async, the playbook for remote and distributed teams. My open source projects have hundreds of millions of downloads. I was the Director of Hubber Enablement at GitHub, where I helped thousands of GitHubbers do their best remote work. Before this role: Chief of Staff for Security, enterprise PM, and GitHub's first Government Evangelist. Before GitHub: attorney, Presidential Innovation Fellow, and member of the White House's first agile development team.

## About and Professional Information

* [About](https://ben.balter.com/about/): Learn more about Ben Balter's professional background, including his work at GitHub.
* [Resume](https://ben.balter.com/resume/): Resume for Ben Balter — former Director of Hubber Enablement at GitHub, attorney, open source advocate, and technology leader.
* [Resume (Markdown)](https://ben.balter.com/resume.md): Machine-readable Markdown version of Ben Balter's resume, ideal for parsing.
* [Contact](https://ben.balter.com/contact/): Contact information and social media links for Ben Balter.

## Recent Blog Posts

* [Open and async on the Overcommitted podcast](https://ben.balter.com/2026/07/28/overcommitted-open-and-async/): What makes a remote engineering team work isn't where people sit—it's how they communicate. A conversation on the Overcommitted podcast about async-first culture, decision durability, and the ideas behind Open and Async.
* [Open and Async: the remote-work playbook is out](https://ben.balter.com/2026/07/21/open-and-async/): Open and Async is the practical playbook for making remote and distributed work actually work—two habits, working in the open and communicating asynchronously, drawn from a decade of remote-first lessons at GitHub.
* [Work loudly](https://ben.balter.com/2026/07/14/work-loudly/): In an office, some of your visibility is free. Go remote and it drops to zero. Working loudly makes your impact visible as you do it—not after the fact in a status update nobody reads.
* [Reorgs happen](https://ben.balter.com/2026/06/07/reorgs-happen/): In thirteen years at GitHub I was part of 25 reorgs—almost one every six months. Reorgs are a constant in tech, not a crisis. Here's how to navigate them.
* [AI-first program management](https://ben.balter.com/2026/05/31/ai-first-program-management/): AI-augmented program management is the natural evolution of async-first and engineering-inspired workflows — amplifying human judgment, not replacing it.
* [How to one-on-one](https://ben.balter.com/2026/04/27/one-on-one-playbook/): Most 1:1s waste your team's only protected synchronous time on status updates. Here's how to run ones worth showing up for.
* [The brag doc](https://ben.balter.com/2026/04/27/the-brag-doc/): Why you need a running record of your wins—and how to keep one without dying of embarrassment
* [No agenda, no meeting](https://ben.balter.com/2026/04/06/no-agenda-no-meeting/): Announcing noagendanomeeting.net — a single-page site advocating that every meeting deserves an agenda, and most meetings deserve to be a document instead.
* [Agentic workflows and the future of code](https://ben.balter.com/2026/03/18/agentic-workflows/): AI coding agents aren't replacing developers — they're extending the transparency, code review, and collaboration patterns behind open source.
* [Thirteen years remote at GitHub: what works](https://ben.balter.com/2026/03/04/thirteen-years-at-github/): When I joined GitHub in 2013, I found a company that had rethought how work happens. Thirteen years later, those lessons are more relevant than ever.

## GitHub Culture

Understanding GitHub's unique culture and communication patterns:

* [What to read before starting (or interviewing) at GitHub](https://ben.balter.com/2021/02/01/what-to-read-before-starting-or-interviewing-at-github/): Your unofficial reading list for understanding GitHub's async-by-default culture, communication norms, and what it's actually like to be a GitHubber.
  * [Intro to GitHub for non-technical roles](https://ben.balter.com/2023/03/02/github-for-non-technical-roles/): GitHub isn't just for developers. A practical guide for non-technical roles to follow along, collaborate, and track work with confidence.
  * [15 rules for communicating at GitHub](https://ben.balter.com/2014/11/06/rules-of-communicating-at-github/): How GitHub uses issues and chat for async communication — fifteen rules that eliminate the 'you had to be there' problem in corporate workflows.
  * [The seven habits of highly effective GitHubbers](https://ben.balter.com/2016/09/13/seven-habits-of-highly-effective-githubbers/): Seven traits I've observed in successful GitHubbers over the years, from shipping early and often to the appreciation economy.
  * [Eight things I wish I knew my first week at GitHub](https://ben.balter.com/2016/10/31/eight-things-i-wish-i-knew-my-first-week-at-github/): Tips I share with every new GitHubber — from shipping something in your first two weeks to pushing through the inevitable overwhelm.
  * [Why everything should have a URL](https://ben.balter.com/2015/11/12/why-urls/): When knowledge lives in people's heads and inboxes, it doesn't scale. Giving decisions and processes URLs makes context discoverable, async, and opt-in.
  * [Why you should work asynchronously](https://ben.balter.com/2022/03/17/why-async/): Async is what makes remote work actually work. It produces better outcomes, improves work-life balance, and unlocks flow beyond Cold War-era workflows.
  * [Leaders show their work](https://ben.balter.com/2022/02/16/leaders-show-their-work/): Great leaders don't just communicate decisions—they explain how and why. Without that context, every decision sounds like "because I said so."
  * [Meetings are a point of escalation, not a starting point](https://ben.balter.com/2023/04/20/meetings-are-a-point-of-escalation/): Most meetings are just information downloads that could've been a doc. Treat them as an escalation based on complexity, not the default starting point.
  * [Seven ways to consistently ship great features](https://ben.balter.com/2017/05/23/seven-ways-to-consistently-ship-great-features/): The best developers don't just write code. They over-communicate, ship the smallest delta, and optimize for users over maintainability.
  * [Four characteristics of modern collaboration tools](https://ben.balter.com/2015/11/18/tools-to-empower-open-collaboration/): The best collaboration tools share four traits: open, linkable, asynchronous, and process-capturing. Are you working the way you'd like?
  * [Tools of the trade: How I communicate at GitHub (and why)](https://ben.balter.com/2020/08/14/tools-of-the-trade/): How I choose communication tools at GitHub, from issues to Slack and Zoom, and why the tool you pick matters as much as what you say.
  * [How I manage GitHub notifications](https://ben.balter.com/2020/08/25/how-i-manage-github-notifications/): My system for staying on top of 200+ daily GitHub notifications without losing focus. Watch liberally, unsubscribe often, and triage by signal.
  * [The six types of pull requests you see on GitHub](https://ben.balter.com/2015/12/08/types-of-pull-requests/): Not all pull requests are equal. Six distinct strategies for using pull requests on GitHub, from quick heads-ups to deep reviews.

And for specific roles:
  * [Twelve things a product manager does](https://ben.balter.com/2016/06/06/twelve-things-a-product-manager-does/): What does a product manager actually do all day? After six months of note-taking, here are 12 responsibilities from user advocacy to strategic thinking.
  * [Nine things a (technical) program manager does](https://ben.balter.com/2021/03/26/nine-things-a-technical-program-manager-does/): What a Technical Program Manager actually does day-to-day, from a Product Manager who found the responsibilities were already familiar.
  * [The seven things a corporate Chief of Staff does](https://ben.balter.com/2022/03/09/seven-things-a-corporate-chief-of-staff-does/): Seven core responsibilities that define the corporate Chief of Staff role, from tactical office management to strategic advising.
  * [Manage like an engineer](https://ben.balter.com/2023/01/10/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?

## Site Information

* [RSS Feed](https://ben.balter.com/feed.xml): Subscribe to all posts
* [Site Source Code](https://github.com/benbalter/benbalter.github.com): This site's source code on GitHub (Static site built with Astro)
* [Fine Print](https://ben.balter.com/fine-print/): Legal information and site policies