There are two schools of thought when it comes to managing teams: you can either manage against mistakes, or manage for success.
Managing against mistakes means putting one manager in charge of every little decision. An experienced team leader can act as a safeguard, but when everything requires approval from someone higher up, it slows projects down.
Managing for success, on the other hand, means giving authority and ownership to individual team members. Every employee is responsible for (and makes the final decisions about) a piece of each project.
That's the management model the leadership behind team communication app Asana has embraced: they distribute authority throughout their 110-person organization to promote trust, ownership, and quick decision making. It's a strategy they call "Areas of Responsibility."
Asana's Areas of Responsibility
Areas of Responsibility (known as AoRs around Asana) operate on the theory that ongoing team goals can be distributed around the company so that someone is always moving them forward. Individuals can take ownership of those AoRs and make decisions about how to improve a specific aspect of the product or the team.
Imagine a company whose sole purpose is to throw birthday parties. Picking and procuring the cake could be an AoR. The person responsible for the cake would consider feedback from their teammates and the client, but ultimately they would make decisions about the flavor, style, and size of cake. The team would trust the cake AoR leader to make the right call, without getting into lengthy debates.
Most companies would love to have an in-house cake expert, but Asana's AoRs are a bit more product focused.
Sam Goertler is a product manager at Asana who has has worked on the team's Android app and a site redesign. She has two AoRs: product simplicity and ongoing education for product managers. In her role as Asana's product simplicity guru, she oversees new features to make sure that they don't overcomplicate things for users. Her ongoing education responsibilities, on the other hand, has her arrange for guest speakers and dig up and share interesting trends in the world of product management.
AoRs make it easy for Asana to put a leader like Goertler in charge of aspects that they're passionate about, even when they aren't tied to their job title. And, as Kelsey Aroian of Asana's marketing team points out, the AoR philosophy is built into the very structure of Asana the product: you can't assign a task to more than one person.
"You really always need a point person who feels responsibility for getting a project over the finish line," she says. When you put more than one person in the driver's seat, it's going to result in a few arguments.
Along with ownership, the AoR system offers Asana employees six benefits:
Documentation
Expertise
Collaboration
Transparency
Data
Reflection
1. Document What Works, and What Falls Short
If you're unfamiliar with the service, Asana is a cloud-based task management app. It allows teams to see what everyone else is working on, and tasks can be assigned to individuals and attached to projects.
That's why the Asana team uses a public "Organization"—a shared task list all employees can see—within its own app to keep track of AoRs: it's a natural extension of the product, since AoRs are all about individuals leading projects and tasks for the whole team.
The "public" part of the equation is important, too. Aroian and Goertler find that when projects are documented out in the open, best practices emerge in an evolving way as a byproduct of what each employee learns throughout the process. Those best practices turn into documentation for the whole team to reference later.
For example, Asana regularly executes product launches. Though no two product launches are exactly the same, there are constants from project to project. Do's and hard-earned don'ts from past product launches inform later ones.
"I just managed my first launch for our new developer site," says Aroian, who owns AORs for platform and customer marketing. Remember: she's a marketer, not a project manager.
But instead of starting from scratch, Aroian was able to copy the task list from a previous product launch to use as a framework. Thanks to previous AoR leaders, Aroian knew where to start; she wouldn't fall into the same traps that her predecessors did. And because that task list had evolved over the many launches before this one, it reflected the company's lessons on the best ways to launch a new product.
As she read through the tasks that her launch template listed, she found some helpful warnings from past launches. One task: "Let the development team know the day of the launch, and the sorts of tickets that tend to pop up when a new site goes live."
That might not come to mind immediately for every marketing staffer at the beginning of a campaign, but AoRs set Aroian up for success.
2. Create a Network of In-House Experts
"Not only do I get to own a certain area of the product, but I know who to go to when I have questions about something that's outside of my domain," Goertler says.
The Asana product manager has several stories about how the transparency of AoRs improved work in the company. For example, when the team built the most recent iOS app, they built it from scratch. Toward the end of the project, they realized that they needed to build in event logging. In other words, gather information about what buttons users touched, when they touched them and how often, in order to better understand how people used the app.
Since it was a new app, new names would be going into the naming of events. But it would help, naturally, if they mostly lined up with other names used for similar events in other Asana products. Here's where AoRs came in: because everyone in the company can see who has what AoR, they were able to find the person on the data science team with the AoR for "events logging."
"It was really helpful to have this expert who was very familiar with our event naming on different platforms, so that once we launched we got meaningful data," Goertler says.
Here's another example: As time passes, people move around the company and get new AoRs. It can be tough for the support team to keep track of who important pieces of customer feedback should go to. Keeping AoRs visible to everyone makes this much easier since support can check who is managing a specific piece of the product on that day and pass the feedback directly to the right person.
In another scenario, design feedback might simply get filtered through the lead designer, where it could get slowed down or disappear in a busy person's inbox. This way, it goes straight to the person on the team closest to the issue.
3. Get Everyone Engaged, and Encourage Collaboration
The AoR model encourages initiative. If a team member sees something that's important but no one is working on, he or she can propose it as an AoR and take the lead on it if their supervisor agrees. Aroian says that this recently happened when one of her team members wanted to think more about sustainable practices at the company, and he was given a new Sustainability AoR.
The approach can also yield cross team collaboration in interesting ways. Aroian started in recruiting, but recently moved to the marketing team. Despite title changes, she's held on to the AoR for hackathons, because she wanted to keep working directly with the product and recruiting team on certain programs. This means that she maintains that bond with her old department, while working with her new team, which should help prevent siloing as the company grows.
Goertler said it also makes it possible for individuals to grow within the company in new ways. Traditionally, you know someone is making progress when they start overseeing people, she says. "There are some individual contributors who do an amazing job but aren't interested in a management path," she says. "They can still advance their career by taking on more and more important AoRs."
Because everyone knows exactly who is spearheading what, it's clear who is responsible for successes in an AoR when a team meets its goal.
4. Promote Transparency and Accountability
Aroian estimated that Asana has about 200 AoRs for a staff of 110. The fact that she was able to check that illustrates another point about the approach to work: when it's all tracked and organized in a transparent fashion, it gives everyone the power of knowing who is taking the lead on what.
"Making this information completely available to everyone really spreads out the accountability," Aroian says. If everyone knows what needs to get done, it's more likely that other people besides the managers have a chance of noticing if something is awry with a project.
Anyone at Asana can go in and look at all the tasks on any project and find out if they're getting checked off or not.
5. Back Your Progress with Useful Data
Asana also divides each year into three parts and sets up goals for every team to be met during those three periods of time (they call them "episodes"). Asana is big on clarity, so having these goals within finite periods makes it clear where everyone is headed.
Asana uses Looker, a data visualization app, to track progress toward an episode's goals. But that tracking didn't come right away. In an Asana blog post about business intelligence at the company, the engineering team points out that the first step to tracking progress is to figure out every possible kind of data available to you—the next step, they say, is not to immediately set up visualizations. Instead, give yourself time to get clarity about what you want clarity about. They argue that you need to give a team room to play with data so they can sort out what they want to know.
Once Asana achieved that clarity, they built data dashboards that are up all around the office. "I always want to know how my work is directly affecting our objectives," Aroian says.
6. Reflect on Your Results
Without reflection, it's impossible to sort out whether or not AoRs are defined correctly, and what work is yielding what outcomes.
The teams that understand the cause and effect within their work are the teams that take time to breathe. It's no accident that Asana is named after the word for "pose" in yoga, where breath is the core of the discipline. Taking time to breathe, to pause and reflect, is built into the calendar of the company, as shown in the above data example. It also enables teams to build the sort of templates that Aroian found so valuable as she began her first product launch.
If you take time to look back at work, you can remember the things you did that weren't in your plan but proved useful as well as the things you wish had been in your plan. These tasks can be documented in a template for the next time.
Try AoRs With Your Team
If your team wants to implement Areas of Responsibility, here are some action items to get it started:
Divvy Up The Work
Break your teams work up into projects and, as needed, break those projects into areas of responsibility. Who is working on what pieces? Who should take point?
Decide Who Holds Authority
Have a conversation about what it means to shift decision making authority over an AoR to the person it's assigned to. Supervisors should challenge themselves to let go of authority here in favor of empowering teams to make the right call, embracing efficiency and innovation and accepting that some mistakes will inevitably be made.
If it turns out that more than one person is taking point on an area, begin that conversation about who should take the lead. Ground this in an understanding that this is a more pragmatic approach and doesn't reflect one person being superior at the task.
Make Your AoRs Public Knowledge
Post these Areas of Responsibility in some kind of document that everyone on the team can access. As you move to your team's Minimum Viable Product of AoRs, a shared folder of Google Docs could be good enough. Also, make sure it's someone's Area of Responsibility to make sure everything gets turned into a documented AoR.
Choose Measurements for Your Goals
Agree on how you're going to evaluate the success of each person's AoRs, and set a timeline to assess their work against their goals. Make sure that each employee has a say in how their AoRs will be evaluated.
Contemplate Your Results
At the tail end of your timeline, once goals and outcomes have been compared, reflect on each person's AoRs and look for ways to refine and improve them. Discuss what projects in the preceding period could become templates for future projects.
Rinse, Repeat
Look for tasks that are being neglected now and create new Areas of Responsibility. Even if no one can take that AoR on now, it could be a useful way to empower the next hire by giving them an AoR to take the lead on as they walk in the door.
For more on AoRs, see the Asana blog: Rethinking the org chart: Areas of Responsibility (AoRs)
