How Asana allocates engineering responsibilities transparently

At Asana Engineering, we take a systematic approach to allocating responsibilities, called the Fair Allocation of Internal Responsibility (FAIR) Process. I created this process after transferring ownership of Asana’s Engineering Intern Program to another person on the Engineering team. Since launching the FAIR Process, every new leadership role in Engineering has started being advertised through […]

At Asana Engineering, we take a systematic approach to allocating responsibilities, called the Fair Allocation of Internal Responsibility (FAIR) Process. I created this process after transferring ownership of Asana’s Engineering Intern Program to another person on the Engineering team. Since launching the FAIR Process, every new leadership role in Engineering has started being advertised through it, which has resulted in a lot of internal transfers, quadrupling the number of non-male Tech Leads we have for teams. 

Why have a process for allocating responsibilities?

I wanted a process for transferring responsibilities that was fair, transparent, consistent, and built that process out for the intern lead role. We adopted the FAIR process across Asana Engineering in February 2020. Since then, we’ve transferred several dozen responsibilities, ranging from small (e.g. Mentor Experience Lead for the aforesaid intern program) to large (e.g. my current role: Platform Area Tech Lead).

We thought sharing the FAIR process would be helpful to people outside of Asana. Here are the considerations we had in designing the process, how we implemented it, and a handy template you can use to try it with your team.

Origin of the FAIR Process

At Asana, our responsibilities—from Head of Engineering to owner of API Logging—are captured as Areas of Responsibility. This system makes it clear that each area of the company should have a single owner who is responsible for the success of that area. This clarity is essential for making great decisions, fast, as well as helping folks grow in their roles by taking on additional or new responsibilities.

When I was thinking about handing off one of my important AoRs, the Engineering Intern Program Lead, I started thinking about the best way for us to transfer responsibilities in general. What requirements should a process that transfers responsibilities have? 

I realized that the status quo would be to come up with a list of candidates, and then choose the most qualified person. This approach can work well, especially if I knew all the qualified candidates, and knew them well. But this approach has a risk of passing over qualified but less visible candidates. Perhaps I don’t know all the folks who would be qualified, or a name slips my mind. 

Let’s say I do draw up a list of candidates. Without a clear decision-making framework, my choice could be biased, or not based on what would make them great in the role. This approach also makes it difficult for those not considered to know where opportunities come from. 

Instead, I wanted a process for transferring responsibilities that was fair, transparent, consistent, and built that process out for the intern lead role. This turned into the FAIR Process, which we turned into a template for anyone to use. The core of this process is defining the requirements for the role, advertising it to all potentially qualified applicants, and then choosing the most qualified candidate. 

I came up with three main requirements I wanted to follow in my process:

  1. ⚖  Fair: The process should result in the best person getting the responsibility. I think fairness is both intrinsically good, and also good for the business as this enables that area to thrive most.
  2. ☀ Transparent: Everyone should know how the decision was made. This helps build trust in the process, and also makes it clear what someone needs to do in order to be a good candidate for the role in the future.
  3. 🔄  Consistent: There should be a documented way to conduct this process so it’s fair and transparent every time. This makes it easier for folks to use the process, and also makes it easy to contribute improvements that everyone can take advantage of.

Looking at all these together, we can see that our status quo “ask some folks if they’re interested” solution falls a bit short. It’s not necessarily fair (as I might be missing candidates based on my knowledge of the org), transparent (since the criteria for evaluation are not clearly documented), or consistent (since everyone could implement it differently). 

Introducing the FAIR Process

To try to improve how we allocated responsibility, I came up with the recursively named Fair Allocation of Internal Responsibility (FAIR) process. This took inspiration from how we recruit leads for our Employee Resource Groups, and how we interviewed external candidates for the role. See our FAIR Process Guide for more details for how to adopt this! 

Let’s say that we were looking for someone to own our Public API, which covers the processes for reviewing changes to our API contract. Here’s how we execute on that using the FAIR process.

  1. Define the requirements for the role: Write up what qualities you think someone would need to be successful. For Public API, this could be experience designing APIs, and a strong familiarity with our REST API. 
  2. Advertise the role and selection process to qualified applicants: Make an announcement to the relevant groups that this role is open, and how to apply. Our rule of thumb: Announce to the smallest group which contains all the qualified applicants. For Public API, this is likely announcing to our API, Mobile and Integration teams, as the folks who work with our APIs regularly. 
  3. Evaluate applicants to the role according to your requirements: Here you want to go through all your applicants, and evaluate them as objectively as possible with your requirements. You want to make sure that you set up your requirements so that it can concretely grade candidates on a gradient from “unqualified” to “extremely qualified”.  
  4. Inform all applicants of what decision was made, and why: All applicants to the role should understand how they were evaluated, and why they were or were not chosen. This doesn’t have to be incredibly detailed, and can just relay what requirements they were weakest and strongest at.

Done in an unbiased and thorough way, this approach results in a better process:

  1. ⚖  More Fair: Defining requirements, and evaluating candidates according to them, makes the process more fair, as it ensures that you’re evaluating folks based on what will make them successful in the role.
  2. ☀ More Transparent: Advertising the role openly, and informing applicants how the decision was made, makes it clear how the decision will be made.
  3. 🔄  More Consistent: Having everyone follow these guidelines for important roles ensure that we can consistently be fair and transparent. We have this documented as an internal Asana template, both with the steps, and with tips on how best to implement each step. This looks obvious, but we’ve gotten a lot of value out of incrementally improving our process, and having that value for every new user of it.

Transferring responsibilities FAIRly makes a better company

We’ve found that using the FAIR process consistently in Engineering has driven positive impact for both sides of hiring:

  • Teams looking for folks to take on new responsibilities now have a standard way to advertise and get those roles filled. If we can’t fill a role internally, it’s easy to then take the artifacts created running FAIR and advertise it externally.
  • Individuals can trust that any application within engineering will be evaluated FAIRly. Even if someone isn’t ready to take on a new responsibility, they’re aware of the options and know what growth at Asana could look like for them, and trust that they can move into those roles when they become qualified.

Together this helps the organization move faster, because we’re able to make sure the best person gets the job, and helps individuals grow faster, because they’re able to easily find and be considered for new roles. While Asana has always had great internal mobility, with the vast majority of our tech leads coming from internal applicants, having a process like FAIR helps ensure that this mobility scales as our organization does. 

The transparency created by this process gives engineers a clearer idea of the opportunities for career advancement internally. It’s often difficult to be aware of the types of growth that are available, especially outside of one’s immediate area. Thanks to a consistent use of the FAIR Process, folks have a clear idea of the responsibilities that are opening, making it easy to trust that there is advancement available. It also helps guide how folks think about growing their career. Someone might not be ready for a tech lead role now, but they can look at the requirements and start growing so they’d be a great applicant in the future.

If you’d like to take advantage of the internal mobility at Asana, we’re hiring

The post How Asana allocates engineering responsibilities transparently appeared first on The Asana Blog.

Source: Asana