How Our Engineering Team Communicates Asynchronously Through Writing

In early September 2021, I’d written this up with our engineering manager Mark in Threads, about how our team at WorkOS can use Threads (Meta!) for team communication. I’d meant for it to be a living onboarding doc for new engineers joining our team, which is fully distributed and async-first. Our asynchronous communication means our face-to-face time can be much more intentional.

I thought I’d share it for all the engineers, product managers, and anyone making product decisions who is also working in a distributed team growing fast. I’m presenting this verbatim, except I lightly edited a subhead and punctuation, and removed a link to an internal Thread. This is best read as a snapshot of how we use Threads as of September 2021; as I mention, we plan on updating it as we keep growing.

Product README Proposal

Background

At WorkOS we use Threads as a primary tool to make product (and many other) decisions asynchronously as an alternative to meetings, Slack and Email. Our aim in doing so is to get a number of advantages such as:

Asynchronous communication.

Meetings take time out of our day and can be a time sink as you add more people on to them. As we build across different time zones we have precious core hours that are shared and available for meetings.

Being presented with a problem in a meeting and being asked to come up with your best solution on the spot does not lead to our best decisions. Your first reaction is usually outdated.

Transparent decision-making.

If you keep meetings small you risk coming to decisions hidden from view; leading to opaque decision-making.

Leaving a record for those who come after us (and ourselves).

If you've worked at a company more than a few years old you might have asked the question "Why did they do it this way?" but the folks who did it are long gone. Decisions were made in meetings or hidden in some Google Doc. Threads allow us to leave a trail for the future.

This Threads README aims to propose some guidelines around how we use Threads at WorkOS. Nothing in this Thread is set in stone and is always open to feedback and change as we grow as a team and learn how we want to use this tool.

When to make a Thread

When does a proposal require making a Thread? As a general rule, if you have to ask, the answer is likely "Yes". You don't need a Thread for tiny fixes like fixing a bug or changing some copy, but even smaller features can be a bit more complicated than you might suspect at the start. Take the ✅ Adding Back Buttons to Dashboard for example. [internal link redacted.]

If you want the team to adopt a process in how we operate, if you're interested in making a change that impacts folks across the team, adding an npm package, these are all great things to document and solicit opinions on.

Our goal should be when someone joins WorkOS and asks "why do we do things this way?" we should be able to link them to a Thread.

Creating a Thread

Where to create Threads

For EPD (Engineering / Product / Design) related Threads we have three core forums for creating Threads:

• Product. If solving a problem or adding functionality has already been prioritized, put your proposal in the Product forum.
• Product Ideas. If you have an idea for WorkOS and you want to capture it feel free to open a Thread in Product Ideas. It's useful to capture ideas so we have a record of them and a place to discuss them. Remember that there's a lot of things we need to do and not all good ideas get prioritized in the near term (or ever).
• Engineering. For proposals that are specific to engineering (a specific technical solution, linter rules, style-guide changes, process changes).

Requesting responses

It's important to be transparent with what your needs as a proposer are. Threads has a tool to request a response from particular people you'd like feedback from and the ability to give a deadline for it.

While everyone will generally look through Threads, if you are requested as a responder you should take special care to come up to speed on and provide feedback on a proposal.

Make sure to include when you need a response to avoid becoming blocked on starting your project due to a lack of response.

What should I include in a Thread?

Creating a Thread doesn't always need to be a magnum opus. You should succinctly convey enough information to explain your proposal while keeping the attention of your audience. In general you should aim to touch upon the following topics if they are applicable:

• Background information
• Any relevant history or links to previous / related Threads
• Your core proposal
• Alternative solutions that you considered
• Open questions
• Particular feedback you are looking for from your audience

Conveying status

Until such time as Threads natively supports categorizing a status of Threads we've adopted the following emoji to display where in the pipeline a proposal is:

• 🗣 In Open Discussion. Most Threads should be opened with this. We're deciding if we want to move forward with this proposal or not.
• 🚧 In Development. We're actively working on implementing this proposal.
• ❄️ Icebox. We've decided this is a good idea but we are not actively working on this and it has not been prioritized.
• 🛑 Canceled. We have decided not to implement this proposal.
• ✅ Completed. We have completed implementing this proposal.

Coming to decisions

Historically at WorkOS we've talked about Type 1 (Irreversible) and Type 2 (Reversible) decisions.

Irreversible Decisions

In the case of a Type 1 Decision we'll want to have organization buy-in from the top (whether that is the CEO or a future relevant head of product or engineering). In the case of such a decision make sure to tag them as a requested response on your proposal and make it clear what you need from them to proceed. Type 1 Decisions are rarer and we want to add friction to the process of making them to make sure we do not rush into these decisions.

If a decision is reversible, we can make it fast and without perfect information. If a decision is irreversible, we had better slow down the decision-making process and ensure that we consider ample information and understand the problem as thoroughly as we can.

Reversible Decisions

When it comes to reversible decisions we've used two common frameworks:

• The proposer listens to feedback and decides if a proposal moves forward or not. This is the default process when outlining a new feature that's isolated in its impact.
• The proposer decides the wider team should weigh in and we utilize fist-to-five to see where the team stands and build consensus. Generally in this process we'd expect folks to at least move towards disagree and commit (3) before moving forward.

These are just some general strategies for coming to decisions for reversible decisions, but at the end of the day we'll work as a team to figure out how to best come to a decision for a certain proposal.

We should aim to move quickly on these types of decisions with the best information we have at the time.

Reversible decisions are not an excuse to act reckless or be ill-informed, but rather are a belief that we should adapt the frameworks of our decisions to the types of decisions we are making. Reversible decisions don’t need to be made the same way as irreversible decisions.

Handling Disagreements

Sometimes in a Thread we may have a back and forth and be unable to see eye to eye solely in the Thread. In these situations it's important to remember to a.) appreciate the art of thoughtful disagreement b.) be respectful of our coworkers, remember that we are focused on finding the best idea c.) remember that written text has no tone. If a conversation is becoming unproductive, we recommend scheduling a call to hash out the issue together. Bring the result of the discussion back to the Thread to capture it.

Completing Threads

If a proposal is accepted and built out, a Thread can be completed with a ✅ check mark. For any other outcome, leave a brief summary in a comment at the bottom of the Thread to summarize what decision was made on it. This will help keep a record of the final decision.

—

If this sounds similar to how you’d like to work, you can learn more about open opportunities listed here.