AORs (Areas of Responsibility)

A living list of who owns what—not job titles, but specific responsibilities with clear DRIs

Emily Kramer
How to build a powerful marketing machine

AORs (Areas of Responsibility)

"We had a list of areas of responsibility which is just who owns what, it's not your job title. It's what are the things that you are the DRI for?" - Emily Kramer

What It Is

A shared document listing every important area of work and who is the DRI (Directly Responsible Individual) for each one. Unlike org charts or job descriptions, AORs are:

  1. Granular - Break down broad functions into specific responsibilities
  2. Living - Updated as people join, leave, or responsibilities shift
  3. Visible - Accessible to everyone so anyone can find who to ask
  4. Non-exclusive - Having the DRI doesn't mean no collaboration

The system solves a critical problem: "I'm doing a launch, I don't know who to go to for this, so I'm just going to skip it." When everyone knows who owns what, they know exactly where to go.

How It Works

Structure

An AOR list typically includes:

Area of Responsibility DRI Notes
Onboarding experience Jennifer (PM)
Onboarding copy Devin (Marketing) Collaborates with Jennifer
Website conversion Marketing Lead
Product launches (Tier 1) Sr. Product Marketer
Email drip sequences Growth Marketer
Brand guidelines Brand Lead

Key Principles

DRI ≠ Solo owner: Having the AOR means you're accountable for the outcome, not that you work alone. The DRI on onboarding experience (PM) collaborates heavily with the copywriter (Marketing) who has the AOR for onboarding copy.

Specificity over breadth: "Marketing" is not an AOR—that's a department. Break it down: "Website copy," "Email sequences," "Product launch for Feature X," "Brand voice guidelines."

Evolving granularity: As teams grow, AORs get more specific. "Emily owns all of marketing" becomes "Emily owns marketing strategy" while specific execution areas go to specialists.

Cross-Functional Application

AORs shine at interfaces between teams:

  • Product + Marketing: Who owns the onboarding experience vs. the onboarding messaging?
  • Marketing + Sales: Who owns the marketing-to-sales handoff? Lead scoring? Collateral for sales calls?
  • Engineering + Product + Design: Who's the DRI for each feature area?

How to Apply It

  1. Create the initial list: Brainstorm every significant area of work across the organization. For each, assign one—and only one—DRI.

  2. Make it accessible: Store it somewhere everyone can find (Notion, Asana, Google Docs). Link to it in onboarding materials.

  3. Maintain it actively:

    • When someone new joins, add their AORs
    • When responsibilities shift, update immediately
    • Review quarterly to catch drift

  4. Use it in practice: When something needs to happen, first check the AOR list. Don't assume—verify who owns it.

  5. Celebrate handoffs: When someone takes over an AOR, make it visible. "I finally handed you the managing editor AOR" becomes a milestone.

When to Use It

  • Onboarding new team members: Show them exactly what they own and who owns adjacent areas
  • Planning cross-functional projects: Identify all the AORs that need to coordinate
  • Resolving ownership confusion: When people argue about who should do something, check the AOR
  • Scaling teams: As you grow, break down AORs and distribute them clearly

Source

  • Guest: Emily Kramer
  • Episode: "How to build a powerful marketing machine"
  • Key Discussion: (00:40:36) - Detailed explanation of how Asana used AORs for cross-functional collaboration
  • YouTube: Watch on YouTube

Related Frameworks

Back to Team Building