Skip to main content

How we make decisions

At XMTP Labs we are default-asynchronous, including how we make decisions. With that in mind we have a couple of tools that we should make decisions with, depending on the circumstances.

NameWhat it's forUse this
Problem / Proposed Solution(s)Socializing simple decisionsP/PS Issue Template
RAPIDA tool for inclusive decision-makingRAPID Issue Template
RFC (Request for Comment)A way to get feedback or temperature check something you are investigatingRFC Issue Template or use the .md Template + a PR with label rfc 📄.

Note: Engineering-specific RFCs are handled in a separate track.

Why use tools for decision-making?​

  1. Using standard tools for making decisions makes it easier to document what's happening, who's doing it, and how it will be done, all without explicitly requiring face-to-face interaction.
  2. It helps the entire company gain ambient awareness around the decisions being made, and why.
  3. It establishes institutional knowledge by documenting why and how we made particular decisions.

Problem / Proposed Solution(s)​

Credit to Matt Mochary where he describes this tool in his book.

Problem / Proposed Solution(s) is a simple tool for socailizing an issue, and presenting some potential ways of solving it.

Most of the time that we present an issue, it should be done in writing. The write-up should include a description of the problem, and at least one proposed solution. It's ok if you don't know the answer. It's also ok if you are only mildly confident in your proposed solution. The purpose is to generate productive discussion and come up with the best path.

Sometimes it may be desireable to bring up problems and discuss them verbally. For example, we do this during our Weekly Kickoff meetings where we dig in on tensions. In these instances, it could be helpful to use a P/PS ahead of time to socialize a simple issue asynchronously, rather than waiting to get input at the next sync meeting.

What makes a good P/PS?​

A well-formed P/PS should be:

  • Short and easy: It must be lightweight and should take just a few minutes to write.
  • Bold and direct: Proposed solutions should be direct (e.g. "Do this…")
  • Focused on solutions: Consistent with our value of having bias towards action, don’t just shine light on the problem, propose a solution too.
  • Outline the options: Include the options you considered, the tradeoffs, and your recommendation.

Example P/PS​

  • Problem:
    • We have too many meetings. It’s cutting into employees’ ability to get real work done.
  • Proposed Solution(s):
    • Kill all recurring meetings
    • Have a no meeting day
    • Create friction to add a meeting (require that any new meeting invite includes an agenda and goals of the meeting)

How to start a P/PS​

  • Open up a GitHub Issue using the P/PS Issue Template
  • @ mention any relevant stakeholders in the issue to get their feedback
  • Once we've settled on one or more solutions, they should be opened up as GitHub issues, assigned to the responsible person, and listed within the original.

RAPID​

RAPID is a tool that was developed by Bain & Co

RAPIDs help us make complex decisions in an inclusive way by codifying whose input is required and whose agreement is necessary. Each person involved in a RAPID has a designated role, and must signal their agreement or disagreement with the decision(s), as well as provide their rationale.

RAPID is named after the steps in its workflow:

  • Recommend: One person
  • Agree: One to two people
  • Perform: The people who will need to take an active role in whatever the decision entails
  • Input: Anyone who is really relevant to the discussion who should add their thoughts
  • Decide: Only one person(!) and not someone who is already on the RAPID

What makes a good RAPID?​

A well-formed RAPID should have:

  • A clearly articulated problem
  • A well-defined recommendation
  • A specified set of steps to move forward

Example RAPID​

We adopted the use of RAPIDs by way of its own RAPID and it's a great first example of how they work.

How to start a RAPID​

  • Open up a GitHub Issue using the RAPID Issue Template
  • Add all of the individuals participating in the RAPID as assignees
    • As they make their contributions, remove them as an assignee
    • At the last step, only the Recommender and Decider should be assigned the issue

On the Agree role​

The Agreer is the person who is seconding the Recommender's proposal in order to put it to a vote. Therefore, it should be understood that the Recommender and the Agreer are both Yes votes at the outset of a RAPID proposal.

If you can't find someone to second your proposal, it's not ready to move forward as a RAPID. Discussion is great, but for ideas that only have a sole supporter an RFC is a better fit.

