# Ben Balter

> Product, leadership, and showing your work

I'm Ben Balter, and I write here about product and engineering leadership, open source, and showing your work. I wrote Open and Async, the playbook for remote and distributed teams. My open source projects have hundreds of millions of downloads. Most recently I was Director of Hubber (Employee) Enablement at GitHub, where I owned the internal platform 4,000+ GitHubbers use to get their work done. Before that: Chief of Staff for Security, five years running trust and safety, 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.
* [About (Markdown)](https://ben.balter.com/about.md): Machine-readable Markdown version of Ben Balter's bio, ideal for parsing.
* [Resume](https://ben.balter.com/resume/): Resume for Ben Balter: product leader in trust and safety, platform security, and developer platforms; GitHub director and senior product manager; attorney and author of Open and Async.
* [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.

## Start Here

* [Why you should work asynchronously](https://ben.balter.com/2022/03/17/why-async/) ([Markdown](https://ben.balter.com/2022/03/17/why-async.md)): 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/) ([Markdown](https://ben.balter.com/2022/02/16/leaders-show-their-work.md)): Great leaders don't just communicate decisions. They explain how and why. Without that context, every decision sounds like "because I said so."
* [15 rules for communicating at GitHub](https://ben.balter.com/2014/11/06/rules-of-communicating-at-github/) ([Markdown](https://ben.balter.com/2014/11/06/rules-of-communicating-at-github.md)): How GitHub used issues and chat for async communication: fifteen rules that eliminate the 'you had to be there' problem in corporate workflows.
* [Interviewing or starting at GitHub? Read these first](https://ben.balter.com/2021/02/01/what-to-read-before-starting-or-interviewing-at-github/) ([Markdown](https://ben.balter.com/2021/02/01/what-to-read-before-starting-or-interviewing-at-github.md)): After over a decade at GitHub, here's what I'd read before interviewing or starting there: how GitHubbers write things down, work async, and ship.
* [How I manage GitHub notifications](https://ben.balter.com/2020/08/25/how-i-manage-github-notifications/) ([Markdown](https://ben.balter.com/2020/08/25/how-i-manage-github-notifications.md)): My system for staying on top of 200+ daily GitHub notifications without losing focus. Watch liberally, unsubscribe often, and triage by signal.
* [The Zen of GitHub](https://ben.balter.com/2015/08/12/the-zen-of-github/) ([Markdown](https://ben.balter.com/2015/08/12/the-zen-of-github.md)): Call it taste, culture, or zen — every organization has shared assumptions that guide decisions and resolve ambiguity in pursuit of its mission.

## Recent Blog Posts

* [It's pronounced JIF. The Open and Async audiobook is out.](https://ben.balter.com/2026/09/08/gif-or-jif-audiobook-both-ways/) ([Markdown](https://ben.balter.com/2026/09/08/gif-or-jif-audiobook-both-ways.md)): The Open and Async audiobook is out. It's read by a synthetic narrator who says 'jif,' correctly. For the hard-G crowd who insist that's heresy, I re-recorded an entire chapter in their (wrong) pronunciation and posted it free. One chapter the wrong way, or eleven and a half hours the right way.
* [Accessible by default: writing a book like software](https://ben.balter.com/2026/08/27/accessible-by-default/) ([Markdown](https://ben.balter.com/2026/08/27/accessible-by-default.md)): The ebook meets the Web Content Accessibility Guidelines (WCAG 2.1 Level AA) because the format wouldn't let me fake a heading and a browser audits every build, not because anyone scheduled a week for it. The parts Markdown can't check, like color contrast, axe-core catches under Playwright.
* [How I over-engineered my book](https://ben.balter.com/2026/08/17/how-i-over-engineered-my-book/) ([Markdown](https://ben.balter.com/2026/08/17/how-i-over-engineered-my-book.md)): My book has a linter, ~5,500 automated checks, and a Pandoc pipeline that rebuilds five formats (EPUB, Kindle, paperback ×2, and web) on every git push. For a book one person wrote. Here's how I built and published it the way I ship software.
* [Open and async on the Overcommitted podcast](https://ben.balter.com/2026/07/28/overcommitted-open-and-async/) ([Markdown](https://ben.balter.com/2026/07/28/overcommitted-open-and-async.md)): 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/) ([Markdown](https://ben.balter.com/2026/07/21/open-and-async.md)): 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/) ([Markdown](https://ben.balter.com/2026/07/14/work-loudly.md)): 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/) ([Markdown](https://ben.balter.com/2026/06/07/reorgs-happen.md)): 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/) ([Markdown](https://ben.balter.com/2026/05/31/ai-first-program-management.md)): AI-augmented program management is the natural evolution of async-first and engineering-inspired workflows — amplifying human judgment, not replacing it.
* [The brag doc](https://ben.balter.com/2026/04/27/the-brag-doc/) ([Markdown](https://ben.balter.com/2026/04/27/the-brag-doc.md)): Why you need a running record of your wins, and how to keep one without dying of embarrassment
* [How to one-on-one](https://ben.balter.com/2026/04/27/one-on-one-playbook/) ([Markdown](https://ben.balter.com/2026/04/27/one-on-one-playbook.md)): Most 1:1s waste your team's only protected synchronous time on status updates. Here's how to run ones worth showing up for.

## GitHub Culture

Understanding GitHub's unique culture and communication patterns:

* [Interviewing or starting at GitHub? Read these first](https://ben.balter.com/2021/02/01/what-to-read-before-starting-or-interviewing-at-github/): After over a decade at GitHub, here's what I'd read before interviewing or starting there: how GitHubbers write things down, work async, and ship.
  * [GitHub for non-developers: a beginner's guide](https://ben.balter.com/2023/03/02/github-for-non-technical-roles/): No coding required. A plain-English guide to GitHub issues, pull requests, Markdown, and notifications for product managers, designers, legal, and ops.
  * [15 rules for communicating at GitHub](https://ben.balter.com/2014/11/06/rules-of-communicating-at-github/): How GitHub used 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