Distributed responsibility: An engineering manager’s perspective

Asana runs on distributed responsibility: it’s our unique approach to management where leaders work to mentor and empower others to be as autonomous as possible. As an engineering manager, I benefit from many of the effects of this. Here’s a look at how distributed responsibility works in practice, allows for full ownership, and contributes to an environment built on transparency and trust.

Distributed responsibility: In practice

In contrast to a traditional, top-down structure, distributed responsibility needs a way to map responsibilities to people, since there aren’t just a few people in charge. At Asana, our Areas of Responsibility (AOR) system maps discrete responsibilities to individual people. Engineering AORs include areas of code, mentoring new engineers on the team, and cultural responsibilities (like our code review process or running the intern program).

Making responsibilities discrete allows different people to own things that would otherwise be connected by functional group; this allows specialization and ownership.

One of the most unique aspects of Asana’s engineering team structure is the separation of roles for Managers and Program Leads (PLs). PLs lead functional groups in their work; they are responsible for making sure that their team is doing the most important work towards an objective.

Managers, on the other hand, make sure that all responsibilities are held and going well, make sure teams are successful, and focus more on coaching others into holding their responsibilities. Though a single person can serve as both a manager and a PL, they’re often filled by different people.

I appreciate the focus that this can give to both PL and manager roles. As a manager, I focus on day-to-day work only as it applies to the growth of my reports, creating a very explicit space to focus on long term goals and reflection. This leads to a great balance between me and the PLs I work with.

Distributed responsibility: Taking full ownership

At Asana, distributed responsibility lets managers focus on their specific areas of passion and have ownership of their areas of focus across the broader organization. In addition to working directly with reports, managers often create roadmaps or build new programs and policies. In a more traditional structure, managers are responsible for those inside their functional group within a broader management hierarchy. At Asana, managers get to own these decisions for the engineering team as a whole.

I’m personally passionate about mentoring, recruiting, and championing diversity, all of which have led me to focus on my current AORs. In the past, I’ve run the intern program for the engineering team and I currently own the AOR for how engineering interfaces with university recruiting. I also own the AOR for diversity recruiting—I want Asana to be doing better than it is, so I’m pretty thrilled to have the autonomy to push us to do better.

Distributed responsibility also leads to a more modular approach to responsibility than most companies have. I’m happiest working as a manager to coach individuals, more than driving forward roadmaps for specific pieces of engineering work as a PL. For some people, it’s the opposite. Having multiple directions in which to progress makes space for people to find their own versions of success. It also increases the odds that people will be excited about all the facets of their work as they grow.

Distributed responsibility: A coaching tool

Distributed responsibility is also an awesome coaching tool. Most of my work with my reports is to get to know their goals (including helping them find what they are in the first place!) and to help them find the right work and feedback to grow and achieve them. I really appreciate the pattern of asking reports for what they want—almost anybody is happier if they have input into what they’re working on.

It’s also great to help provide a really clear sense of how their current and future work aligns with what they want. Coaching people to understand the value of particular responsibilities, and getting them excited about a new thing that they didn’t have context on before is also exciting.

It feels great to let my reports get the satisfaction of making meaningful decisions, and this practice is what turns people into future leaders. I personally appreciate all the incremental responsibilities that let me work towards being a manager.

Distributed responsibility: Creating transparency and trust

Systems that allow distributed responsibility also tend to build transparency and trust by encouraging those who own responsibilities to share their decision making process. I love that Asana has designed very open processes for picking our company priorities, that we have a value of “transparency by default”, and have a strong engineering culture of sharing and getting feedback on engineering decisions through design docs.

These all let people see the breadth of how our business is run, and to get to learn from the decisions that others make. It also feels great as a manager getting to share the details of your own work. I’m often inspired by my reports as brainstorming partners!

Distributed responsibility has let me focus on the things that matter to me and to develop skills I value. Beyond making my job fulfilling, distributed responsibility has also contributed to the success of our engineering organization as a whole. Our organization now is comprised of many people excited to fully own and drive pieces of work—I’ve gotten to see so many engineers grow by taking full ownership of large responsibilities!

Would you like to put distributed responsibility into practice as an engineer at Asana? Take a look at our open positions—we’d love to hear from you.