What do you think?
Rate this book
Open and Async: The collaborative software development playbook for remote and distributed teams
Working from home ≠ working remotely.
Your company survived the pandemic by shipping everyone a laptop, bolting Zoom onto existing workflows, and declaring victory. That wasn't remote work. That was office work in sweatpants — same meetings, same approval chains, same "quick sync" culture, just piped through a webcam.
Open and Async is the playbook for the teams that actually figured it out. Drawn from more than a decade at GitHub — the company that's been remote-first since before it was fashionable — it's an opinionated, battle-tested guide to the two practices that make distributed work succeed: radical transparency and asynchronous communication. Async is the operating system; remote is the hardware.
For managers: Build teams that ship without constant synchronous coordination. Create a documentation culture that scales across time zones. Retain your best people by respecting their time, their focus, and their intelligence — while advancing a career built on outcomes, not optics.
For individual contributors: Become visible, effective, and promotable without hallway politics or performative face time. Build a career on the strength of your work, not the luck of your seating chart.
Inside you'll learn:
• Why everything should have a URL
• How to treat meetings as escalation, not default
• How to measure impact over input
• Patterns for leading across time zones
• How to navigate resistance to change
• How to write decisions that outlive the meeting
• How to make the shift stick long after the novelty wears off
Stop digitizing the office. Start building something better.
Your company survived the pandemic by shipping everyone a laptop, bolting Zoom onto existing workflows, and declaring victory. That wasn't remote work. That was office work in sweatpants — same meetings, same approval chains, same "quick sync" culture, just piped through a webcam.
Open and Async is the playbook for the teams that actually figured it out. Drawn from more than a decade at GitHub — the company that's been remote-first since before it was fashionable — it's an opinionated, battle-tested guide to the two practices that make distributed work succeed: radical transparency and asynchronous communication. Async is the operating system; remote is the hardware.
For managers: Build teams that ship without constant synchronous coordination. Create a documentation culture that scales across time zones. Retain your best people by respecting their time, their focus, and their intelligence — while advancing a career built on outcomes, not optics.
For individual contributors: Become visible, effective, and promotable without hallway politics or performative face time. Build a career on the strength of your work, not the luck of your seating chart.
Inside you'll learn:
• Why everything should have a URL
• How to treat meetings as escalation, not default
• How to measure impact over input
• Patterns for leading across time zones
• How to navigate resistance to change
• How to write decisions that outlive the meeting
• How to make the shift stick long after the novelty wears off
Stop digitizing the office. Start building something better.
580 pages, Kindle Edition
Published July 21, 2026
About the author
Ben Balter
1 book2 followersBen Balter was Director of Hubber Enablement at GitHub, where he helped thousands of GitHubbers do their best remote work. He has spent the last decade trying to figure out how large engineering organizations actually work — and why the obvious answers are usually wrong.
Before that role, Ben led Technical Business Operations for Engineering, served as Chief of Staff for Security, and oversaw GitHub's enterprise offerings as a Staff Technical Program Manager. Earlier, in Trust and Safety, he shipped more than 500 features for a platform with over 100 million developers.
Ben was GitHub's first Government Evangelist and a member of the inaugural class of Presidential Innovation Fellows, where he helped draft parts of President Obama's Digital Strategy and Open Data Policy. A lawyer and technologist, he holds a J.D. and an M.B.A. from George Washington University. He writes at ben.balter.com.
Before that role, Ben led Technical Business Operations for Engineering, served as Chief of Staff for Security, and oversaw GitHub's enterprise offerings as a Staff Technical Program Manager. Earlier, in Trust and Safety, he shipped more than 500 features for a platform with over 100 million developers.
Ben was GitHub's first Government Evangelist and a member of the inaugural class of Presidential Innovation Fellows, where he helped draft parts of President Obama's Digital Strategy and Open Data Policy. A lawyer and technologist, he holds a J.D. and an M.B.A. from George Washington University. He writes at ben.balter.com.
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 7 of 7 reviews
Review of advance copy received from Author
TL;DR
There is a lot of wisdom earned through experience that the author lays out in this book. It’s dense with insights about how good company culture (and what that really means) drives the success of companies. The book is written for someone coming from a world where “productivity” means certain outdated things – you have to be in a specific place, at a specific time, with specific people. It’s becoming common knowledge that this isn’t true. Workplaces aren’t all there yet though. So books like this are necessary to act as the continued counterbalance to the traditional ideas of productivity that remain pervasive.
Things the book gets right
- If you’ve ever been at work and asked the question: How does anyone get anything done with all these meetings? This book might be for you. The answer is that some things can and should get done in meetings – personal 1:1 time, necessarily messy discussions or decision making – but other things require dedicated, unbroken, and focused time. Working asynchronously (one of the central ideas of the book) forces you to confront the questions centered on what individuals and teams are trying to accomplish and how, at the system and process level, they are going about it. The latter is often avoided.
- Early on there’s a section dedicated to defining some terms – remote-first, hybrid, distributed, and remote-friendly. This is a good orientation point for readers as these often don’t get talked about with enough precision. The lack of precision leads to these terms being used interchangeably, which then subtly undermines earnest attempts to rethink or evolve workplace standards.
- Talent is distributed around the world and if you want to access diverse talent, which you should, you will need to provide ways of working that facilitate distributed teams. Some of the workflows highlighted in the book give you a roadmap for how to think about attracting and retaining globally-distributed talent.
- The chapter “Impact over Input” is worth reading for its commentary challenging the concept that hours worked is what matters. And the chapter on developer happiness makes a great point that what leads to shareholder value is people working in ways that actually suit them:
This could even be generalized to happy employees make great products (or provide great services) and the result would still be happy customers and shareholders.
- The book really starts to hit its stride during the chapter “Working in the Open.” Just about every company would benefit from raising the risk tolerance of their employees. The modal employee doesn’t operate autonomously enough, nor do they carry sufficient risk tolerance. Telling everyone to simply “take more risks” isn’t effective when people don’t know how to do that. A great way to start building the risk-taking muscle is to follow the suggestions in this chapter, many of which boil down to creating different ways to encourage people to speak up when they notice problems, share work early and often, and document what’s been learned as the day-to-day execution happens. There are some good practical steps that people can take which will allow them to gradually build the confidence it takes to put themselves out there, which is characteristically what risk taking is about.
- Most companies I come across would say that their whole business “runs on Slack.” I go back and forth on whether this is a good or bad thing. The fact that it’s colloquially true though makes the section “Chat Responsibly” worth a read for anyone who spends time interacting with colleagues through it. There’s so much that people get wrong when they open Slack to communicate even the most basic of things, but no one ever teaches you how to use it well, or at all. Chat Responsibly is the first time I’ve seen practical guidelines codified in a single place.
More nuanced point
If your company culture does not promote transparency and openness, you should fight that. If your company culture does not encourage writing things down and instead defaults to meetings, you should fight or at least question that as well. The book makes the point that through a strong culture of writing and therefore making all past decisions legible across people, teams, and time you can reduce things like duplicated work and dead ends. You wouldn’t be faulted for wanting to avoid these at first glance. But doing work yourself, going down the dead ends and even duplicating another person's tasks can be how an individual builds the intuition and judgment that allows one to know that a dead end is in fact a dead end. Just because someone went down a path that didn’t bear fruit a year ago doesn’t mean the landscape hasn’t shifted enough that the same path wouldn’t lead to a better outcome now. This is especially true in the markets for technology and software products where things seemingly move at an eye-watering pace, and what was true a month ago is nearly irrelevant today. Point being: If there’s a noticeable and obvious lack of strong reasoning and clear thinking in your company, writing things down will help. At some point of writing it all down though, at some amount of writing and subsequent reading, you simply won’t learn as much as you could have by taking action and creating your own informational advantage. If true understanding is what you’re after, all those documents will only get you so far.
Overall
If nothing else, the book does a good job of giving people permission to think and act differently than their default organizational behaviors may indicate.
There is a lot of wisdom earned through experience that the author lays out in this book. It’s dense with insights about how good company culture (and what that really means) drives the success of companies. The book is written for someone coming from a world where “productivity” means certain outdated things – you have to be in a specific place, at a specific time, with specific people. It’s becoming common knowledge that this isn’t true. Workplaces aren’t all there yet though. So books like this are necessary to act as the continued counterbalance to the traditional ideas of productivity that remain pervasive.
Things the book gets right
- If you’ve ever been at work and asked the question: How does anyone get anything done with all these meetings? This book might be for you. The answer is that some things can and should get done in meetings – personal 1:1 time, necessarily messy discussions or decision making – but other things require dedicated, unbroken, and focused time. Working asynchronously (one of the central ideas of the book) forces you to confront the questions centered on what individuals and teams are trying to accomplish and how, at the system and process level, they are going about it. The latter is often avoided.
- Early on there’s a section dedicated to defining some terms – remote-first, hybrid, distributed, and remote-friendly. This is a good orientation point for readers as these often don’t get talked about with enough precision. The lack of precision leads to these terms being used interchangeably, which then subtly undermines earnest attempts to rethink or evolve workplace standards.
- Talent is distributed around the world and if you want to access diverse talent, which you should, you will need to provide ways of working that facilitate distributed teams. Some of the workflows highlighted in the book give you a roadmap for how to think about attracting and retaining globally-distributed talent.
- The chapter “Impact over Input” is worth reading for its commentary challenging the concept that hours worked is what matters. And the chapter on developer happiness makes a great point that what leads to shareholder value is people working in ways that actually suit them:
...happy developers make great software, great software makes happy customers, happy customers make happy shareholders
This could even be generalized to happy employees make great products (or provide great services) and the result would still be happy customers and shareholders.
- The book really starts to hit its stride during the chapter “Working in the Open.” Just about every company would benefit from raising the risk tolerance of their employees. The modal employee doesn’t operate autonomously enough, nor do they carry sufficient risk tolerance. Telling everyone to simply “take more risks” isn’t effective when people don’t know how to do that. A great way to start building the risk-taking muscle is to follow the suggestions in this chapter, many of which boil down to creating different ways to encourage people to speak up when they notice problems, share work early and often, and document what’s been learned as the day-to-day execution happens. There are some good practical steps that people can take which will allow them to gradually build the confidence it takes to put themselves out there, which is characteristically what risk taking is about.
- Most companies I come across would say that their whole business “runs on Slack.” I go back and forth on whether this is a good or bad thing. The fact that it’s colloquially true though makes the section “Chat Responsibly” worth a read for anyone who spends time interacting with colleagues through it. There’s so much that people get wrong when they open Slack to communicate even the most basic of things, but no one ever teaches you how to use it well, or at all. Chat Responsibly is the first time I’ve seen practical guidelines codified in a single place.
More nuanced point
If your company culture does not promote transparency and openness, you should fight that. If your company culture does not encourage writing things down and instead defaults to meetings, you should fight or at least question that as well. The book makes the point that through a strong culture of writing and therefore making all past decisions legible across people, teams, and time you can reduce things like duplicated work and dead ends. You wouldn’t be faulted for wanting to avoid these at first glance. But doing work yourself, going down the dead ends and even duplicating another person's tasks can be how an individual builds the intuition and judgment that allows one to know that a dead end is in fact a dead end. Just because someone went down a path that didn’t bear fruit a year ago doesn’t mean the landscape hasn’t shifted enough that the same path wouldn’t lead to a better outcome now. This is especially true in the markets for technology and software products where things seemingly move at an eye-watering pace, and what was true a month ago is nearly irrelevant today. Point being: If there’s a noticeable and obvious lack of strong reasoning and clear thinking in your company, writing things down will help. At some point of writing it all down though, at some amount of writing and subsequent reading, you simply won’t learn as much as you could have by taking action and creating your own informational advantage. If true understanding is what you’re after, all those documents will only get you so far.
Overall
If nothing else, the book does a good job of giving people permission to think and act differently than their default organizational behaviors may indicate.
July 21, 2026
Incredible guide for applying open source workflows and values to remote-first and distributed work!
This book was not what I expected. But I loved it! Here are my thoughts about what this book is not, what this book is, and why anyone serious about excellence in the age of remote work should read this book.
When I first met the author, Ben Balter, I found him to be one of those rare coworkers who always understood what I needed or wanted before I opened my mouth to explain anything. We were at the White House. It was 2012. Ben was one of the first Presidential Innovation Fellows. I led the White House's web development team. We were both wide-eyed with the potential for open source code, open data, and public APIs to improve government services. We created the White House’s GitHub account (https://github.com/whitehouse) and promoted new ways of working in government. Ben went on to work for GitHub and remained at the cutting edge, continuing to think deeply about how open source workflows can make professional work more excellent and more fulfilling for more contributors (employees), and thereby deliver better results for the businesses they serve. I remained in government creating new remote-first teams inside creaky old bureaucracies. Naturally, I expected Ben’s book to anticipate and answer many of my unarticulated questions about remote work. It did! But not the ones I expected.
I opened the book wanting to be able to recommend it to every government leader who is not yet convinced that all organizations need to figure out how to embrace “open and async”, “default to open”, and “need to share” (rather than “need to know”) cultures. This is not that book. It’s not for winning hearts and minds of people who do not already perceive the value of openness. It probably won’t change the minds of wrongheaded people who think spyware can enforce the quality of work done at home. And it assumes some familiarity with software development and open source projects, which many government employees do not have. Hopefully, Ben will address these in a sequel. In the meanwhile, I hope those rare govies working for digital teams or doing product development in government will give this a read. Because there are some real gems in the practical tactical recommendations in this book.
It turns out, the book Ben wrote is actually *exactly* what the title says it is: A software development playbook for remote and distributed teams. And what is so special and rare about it is the level of detail Ben provides, grounded in years of firsthand experience. It reminds me of the adage, ‘Amateurs talk strategy; professionals talk logistics.’ This is a book for professionals. It’s for people who believe in “open and async” and want to know how far they can take it. Most of us have not created or contributed to as many open source projects as Ben; most of us do not have employers as enthusiastic about these new ways of working as GitHub; and very few people have seen firsthand what it looks like to work in a place where these systems have been refined year-after-year for +10 years. In this book, Ben shows us.
Ben does not stop at high-level concepts like ‘everything should have a URL’, and then leave the hard work of figuring out implementation details to the reader. The book is full of specific examples. He describes each team, project, document, meeting, and employee having a URL. He describes how “give concepts URLs” was actually applied in GitHub’s in-house team app, service catalog, and product development process. And the book goes deep like this on an incredible breadth of topics.
For anyone who thinks deeply about how to build culture and cultivate excellence in remote-first and distributed teams, I highly recommend this book.
This book was not what I expected. But I loved it! Here are my thoughts about what this book is not, what this book is, and why anyone serious about excellence in the age of remote work should read this book.
When I first met the author, Ben Balter, I found him to be one of those rare coworkers who always understood what I needed or wanted before I opened my mouth to explain anything. We were at the White House. It was 2012. Ben was one of the first Presidential Innovation Fellows. I led the White House's web development team. We were both wide-eyed with the potential for open source code, open data, and public APIs to improve government services. We created the White House’s GitHub account (https://github.com/whitehouse) and promoted new ways of working in government. Ben went on to work for GitHub and remained at the cutting edge, continuing to think deeply about how open source workflows can make professional work more excellent and more fulfilling for more contributors (employees), and thereby deliver better results for the businesses they serve. I remained in government creating new remote-first teams inside creaky old bureaucracies. Naturally, I expected Ben’s book to anticipate and answer many of my unarticulated questions about remote work. It did! But not the ones I expected.
I opened the book wanting to be able to recommend it to every government leader who is not yet convinced that all organizations need to figure out how to embrace “open and async”, “default to open”, and “need to share” (rather than “need to know”) cultures. This is not that book. It’s not for winning hearts and minds of people who do not already perceive the value of openness. It probably won’t change the minds of wrongheaded people who think spyware can enforce the quality of work done at home. And it assumes some familiarity with software development and open source projects, which many government employees do not have. Hopefully, Ben will address these in a sequel. In the meanwhile, I hope those rare govies working for digital teams or doing product development in government will give this a read. Because there are some real gems in the practical tactical recommendations in this book.
It turns out, the book Ben wrote is actually *exactly* what the title says it is: A software development playbook for remote and distributed teams. And what is so special and rare about it is the level of detail Ben provides, grounded in years of firsthand experience. It reminds me of the adage, ‘Amateurs talk strategy; professionals talk logistics.’ This is a book for professionals. It’s for people who believe in “open and async” and want to know how far they can take it. Most of us have not created or contributed to as many open source projects as Ben; most of us do not have employers as enthusiastic about these new ways of working as GitHub; and very few people have seen firsthand what it looks like to work in a place where these systems have been refined year-after-year for +10 years. In this book, Ben shows us.
Ben does not stop at high-level concepts like ‘everything should have a URL’, and then leave the hard work of figuring out implementation details to the reader. The book is full of specific examples. He describes each team, project, document, meeting, and employee having a URL. He describes how “give concepts URLs” was actually applied in GitHub’s in-house team app, service catalog, and product development process. And the book goes deep like this on an incredible breadth of topics.
For anyone who thinks deeply about how to build culture and cultivate excellence in remote-first and distributed teams, I highly recommend this book.
July 21, 2026
The book I would love to read when I joined GitHub, or earlier when I started working remotely, or earlier when I started at the software industry. The book that every new Hubber should be given the very first day of onboarding.
It tells the origin of inner-source, how to build proprietary software the way open source software is built, bringing the practices that worked for people who never met in person, who doesn't speak the same language, who have few or no overlapping of working hours.
Then why not applying these concepts to company management? To any other activity you organize, say a conference? Ben does it applying his technical background, and I love all his metaphors, e.g. meetings are like synchronous blocking calls in code, or you're building the operating system for your team.
Ben makes a great work at identifying the core principles, which are condensed even on the title: Open and Async. Once you read the book, the 3-word title is a pointer to every concept on it, like the 3 first words of a song you've memorized, all makes sense now. And it works better because this is not dark magic. This is something you already do when contribute to open-source, when planning with friends (WhatsApp groups, rare calls, meetings for fun) and with tools you're already familiar with, so it feels so natural.
I'd enjoyed reading the examples and stories which are extracted from real GitHub own history, so nothing speculative there, just real stuff. Disclaimer: I work at GitHub since 2020 though I never worked close to Ben. I've still learnt and enjoyed so much from Ben's distilled experience. This is a playbook on running a company that, as a matter of fact, it's AI ready.
Ben glorifies my old motto: use commit message for the why, the code already says the what and the how, but Ben expands this principle by orders of magnitude to a system of communication. As a side effect, this sets up the org (any kind of org) for the AI, which will find all the documentation in a well structured way.
As a fan of pair programming, I use it very often in an async-first environment,ñ. Ben's thesis is not against pairing, but about not having to pair to make progress, about putting in place other mechanisms to avoid blocking, and then fallback or use or even enjoy pairing when it fits.
There are so many good quotes, but my favorites:
- Async is the operating system; remote is the hardware.
- Share demos, not memos. More prototypes than decks.
- Speak like a human: you can be professional without being formal.
- Chat is for now, issues are for later, email is for outsiders.
- Your hiring process is your culture.
- Without trust, transparency feels like surveillance. Openness without safety is just exposure.
- Open: The best answer is a URL.
- Open: The risk isn't that someone will question your decision. It's that no one will.
It tells the origin of inner-source, how to build proprietary software the way open source software is built, bringing the practices that worked for people who never met in person, who doesn't speak the same language, who have few or no overlapping of working hours.
Then why not applying these concepts to company management? To any other activity you organize, say a conference? Ben does it applying his technical background, and I love all his metaphors, e.g. meetings are like synchronous blocking calls in code, or you're building the operating system for your team.
Ben makes a great work at identifying the core principles, which are condensed even on the title: Open and Async. Once you read the book, the 3-word title is a pointer to every concept on it, like the 3 first words of a song you've memorized, all makes sense now. And it works better because this is not dark magic. This is something you already do when contribute to open-source, when planning with friends (WhatsApp groups, rare calls, meetings for fun) and with tools you're already familiar with, so it feels so natural.
I'd enjoyed reading the examples and stories which are extracted from real GitHub own history, so nothing speculative there, just real stuff. Disclaimer: I work at GitHub since 2020 though I never worked close to Ben. I've still learnt and enjoyed so much from Ben's distilled experience. This is a playbook on running a company that, as a matter of fact, it's AI ready.
Ben glorifies my old motto: use commit message for the why, the code already says the what and the how, but Ben expands this principle by orders of magnitude to a system of communication. As a side effect, this sets up the org (any kind of org) for the AI, which will find all the documentation in a well structured way.
As a fan of pair programming, I use it very often in an async-first environment,ñ. Ben's thesis is not against pairing, but about not having to pair to make progress, about putting in place other mechanisms to avoid blocking, and then fallback or use or even enjoy pairing when it fits.
There are so many good quotes, but my favorites:
- Async is the operating system; remote is the hardware.
- Share demos, not memos. More prototypes than decks.
- Speak like a human: you can be professional without being formal.
- Chat is for now, issues are for later, email is for outsiders.
- Your hiring process is your culture.
- Without trust, transparency feels like surveillance. Openness without safety is just exposure.
- Open: The best answer is a URL.
- Open: The risk isn't that someone will question your decision. It's that no one will.
July 21, 2026
Open and Async is the guidebook for the remote worker. While the idea of remote work didn't come out of the recent pandemic, the practice certainly became more appealing to some employers. Remote work comes in different shapes and sizes, and author Ben Balter effectively navigates them through best practices, things companies get wrong, and how to avoid them.
As one of the many members of the workforce that entered their first remote role in the last 6 years, I wish I'd had this book handy. Drawing on his experience working alongside early "Hubbers" at GitHub, Ben tackles the differences between remote, remote-first, and hybrid work styles that many of us get wrong. Through his own experiences, he clears up common misconceptions about working remotely and lays out effective practices for doing it well.
Whether you're an individual contributor or part of management, Open and Async is a must-read for remote workers. I look forward to using this as a reference throughout the rest of my career!
As one of the many members of the workforce that entered their first remote role in the last 6 years, I wish I'd had this book handy. Drawing on his experience working alongside early "Hubbers" at GitHub, Ben tackles the differences between remote, remote-first, and hybrid work styles that many of us get wrong. Through his own experiences, he clears up common misconceptions about working remotely and lays out effective practices for doing it well.
Whether you're an individual contributor or part of management, Open and Async is a must-read for remote workers. I look forward to using this as a reference throughout the rest of my career!
July 22, 2026
An extremely useful read for anyone who operates in a remote role in a company that has historically operated in-person.
The book helped me reframe a recent frustrating situation. I was at the tail end of leading a cross-departmental project and needed a decision from a stakeholder. They felt blindsided by the proposal; I felt blindsided that they were blindsided. I'd worked openly, documented decisions as they were made, and cc'd their team on progress. I had taken their silence as approval. Turns out I'd been communicating with collaborators but never stakeholders.
The attention this book pays to the intention behind that actions (and specifically the "The Rule of No Surprises" chapter) helped me to understand I'd never communicated how I was going to communicate. Not very open of me :-)
I'd bet other folks will also have similar, hopeful feelings about how they could be a better collaborator after a read.
The book helped me reframe a recent frustrating situation. I was at the tail end of leading a cross-departmental project and needed a decision from a stakeholder. They felt blindsided by the proposal; I felt blindsided that they were blindsided. I'd worked openly, documented decisions as they were made, and cc'd their team on progress. I had taken their silence as approval. Turns out I'd been communicating with collaborators but never stakeholders.
The attention this book pays to the intention behind that actions (and specifically the "The Rule of No Surprises" chapter) helped me to understand I'd never communicated how I was going to communicate. Not very open of me :-)
I'd bet other folks will also have similar, hopeful feelings about how they could be a better collaborator after a read.
July 21, 2026
The Essential Playbook for Building an Open, Async Company
Ben Balter’s Open and Async distills a decade of experience at GitHub—home to one of the most revolutionary startup cultures in modern history—into an essential playbook for modern leaders. Its most powerful lessons are remarkably practical. These simple habits for companies create clarity, accountability, and organizations that work well across teams, locations, and time zones. Most importantly, Balter shows how to build with sound fundamentals from the beginning—because doing it right the first time is far easier than trying to change a company’s culture later. A short, sharp, indispensable guide for anyone building or leading a modern organization.
Ben Balter’s Open and Async distills a decade of experience at GitHub—home to one of the most revolutionary startup cultures in modern history—into an essential playbook for modern leaders. Its most powerful lessons are remarkably practical. These simple habits for companies create clarity, accountability, and organizations that work well across teams, locations, and time zones. Most importantly, Balter shows how to build with sound fundamentals from the beginning—because doing it right the first time is far easier than trying to change a company’s culture later. A short, sharp, indispensable guide for anyone building or leading a modern organization.
Read
July 21, 2026Fantastic book, and one I enjoyed greatly; a thoughtful and considered work on the need for asynchronous work. Highly recommended
Displaying 1 - 7 of 7 reviews