What is an AoR at Asana?
In "How are Sprints and Episodes at Asana Structured And How do They Work"
(Dustin Moskovitz's answer to How are Sprints & Episodes at Asana structured and how do they work?) Dustin briefly mentions something called an AoR. Are these like OKRs, or are they something completely different?
(Dustin Moskovitz's answer to How are Sprints & Episodes at Asana structured and how do they work?) Dustin briefly mentions something called an AoR. Are these like OKRs, or are they something completely different?
1 Answer
Jack Lion Heart, Product Engineering @ Asana64 upvotes by Quora User, Trevor Bezdek, Marc Bodnick, (more)Loading...
At the core: Areas of Responsibility (AoRs) are a very simple system. You write down all the areas of your company and explicitly designate one person responsible for each.
There's now a comprehensive guide to AoRs up on the Asana Guide. It explains the goals of AoRs, how to create and assign them, and what kind of outcomes you can expect. Read it now:
Rethinking the org chart: Areas of Responsibility (AoRs)
== Previous Answer ==
AoRs are Areas of Responsibility, and they define much of what people are responsible for at Asana. We maintain a list in Asana of specific components of the company that we've explicitly assigned (actually, we maintain multiple lists -- we've started to break them up in to Eng Responsibilities, Design Responsibilities, ...). Justin is our Product lead, and Kelsey is our touch person for Visas. One designer is responsible for our Design Onboarding, while another maintains the Style Guide and Asana Design Principles. They're different from (O)KRs in that they are descriptive, rather than goal-oriented, and generally permanent. A KR at Asana might be "Hire 6 engineers in 3 months" whereas an AoR might be Engineer Sourcing or Offer Closing.
This is an intentional effort to spread responsibility broadly and outside of management. Managers and Program Leads are very important; they essentially have AoRs for their people and projects respectively. But if those were our only visible leadership roles, people would default to routing problems through managers and program leads, distracting the managers and underleveraging others.
The relationship between management and AoRs is fluid. Some AoRs blossom to receive dedicated teams over time, and the AoR owner sometimes becomes the team's manager. AoRs are infinitely divisible fractals, where the granularity drawn is proportional to the size of the company. Like how managers are encouraged to obsolete themselves, successful owners of growing AoRs distribute the responsibility entrusted to them, often by creating sub-AoRs. The variability of AoR size means that it's usually possible to find some component that's large and complex enough to help someone grow but still something they're currently capable of excelling at.
Having a highly visible system that's as flexible as AoRs allows people to become leaders along arbitrary dimensions. No matter what good behavior you want to encourage, you can write it down as an AoR and encourage someone to keep doing it (or to grow into it). The process of creating a list of AoRs adds structure to the team. Having the list around is helpful for new hires -- they can easily route their questions to the right person, and they get to know each person in the company a little better and a little faster.
This is our highest-level application of the DRI principle (see How well does Apple's Directly Responsible Individual (DRI) model work in practice?); if all else fails, responsibility falls to the owner of the Meta Lead AoR (that's Dustin). But we prefer that 99.9% of all bucks stop well earlier -- at the task level. You may have noticed that tasks in Asana can only have one assignee; that's the same principle at work.
There's now a comprehensive guide to AoRs up on the Asana Guide. It explains the goals of AoRs, how to create and assign them, and what kind of outcomes you can expect. Read it now:
Rethinking the org chart: Areas of Responsibility (AoRs)
== Previous Answer ==
AoRs are Areas of Responsibility, and they define much of what people are responsible for at Asana. We maintain a list in Asana of specific components of the company that we've explicitly assigned (actually, we maintain multiple lists -- we've started to break them up in to Eng Responsibilities, Design Responsibilities, ...). Justin is our Product lead, and Kelsey is our touch person for Visas. One designer is responsible for our Design Onboarding, while another maintains the Style Guide and Asana Design Principles. They're different from (O)KRs in that they are descriptive, rather than goal-oriented, and generally permanent. A KR at Asana might be "Hire 6 engineers in 3 months" whereas an AoR might be Engineer Sourcing or Offer Closing.
This is an intentional effort to spread responsibility broadly and outside of management. Managers and Program Leads are very important; they essentially have AoRs for their people and projects respectively. But if those were our only visible leadership roles, people would default to routing problems through managers and program leads, distracting the managers and underleveraging others.
The relationship between management and AoRs is fluid. Some AoRs blossom to receive dedicated teams over time, and the AoR owner sometimes becomes the team's manager. AoRs are infinitely divisible fractals, where the granularity drawn is proportional to the size of the company. Like how managers are encouraged to obsolete themselves, successful owners of growing AoRs distribute the responsibility entrusted to them, often by creating sub-AoRs. The variability of AoR size means that it's usually possible to find some component that's large and complex enough to help someone grow but still something they're currently capable of excelling at.
Having a highly visible system that's as flexible as AoRs allows people to become leaders along arbitrary dimensions. No matter what good behavior you want to encourage, you can write it down as an AoR and encourage someone to keep doing it (or to grow into it). The process of creating a list of AoRs adds structure to the team. Having the list around is helpful for new hires -- they can easily route their questions to the right person, and they get to know each person in the company a little better and a little faster.
This is our highest-level application of the DRI principle (see How well does Apple's Directly Responsible Individual (DRI) model work in practice?); if all else fails, responsibility falls to the owner of the Meta Lead AoR (that's Dustin). But we prefer that 99.9% of all bucks stop well earlier -- at the task level. You may have noticed that tasks in Asana can only have one assignee; that's the same principle at work.
Write an answer