How we work asynchronously
Our secret to shipping lots while working remotely
Welcome to Product for Engineers, a newsletter created by PostHog for engineers and founders who want to build successful startups.
PostHog is a team of 38 people across 11 different countries. We’re entirely remote, and as we covered in our last issue, designed for speed. What’s fuelling this intercontinental race car? A little thing called asynchronous work.
Besides being difficult to pronounce, being asynchronous means people can work autonomously and on their own schedule, even if other teams members aren’t immediately available.
In the spirit of transparency (the value of which you’ll see soon), we’re taking the cover off our race car and sharing our not-so-secret strategies for working asynchronously.
This week’s theme is: How to successfully work asynchronously.
1. Transparency as a core value
Transparency is critical to successful async work.
This means, wherever possible, our handbook, strategy, roadmap, and work discussions are all open for anyone to see. It also means, internally, the executive team shares financials, updates on fundraising, board slides, and people decisions.
Each of these is often private and/or synchronous in other companies. Of course, some of our information or discussions are confidential, but as much as possible is shared as publicly as possible.
Transparency enables everyone to know what is going on with the company without synchronous communication. This creates autonomy and empowerment.
Further reading
How to run a transparent startup – James Hawkins
2. Context is king
It’s impossible to do good work without context. What are you building and, more importantly, why?
Our asynchronous culture is built on the short, intense synchronous time we spend together, such as our annual all-company offsite, small team offsites, in-person onboarding, and quarterly planning meetings.
These are opportunities to clarify:
Big roadmap plans, so we know far in advance what we want to build.
Quarterly goals, so small teams can share their specific plans.
Ownership, so everyone knows who is delivering those goals / projects.
We use our weekly Monday all-hands meeting to re-emphasize, update and scrutinize our goals, through a combination of announcements, team updates, and James’ topic of the day. Recent topics include how we build an enduring company, reviewing PostHog’s values, and how to balance planning vs. collaborating vs. shipping.
With this context, people are empowered to work async. Teams require less synchronous communication to get their work done throughout the week. Instead, they rely a lot on…
pssst… love writing code, startup swag, and free food? We’ve got something for you.
PostHog is cohosting a hackathon in San Francisco on December 2nd. Join us for a day of ✨ synchronous ✨ building, workshop sessions, and more.
3. Writing in public
To make good decisions about what they work on, people need access to the relevant context. In an async environment, this means:
Making it easy to find.
As much as possible, we document things so people can unblock themselves without asking for help from someone who could be offline or busy. Our priority list for this is:
Pull requests: Ship code if you can. This includes updating our public handbook and docs.
Issues: Clarifies task, requirements, and ownership in GitHub. Others can to give feedback and discuss. All-in-one place, searchable, and connected to code.
Slack: Nearly everything else happens in public channels. Announcements, updates, ideas, questions, and more all happen here.
We avoid private group chats, internal email threads, and docs in other locations. These make information harder to find.
4. Reduce work in progress
Another way we stay autonomous is by reducing work in progress. Async coordination is hard enough, imagine juggling 10 different projects while doing it. We prevent this with a few principles:
PRs should be doable in one day.
Start your day by responding to others’ review requests.
Merge whenever.
Ship behind a feature flag and test in production.
Each of these reduces the amount of context needed to get work shipped. This makes it less likely people need to communicate at all. They can spend their energy working rather than context juggling.
Further reading
Why we test in production (and you should too) – Ian Vanagas
5. Our request for comments process
Planning a big project impacting multiple teams?
Instead of a “stakeholder meeting,” we use a request for comments, AKA RFC. This process helps us publicly get feedback and make decisions on big projects. It is a core piece of async communication at PostHog that boils down to a written pull request with:
The problem
The recommendation
The decision
It includes all the context others need to ask questions and give feedback. Once done, the designated person makes (and owns) the decision. You can see examples of them on GitHub.
An RFC eliminates organizing a meeting with the “relevant stakeholders,” preparing and distributing background materials, doing presentations, and having live Q&A. All of this takes unnecessary time for everyone involved and is not async-friendly.
Side note: A hidden benefit of being async is that we spend basically zero time organizing meetings, which sucks up a shocking amount of time in most companies.
The benefits of async work
What do we get out of all this?
Nearly everyone is on a maker schedule. We have a lot of time to do our work and that enables us to ship a lot.
We are remote. We can hire the best people wherever they are. Working with a great team was one of the most common motivations in a recent internal survey.
Transparency builds trust, gets more user feedback, and is great marketing.
Written communication like our roadmap, goals, and feedback is clearer and better thought through than synchronous versions.
Autonomy and time for deep work help make PostHog a great place to work. This was another common motivation from the internal survey.
Mitigating the downsides of async
Earlier in PostHog’s life, we made the mistake of being too async. This created unclear direction and disconnect within teams which in turn caused unnecessary tension and burnout. We learned from this and now do a lot to prevent it.
We still do syncs, just less often than most companies. They include:
Standups every week or second day (depending on the team)
One-on-ones and ad-hoc Slack huddles.
In-person onboarding for new hires with their team.
Co-working and meeting up budgets.
One small team and one whole company offsite every year.
This helps build connections, energize, and align the team for our async to work the rest of the time.
Further reading
How to plan a killer company offsite in just 8 weeks – Grace McKenzie
Creating your asynchronous work toolkit
Inspired to become more async? Here are some actions you can take:
Be more transparent: This provides people with the context they need without having to sync.
Have a public roadmap and goals: Know what’s important and what others are working on.
Use an RFC: Cut the time you spend in meetings, enable async discussion, and have all the decision context in one place.
Use your website: Having a source of truth for processes. Making this easily editable by anyone. Get context out of people’s heads and into a place others can read it.
GitHub maximalism: Connect everything to the shipped code. Read how we use GitHub as our CMS.
Good reads for product engineers 📖
Five Ways to Address Complexity In Your Product – Casey Winters
when a simple product becomes too complex, users inevitably flow to another simple product instead. Casey Winters, an advisor and ex-Chief Product Officer at Eventbrite, shares ways to break this cycle.
7 types of difficult coworkers and how to deal with them –
How to analyze surveys with ChatGPT – Lior Neu-ner
A guide to using PostHog survey data in ChatGPT to quickly summarize results.
Metrics that cannot even be measured in retrospect – Jason Cohen
Some things are just really hard to measure. It’s useful to know what they are so you don’t waste time trying to over analyzing.
Words by Ian Vanagas, who scored 6/8 on Dictator or Tech Bro
Great summary, Ian! Big fan of using the RFC.