The “tragedy of the commons” is that when several people share responsibility for an action or process, often that action doesn’t get done well, or at all.
The phrase comes from a story about The Commons, a shared grazing area between farmers. When one farmer’s flock grazes on the common land it reduces the quality of the land available for other farmers. Because people overlook this negative externality when deciding how many sheep to own, the result is an excessive number of sheep, and an un-grazable Common.
To prevent this from happening, we group tasks into categories and assign each category to one—and only one—person, the directly responsible individual (or DRI). These are our Areas of Responsibility (or AORs). Apple is famous for having pioneered AORs in Silicon Valley, but now most successful tech companies use this method.
We’ve created a listing of every possible function in the company. Next to each function, we list the responsible person. This is the AOR list. It serves as a company directory and ensures that no functions fall through the cracks. It should be updated as new functions arise or as responsibilities shift.
This, combined with our process documentation, ensures that there are no single points of failure.
Sample AORs
| AOR | DRI | Backup | Slack Channel |
|---|---|---|---|
| Develop cross-product roadmap | Andrew O'Neal | AlexMacCaw | |
| Manage QA team | Wei Zhu | Ben Stevenson | |
| Product Design | Hector Simpson | ||
| Manage designs and design approval | Andrew O'Neal | ||
| Signoff on final products | Andrew O'Neal | Alex MacCaw | |
| Product Management: X | Ashley Higgins | Andrew O'Neal | #x-support |
| Product Managment: API | Wei Zhu | Harlow Ward | #data |
| Product Management: Data | Wei Zhu | Harlow Ward | #data |
| Product Management: Connect | Jess Lam | Andrew O'Neal | #integrations-support |
| Product Management: HubSpot, Pardot, Marketo | Jess Lam | Andrew O'Neal | #integrations-support |
| Product Management: Salesforce | Jess Lam | Andrew O'Neal | #salesforce |
| Product Management: Pricing | Amit Vasudev | ||
| Product Support: Shirley Shaw | #support | ||
| Webhooks | Ben Stevenson | Wei Zhu | #data |
No single point of failure
A single point of failure is a function that one person performs when no one else has full knowledge of how that function works. If that person becomes sick or leaves the company, functionality suffers. A well-run company has no single point of failure. To create a team with no single points of failure, we do two things:
- Write down all processes. As soon as you or your team members find yourselves doing something for the second time, you should write down the steps of that process exactly (so you don’t have to explain the third time). Place these written processes in Notion.
- Cross-train a second person for each role. Map each function in the company (from the AORs) to a backup person. Have the backup person co-work with the primary until the backup knows how to perform the role. (Of course, having all of the processes already written down will vastly improve this training process, so have your team write down all the processes first.)