On the Decider role​

In most cases, the Recommender should be tagging either a founder as Decider, their direct manager, or a higher-ranking org leader -- someone who already has implicit veto power over the decision.

Especially as we grow, we'll find situations where leaders who have more company-level visibility/context need to veto proposals made by their teams. Leaders should be trusted to exercise that power carefully, and communicate these decisions well.

In the more unique case that the Recommender is one of the founders, they should probably just tag the other founder as the Decider. Anyone else who you tag won't have the implied veto that comes with rank, and thus isn't a fully empowered decider.

How does the timeline work?​

The primary goal is to stick to the "Decision made by" date. It is the Recommender's job to whip input prior to that date. So long as a majority of people have provided their input by the Decision date, the Decider has the discretion to move forward with the final call.

RFC​

An RFC is a way to "sound out" something that would be a meaningful change to an existing tool or process.

  • RFCs
    • define a problem in some detail
    • spell out how solution(s) may work
    • allow for our assumptions to be challenged, as well as explain why some alternatives considered aren't a good direction
    • can override previous RFCs when updating something
    • allow for follow up on whether the changes had the desired effect

For some additional detail check out @snormore's excellent language in his RFC for RFCs.

What makes a good RFC?​

Our RFC Issue Template sets this up really nicely, and makes it easy to just follow the instructions with each section.

Using labels on issues/PRs​

Every RFC should use the rfc 📄 label.

Additional labels such as rfc/draft, rfc/review, and rfc/complete help to describe the current state of the RFC.

On goals / non-goals​

One of the sections in our RFC template is reserved for goals and non-goals. The "non-goals" sections is useful for detailing things that the reader may perceive as a desired change, but that you aren't actually considering as in-scope at this time.

On Plan & Timeline​

This doesn't need to be perfect when it's in draft form, but MUST be included when the RFC is considered complete.

How to start an RFC​

When to use which tool​

RAPID vs. P/PS​

A decision warrants RAPID if input from multiple stakeholders is REQUIRED to proceed and agreement is REQUIRED from a decider.

Many decisions may be made through a well-formed P/PS instead: namely those where input from others is RECOMMENDED to proceed, and their agreement is OPTIONAL.

  • P/PS: input from others is RECOMMENDED to proceed; agreement is optional
  • RAPID: input from others is REQUIRED to proceed; agreement is REQUIRED from a decider.
  • RAPID is a tool that enforces inclusive decision-making. So if a decision seems likely to be controversial, or someone on the team may feel blindsided or try to revisit it if they found out about it after the fact, it should probably be a RAPID. If you find yourself thinking "so-and-so may not agree but we should probably just do X": RAPID. (Maybe even talk to so-and-so first.)
  • P/PS doesn't enforce inclusion, it's just a tool for socializing something before you do it. Maybe you get some input that improves your solution; maybe you get some input that changes your mind; maybe it's surprisingly controversial and you decide it's a RAPID; maybe nobody responds. "Anybody object before I YOLO this thing?": P/PS.

RAPID vs. RFC​

An RFC is best for times when you want to sound out an idea, and the steps to move forward with a solution may not be fully formed and require additional feedback.

A RAPID would be best for situations when the recommended solutions and execution path are well defined and require no additional exploration.

  • RFC: an idea is being explored and feedback is desired
  • RAPID: an idea is fully formed and its recommended solutions are well-defined

It's possible that an idea may begin its life as an RFC, with a RAPID later opened to implement the solutions initially proposed.

Language styleguide​

We should strive to use some consistent language conventions so that others reading our proposals or decisions can best understand their intentions.

Indicating requirement levels​

At XMTP Labs, we should adhere to the key words used in RFC-2119. Back in internet standards days, they came up with this consistent terminology for indicating requirement levels.

  • MUST
    • This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification.
  • MUST NOT
    • This phrase, or the phrase "SHALL NOT", mean that the definition is an absolute prohibition of the specification.
  • SHOULD
    • This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
  • SHOULD NOT
    • This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.
  • MAY
    • This word, or the adjective "OPTIONAL", mean that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.)