The responsibilities and evolution of EngOps at Asana

‍Abi: Welcome to the show, Ryan. Could you start off by telling us a bit about yourself and your role?

Ryan: Thanks, Abi. My name’s Ryan Atkins and I’m the head of engineering operations at Asana. I’ve been at Asana for just about two years, and in my role, I essentially lead a team that’s responsible for engaging and improving the effectiveness and efficiency of our engineering organization and its engineers.

You co-authored this article called Bootstrapping Engineering Operations, and for people listening, this article was written in 2020. It was mostly a reflection of why and how the engineering ops team was formed at Dropbox. I don’t want to rehash everything in those articles, but I do want to cover a little bit of background. So for those who haven’t really heard of it before, what is Engineering Operations?

Engineering operations is essentially a function embedded within an engineering organization that helps ensure that processes and systems and tooling exist to help optimize the output of the organization.

A lot of that work, particularly the work that I drive, is related to an engineer’s experience and how engaged they feel in their work. This framework that I use around effectiveness, efficiency, and engagement is really like: are people working on the right problems? Are they doing it efficiently, as fast as they possibly can? And do they feel great? Are they engaged with their work and do they feel good about it? And so that’s the internal focus of an engineering operations organization.

That’s really interesting. So, what does your current eng ops team look like at Asana and what are you primarily focused on there?

Yeah, we’re a pretty small and scrappy team, which I think is probably the state of a lot of just engineering organizations that are going through really rapid growth, but we consist of technical program managers and program managers that are aligned to various work streams.

And there’s a couple different frameworks that I use to explain this. The one that I’ve been leaning into recently is people-centric programs, business operations, and then software development lifecycle-type work. And so I can give you a quick example of all three:

• In the people bucket, we have programs like engineering onboarding or our engineering interview experience, anything related to enablement, talent, growth, and engagement happens in that bucket.
• In the business operations piece, we’re looking at broad scale communication in the org, setting up systems, processes, standards, to help make that predictable and engaging and reliable, but also things like vendor management and headcount planning and growth, all these internals that help the business side of an engineering organization function.
• And then lastly, of course, we have the software development side, which is what are the set of horizontal programs and initiatives that help teams function effectively? So for example, a TPM that’s focused on our accessibility efforts, so embedded within our design systems and accessibility team helping to drive forward changes in how teams think about designing and engineering more accessible solutions to our product.

We talk to a lot of different types of teams that are supporting engineering. Some of those teams are called platform teams or dev ops teams, dev prod teams, infra teams. Many companies have these types of teams, so I’m curious, how is EngOps similar or different to maybe a more typical dev prod or dev experience team?

Yeah, great question. We have a developer effectiveness and developer efficiency team and we partner with them very closely. I think often teams like that are more focused on the under the hood tool chain, workflow, and systems that engineers are using to manage, review, deploy, test, code.

We are a click above that, looking at not just the system of our engineering lines of code, but the system of our organization. We’re thinking about what are some of the cultural levers that we might be able to pull that also contribute to the same overall goal, which is helping engineers do the right work faster and feel great about it.

I’d love to unpack that further later on, but a related question. You mentioned you have TPMs in your org. Does the entire TPM org sit under engineering operations or is TPM its own org that has folks working in engineering operations?

It’s evolving right now at Asana and I’ve been through similar sets of evolutions that prior companies I’ve worked at like Stripe and Dropbox. Right now we’re small, and I think that Asana, we’ve gotten pretty far in our scale and growth without leaning too heavily on a need for TPMs, but I do see that changing in the future.

There’s a couple of reasons why that is related to some of the things that make Asana really special, which is the way we leverage our own product, which is all about work management. It’s allowed us to smartly cut a couple corners in the way that our org is designed. There’s a couple other cultural things that we lean into that I’m happy to talk about, which is our system of ownership that we use to really map what is and isn’t owned, which enables people to do a little bit more role blending. And so carving out the specific necessity for one TPM gets a little bit delayed because you have a really organized system for handling that type of work.

I think you’ve done a great job really distinguishing engineering operations from dev ops or dev pro teams. I’m curious, at least from my perspective engineering operations doesn’t seem as common as some of those other kinds of teams. Why do you think that is? Why do you think engineering operations isn’t more common across the industry?

I mean, I’m completely biased here, but I think that the tide is coming and people are beginning to understand. If you look back historically over the last decades, enablement teams have become more popular. I think prior to having Engineering Operations teams, you’ll see a lot of sales enablement, sales operations teams that are dedicated and embedded within their functions. And so engineering operations I believe is coming more to the forefront.

I’ll tell you a couple reasons why I think it’s maybe been delayed a little bit, and they’re all really good reasons for holding off for a long time. The first thing is the nature and culture of the software engineering industry, which is that every engineer that I work with really has a passion for contributing to the community. And that can happen in the form of mentorship, knowledge sharing, the way that engineers think about open sourcing and just this idea of contributing back to the community that exists. And so I think that’s allowed organizations to get further than they might have otherwise, just that cultural belief that exists with the role itself.

The second thing is really that organizations are systems just like technology systems and tech stacks and thinking about the inputs and outputs. And so I feel like engineers naturally, not just because of the underlying culture, but the fact that organizations are systems, love to contribute to building and understanding and modifying and optimizing the system that is the organization and culture. And that is absolutely the viewpoint that I take, that we operate the engineering org like it is this system that has inefficiencies and we build up cultural debt like technical debt and it can be addressed.

So I think that the fact that so many engineers are really passionate about this space is why it’s delayed and at a certain size and scale, organizations really benefit from having dedicated staffing to this. And it doesn’t need to detract from the way that people culturally value improving the organizational systems. It can just add to it and make it even better and more efficient.

That makes sense. Software engineers by nature are more focused on these types of problems. And so to your point, maybe there hasn’t been a need as quickly for a dedicated function to solve these types of problems. From your perspective, I’m sure since you’ve pioneered this function, are you seeing more companies standing up engineering? Are you seeing this trend?

Yeah, I am seeing it. And I’ll tell you two other reasons why I’ve seen it emerge more recently.

One is the just pure scarcity for engineering talent and the talent war around that. So anything that you can do, that an organization, that a business can do to help attract the best engineers, grow and retain the best engineers and also creating an environment in which they really will thrive is just a better business outcome than having a lot of turnover, spending a ton of time.

And the other thing is really like making sure that you are aligning the work that engineers are doing to best optimize for their skillset. I have a ton of different examples of this, where I’ve come into an organization and there will be an engineering leader, an engineering director, sometimes an IC, sometimes an EM, who is managing something like an eng onboarding program.

And it’s fantastic, and it’s great to have leaders that are driving that. But what happens with scale is that the operational burden of running a program like that just takes up too much of their very precious time. And I feel like a lot, this maybe sounds sad, but a lot of the impact that I’ve had is just freeing up time from senior engineering leaders, by creating a better organizational system for these programs that exist.

I’ve just seen this time and time again, of helping to make sure that engineering time is the most leveraged that it can be. And so identifying the inefficiencies that exist and helping to centralize those with a really high quality program manager is just a better way to get that work done.

And I’m sure a lot of people listening, eng leaders in particular can relate to that pain of trying to juggle these cross-cutting initiatives along with their day to day delivery work.

The other thing is that I am also very conscientious. I don’t want to come in and be like, “oh, eng director, you really love working on eng onboarding, you should stop doing that, because it’s not going to use your time.” It’s not like that, it’s more like, “what are the things that you really care and value? And what are the things that are just more around program management and the operational piece that we could carve out? We could maintain your role as a strategic advisor and help you keep doing the things that you love doing and the things that you’re good at and really support your effort there rather than displace you from this really important cultural pillar.” So that’s the approach that we take.

That’s a great point. This conversation is making me think of one of our customers, who is an engineering manager and cares a lot about developer experience. He wants to lead what I think is essentially an engineering operations function based on your definition of it. So, how should he get started? Do you think he should just try to go pitch his leadership on forming an EngOps team right away? Or do you think he should approach it more gradually by taking on a project or something like that?

That’s a really good question. I feel like I have two approaches that sound contradictory. So one is the importance of the kind of, I’ve always seen this grassroots, organic nature of how these types of eng ops responsibilities are distributed throughout orgs where people just really want to volunteer and step up to own a thing. No engineer I know wants to sit behind a computer and just write code all day long. They want to be involved in the community and growth and collaboration and it’s good for their careers. And so that’s really critical.

At the same time, it’s also really important to have some top down leadership buy-in to the importance of this role. That’s really important.

And the last thing that I’ll say is I think scale really matters a lot. So EngOps is very specifically a function where the benefits increase with the scale of the organization.

And so when you are trying to decide whether it’s worth making an investment in your first EngOps hire, one of the first things that I would do is just map out the inefficiencies that exist, or maybe the set of cultural programs and systems where people are chipping away at different parts. Understand the broader map and then figure out the smartest way to draw a circle around the set of responsibilities that that first EngOps hire could take on to add a lot of value. And there’s no silver bullet to when, the timing is absolutely perfect, but I tend to think around like a hundred engineers as a pretty good place to get started. There’s like famously Dunbar’s number of 150 of the size of a community where people stop knowing each other particularly well where for sure you get to that state where having someone who is thinking a lot about organizational strategy really, really matters.

That’s great advice. In terms of drawing that circle, like mapping out the system of an organization, based on your experience, are there some common circles or pain points that you think someone doing this should look for or expect to find?

I use eng onboarding as an example a lot. For one, if you’re looking ahead as an organization, I see these startup companies that raise their series C and that’s going to go into a lot of engineering hiring. The question is, how do you do that really well? And how do you make sure when you hire this new wave of engineers, that they are set up for success? And I think around that time, those are typically some of the first things that you would circle. Is our onboarding program effective? And also are we doing an efficient job of evaluating talent? Is our recruiting process really efficient?

That’s typically the space where I get started. There’s also some benefits that come with having engineering operations actively involved in onboarding, which is that one, the EngOps team gets to set themselves up for success because of the first impression that they create on new hires. I have always strategically gotten deeply involved in engineering onboarding as this first touchpoint for engineers. You have a disproportionate amount of leverage on how you influence the culture in those first few weeks of an engineer’s experience. What are the things that you are highlighting? How are you helping them to feel a sense of belonging to the team and organization? So I always start there. I think it’s just really, really beneficial to think about the beginning of an engineer’s lifecycle with the company through their interview process and onboarding.

‍I love that. I’m thinking back to this engineering manager. So let’s say he goes and pitches eng onboarding to leadership as something to focus on. I’d love to get your gut reaction, if these leaders were to respond with “we don’t need an engineering ops team because teams should be able to figure out their own ways of working.” What’s your reaction to that statement?

So a couple of things that I would give advice to this engineering manager on angles to bring up. One is around duplicated effort. So if you start to see teams that are all building the same playbook, because they are somewhat disconnected, duplicating effort, like every new hire that starts is embedded with their team and mentors on the teams are repeating a bunch of information, architectural information or cultural information, and looking for that duplicative work across the org, I think is really big.

The second one, and I feel like sometimes I just describe EngOps as doing this, which is like drawing the circle and or putting a lasso around the organization to prevent cultural drift. And so I see this a lot. I see it across functions from engineers, product management design, but also like different pockets of the org between product and infrastructure. If you’re paying close attention, organizations as you scale begin to drift apart, and they begin to do things that are slightly different.

I lead a monthly meeting with all of the engineering management community at Asana and we were just talking about this this week around the desire for when standardization really matters. And this is one of my favorite questions, I ask it to like candidates that I’m interviewing, around when do you create autonomy and agility for local teams? And when does that stop working well, where you need some form of standardization? And in my experience, three things happen that break this down.

So one is around intake processes for teams where they need to collaborate with other groups and understand the needs of their internal customers. And if different teams have different intake processes, it leads to a lot of confusion and inefficiency. So that’s one.

The second is around managing additional dependencies, like when you’re waiting on a team to build a new service for you and you’re not sure when it’s going to be done, you start to hear things when you make a request of another team around like, oh, we really want to work on this, but it’s not our top priority, so understanding prioritization is the second one. So you got intake, you got dependencies.

The third one is around reporting up where you suddenly have an engineering leadership team that’s a little bit too far removed from what’s happening at the team level. And it’s very hard to look across 10, 20, 50 different teams and glean any valuable insights. It’s like, how fast are we moving? Are we actually hitting our goals? If everyone is working in different ways? So I feel like there’s this scale that you get to where those three things start to reveal a couple of cracks in your organizational structure where eng chops can come in and provide the glue to bring things back together.

I love the question that you ask people you were interviewing. Hopefully they listen to this and get some tips. I’m curious, it’s related to what we’ve been discussing, but in more simpler terms, what is the business case for engineering ops?

This brings me back to a question that you asked earlier, which was around why has EngOps taken a while to catch on and why do I think it’ll be more valuable in the future? So the business case that I would pitch to our CFO and my CTO when I’m advocating for headcount are really around inefficiencies that exist in the way that engineers are using their time. And I think that we’ve gotten so much better around tooling and measurement of organizational effectiveness with a lot of really prominent new frameworks and articles and books and podcasts and things that have been recorded just in the last seven or eight years, we’ve become much more attuned to measuring the output of an org and understanding the core metrics that are so fundamental and make it tick.

And at the end of the day, I talk to my manager who leads engineering at Asana and pull up things like if we can save every engineer seven minutes, we are at a scale where that is generating brand new engineers. And if you think about the amount of time that it takes to identify, assess, hire, onboard engineering talent, if we can actually get more value just by finding these inefficiencies that exist, sussing them out and addressing them, we can do so many great things and it’s gotten easier to track this.

So little things like meeting time. I literally this morning spent time doing an analysis of how much focus time exists in our engineering org per engineer. And we do this through like analytics on top of calendars using a set of tools, other things like the amount of time that people spend looking for documentation or asking the same help question to get unblocked, because it’s not easily discoverable. So all of these things around sniffing out these inefficiencies in ways that engineers are using their time in ways that they don’t want to and are inefficient and how can we build better systems and tools to prevent that means we’re generating more engineering impact. And so that’s the argument that I lead with

That makes a lot of sense. And as we all know, there’s so much inefficiency with an engineering org. So what’s the right investment then in this function, like what, is there a rule of thumb for a ratio of EngOps, org size to engineers that you have in your mind?

Yeah, it’s hard because it depends on so many different things. It depends on the product that you’re building. So what space are you in? It depends on the culture and what you really care about as an organization. In particular I think one of the things that I love most about Asana is that it has a very long-term oriented mindset. So we’re willing to make some short term trade offs for long-term benefits and not every company is like that. Some companies are desperate to hit their goals and targets in the next six months, and they don’t have the luxury of long-term planning and we do. So I think that’s important. Those are all factors that contribute to figuring out what the ideal ratio is.

So one, I think starting early makes sense. And maybe as you gradually grow over time and you build out more of this organizational and cultural infrastructure, the ratio can get broader. But I like the idea of starting around a hundred, maybe 125 engineers, making that first EngOps hire, and scaling it up around, I’d say a hundred, maybe 150 engineers to one EngOps person, maybe a little bit lower than that. Other factors would be like, do you use a good work management system? Put it in a plug for Asana there. How distributed is your team? What does your team look like? How monolithic is your code base? How many different products are you building? I think these are all factors that contribute to what that ratio should look like. So sorry that it’s a complicated answer.

In your article you wrote something I found really powerful. You said HR teams solve global company-wide problems and set policy, which are rarely eng specific, EngOps directly embedded within engineering is focused on eng org health and the development of engineers. Going back to this engineering manager we’ve been talking about, what additional advice would you have for maybe getting buy-in from HR? It topically seems like there’s maybe overlap with what HR does. So how do you build a partnership with HR and how do you advocate for EngOps to maybe a skeptical HR stakeholder?

I’d say that relationships with your people team and HR team are so critical. And I work very closely with our HR business partners and our TA partners and that relationship is so, so important. And I also think it’s really important for the EngOps function to be directly embedded and to report into engineering, to be closer to the ground. So some of the things, establishing a firm relationship and building that trust, it really helps to have your most senior engineering leadership buy in and support your function and what you’re trying to do. I think that’s really important. I also feel like ensuring that, or maybe communicating why engineering needs this dedicated role. And I’ll tell you my reason, why is that engineering often, across a company, especially like in a software company will have more of the same role.

You have more engineers than you have of any other single role in the company. You have more engineers than you have recruiters or sales teams or marketers, or even data scientists. Engineering is this large critical mass. And what ends up happening is the engineering org hits these problems of scale before the rest of the company does. And so these things like, I address this all the time. We have more layers in our engineering org. And so just how we think about our org structure and policies that are related, that are created across the org break down within engineering. We have four layers, five layers of management, because we’re so much larger. We have hundreds of engineers. If you compare that to other functions, we’re just so much bigger. And so a really good example that I have at Asana is we had this problem with documentation, of just like navigating docs.

Our engineering team is prolific, writing a ton of documentation, there are tons and tons of engineers. So what are our systems and tools that we want to adopt company wide? Because a lot of these documents that are being written need to be reviewed and consumed by our product marketing team, our finance team, and so we encountered this problem first and the engineering operations team drove a solution, which was adopting a new set of tools and standards around how we organized information. And we had to take the lead on that, because we experienced the pain first, but it was important to have a consistent solution that would work for the rest of us. So engineering becomes the Guinea pig and the pilot for a lot of things. And it’s critical to work with the people team and to be close and bring them early as key stakeholders for when you make that switch to broaden engineering org solutions to the whole company.

That’s so interesting. And it’s inspiring because in some ways, what you’re saying is EngOps is paving the path in terms of culture and practices for the entire company, right?

I can give you just two more examples really quickly. I think a lot of the rigor that we’ve put into our interview system, so thinking about interview rubrics and how we train interviewers, because our vault, our scale, our hiring process has been a lot larger than the rest of the company. The other thing is, if you look at typically in a software company, the first 200 employees will be very disproportionate engineers, as you are building out this product and understanding product market fit. And so you typically have longer tenured employees who have been around a while who are bootstrap creating a bunch of this like internal organizational infrastructure themselves. So one, one example is around our interviewing processes, another is around things like career levels and ladders and how we talk about calibrating on performance. I always see engineering teams taking the lead there where they need this form of standardization first. And then often the company will adopt what happens there.

‍I love that. So you’re talking about a progression of an organization here. I’m curious, what’s the progression of an EngOps team as an organization evolves, and what kinds of challenges do you see throughout those different phases?

I have a framework around this where it’s like you’re growing as a company organization and you start to see things form, like if you zoom out enough, you start from just, like, pure chaos where no one knows what’s going on. And then someone’s like, huh, we should really document this. So if someone writes like a checklist and then a checklist turns into a process, right?

As you mature a little bit, and that checklist needs to be applied across a couple different places. You turn it into a documented process. And then the process evolves or becomes a program where you have a beginning and then a program becomes a full system. And that’s typically the evolution of a thing. And that could look like how you address onboarding or information architecture and documentation or interviewing or whatever it may be.

And often there’s the people side parallel, which is that you’ll have no one toown anything and it’ll be chaos. And then one volunteer will step up and it might be an engineering manager or like a senior IC. It’ll be like, okay, this is a problem, I’ll take care of it, I’m volunteering my time but I’m only going to spend 5% of my time on it, and then that problem space grows and everyone’s like, Hey, how come our onboarding program is not great and hasn’t changed in a little while? And the person leading is like, look, I only have 5% of my time to spend on this. And you realize that you need that dedicated hire. And maybe there’s a step in between where you might form a committee to work on this thing or one person isn’t enough. We need five people working on engineering onboarding. And then you realize at a certain point, okay, this is really inefficient. Who is managing the set of five people that are all volunteering to work on this? Let’s get a program manager to focus on it.

That evolution, it could take, depending on how quickly an org grows, it might take two years, it might take six months, but I see that constantly, that pattern emerges. And if you see that pattern emerge, you can accelerate that process that serves your organization well, if that makes sense.

That framework of checklist, process, maybe a committee, and then program, that’s great. So then in a mature organization where you’re maybe more at the program stage, I’m sure there’s always new things going through that evolution, as new problems come up. Is the work of EngOps to continue to drive and scale the existing programs as well as implement new ones?

Yeah, absolutely. Drive and scale existing programs, I think it’s really hard in an organization, I think there’s a very easy failure mode where unless you have very large acquisitions of other companies where you suddenly have an infusion of like dozens of engineers at once, you gradually scale and you totally have this like boiling the frog type problem where things just slowly get worse and decay over time. And you have these paper cuts that you just get used to and having an EngOps organization that is zoomed out to be like, wait a second. I see paper cuts left and right and they really add up to something detrimental. And so as the org scales, someone who is responsible for pausing and saying, does this still make sense? Let’s go back to our first principles behind what we really want to try to achieve. I’ve done this in a lot of places, especially with the evolution of eng onboarding programs where it’s like, what actually are the highest order things that we’re trying to achieve? Is this still true?

When we created this program three years ago, when we had 150 engineers, do we still have the same set of goals that we had then that we should have now? And constantly evolving as we scale, identifying existing programs, building out new ones, really important. Things like rotational programs, companies might call them like hack sprint hack a month, that’s something that we’re thinking about at Asana, where we’re large enough that we need to deliberately create structure around internal mobility and making sure that engineers have a sense of growth, that we are not creating knowledge silos. So there’s an example of one that we are like, we’ve hit a size where we really need a little bit more structure around this.

That’s a great point around always questioning the things you’re doing and the importance of phasing out programs, not just creating new ones. Pivoting a little bit, in your article you wrote a successful EngOps team will help the engineering org in a number of measurable ways. Engineers should not only feel more productive, but be more productive. So what are the ways in which you measure these things, in particular around organizational health and effectiveness?

First thing to acknowledge is that it’s a really hard problem. There is a lot of failure modes and Abi, I know you’ve talked with other leaders about this and I’ve listened to great podcasts where people have identified this. You can create the wrong metric and create a bunch of perverse incentives. There’s a lot of research around, like if you inadvertently gamify certain elements of being an engineer, there are a lot of consequences to that. So we’ve actually, as a team, I’ve driven a lot of this work partnering very closely with our like dev ops, dev effectiveness team in identifying a core set of five metrics that we look at. Some of them are input related where it’s like, what are the factors that contribute to an engineer’s experience that impact their velocity? And some are output related. So what are some of the things that we know if they’re moving fast or not?

And I’d say the most important thing at the highest level is really looking at your core business goals and do we set these? Are we measuring them? Are we making progress toward them? And that exists at a high level and then a notch down some of the ones that I’ll take, some of the output metrics that we look at are, and I got to say again, caveat, very imperfect and we’re still learning. And a lot of these metrics also take a long time to bake. So we’re looking typically at quarters or halves. And so I’m only two years at Asana, so we’re still letting these things bake. But one that we use is pull requests per monthly active GitHub user, and it’s imperfect, but at our scale, couple hundred engineers, it’s helpful to look at trends over time.

Are we continuing to see the same form of output? And some of the, you can see in my internal documentation that the footnotes and asterisks, which are like, we know that not all pull requests are the same size, they have the same impact, but we’re trying to normalize over a large group. So that’s one output metric. Another is around sentiment. Do engineers feel like they can move fast toward achieving their goals? And we ask this question in our bi-annual our semiannual engagement survey, and I think it’s really important to keep that qualitative feedback around sentiment of speed.

Some of the other input metrics that we look a lot at, one is around hiring. So this is the amount of engineering hours we spend to have one converted engineering hire. And we look at this because it’s expensive. We are spending dozens and dozens of engineering hours through our interview process, through interviewer training to make the hires that we need to grow our team. And so we look critically at that. That’s one. Another, I mentioned this earlier around focus time. So are we protecting calendar time for engineers to have that critical sense to achieve a sense of flow, and do their best work and feel good about it. And this is something organizational creep over time, we look at our calendar of all the all hands that we have, the communications that we send out. And we are increasingly critical about what that level of noise does for our engineering team. And so that’s another one, looking at focus time.

One more on the input build time is what we refer to as our build cycle time. So like the P50 and P90 around how long does it take an engineer to make changes and see those changes appear in their local development environment. It’s such a core part of the engineering workflow. What are things that we can re do to reduce that like build cycle time? So there’s five for you, two output ones, really three input ones. And we have a list of like 75 secondary metrics that we also look at, but those five I think are useful because they’re universal, so they impact every single engineer. They are diverse, so we’re looking at different pockets of how engineers spend their time. And I think they’re relatable and understandable. And I think that really matters in helping, also we’re not just like passively measuring velocity, but the act of communicating that we care a lot about this has secondary implications on our culture, like Ryan is spending a lot of his time looking at these because we care a lot about velocity and it sends I think an important message that reinforces this cultural value that we have at Asana, which is do great things fast.

A little bit earlier you mentioned this term like cultural levers, right? Like engineering ops is really focused on these cultural levers and you gave one really great example, which is onboarding developers. You’re really setting the tone for their expectations and initial impressions of the culture of the company. What are other cultural levers that you have?

I love this question. I’ll give you three more. I don’t know, probably onboarding is the most important one. The three others that I focus on a lot, one is the eng manager community. And we have deliberately crafted a very specific experience for managers, and it exists in dedicated slack channels that we have, Asana also just does this really, really well. So like very, very deliberate part of what we do. We have this monthly manager meeting that in every meeting that we have, one, it’s well attended. So there’s leadership buy-in. I’ve been at other places where people have tried to run periodic manager syncs and you just watch the attendance dwindle over time. And so making sure that it’s high production value and high impact to the attendees and that leadership is supportive of this time is really important.

So we have these monthly eng manager meetings and it’s super useful to get a pulse check on the set of people that are responsible for really establishing local cultures of excellence and making sure that there is a support community around that. So as a part of these monthly meetings, we almost always have 20 to 25 minutes of breakout time where managers are meeting with a group of six other managers that they might not know. We also have a recognition segment where we are highlighting excellent work and reminding people what good looks like. So that’s one big one, the eng manager community.

Another really big one is whatever forum you use to communicate broadly. So for us, it’s an eng all hands that we run monthly every six weeks or so, where we curate the content and we are very deliberate and mindfulness is another Asana value around what that experience looks like. What do we want to reinforce? What do we want to help people understand? And so we had an eng all hands just yesterday where we had this amazing 15 ish minute segment on our experimentation framework, where it was a lot of, like, we could underscore some of these themes around velocity moving quickly and also how we care about customer value and what that looks like. And so using a platform like English all hands is really important.

And then I think the last one is any form of leadership stage. So I work very closely, I help to run our head of engineering staff meeting, where we meet biweekly. And that’s such a critical touch point of just surfacing concerns that people have from within their engineering pillars or divisions and having a really tight leadership team, I think is really important. Again, all of these things are acting to prevent this cultural drift. And these are really the set of platforms by which we can incorporate a lot of our engineering cultural strategy and make sure that they percolate to all the right places, that we’re also have the right form of input.

I’m kind of blown away actually, because it makes so much sense now that you explain it, you’re there at the very beginning of the developer journey at the company, but then you’re there working with executive leadership, but also the manager community. So you’re everywhere. So that’s definitely a cultural lever.

I’ll add one more that I think is really important that we do really well at Asana which is having these structured feedback mechanisms. There are a lot of kind of like public within Asana projects that are really, really important and easy to access and they encourage general contributions. So I’ll give you a couple examples. There’s a project that I’ve spun up that’s called eng org opportunities and there’s different variants of this across Asana. It’s a cultural pattern that exists. So there’s a project called Asana opportunities. There’s a project that’s called, I’m glad you asked. And basically it’s people can insert any questions that we have and we have a comment thread about it and people can upvote and engage. And there’s another project that’s on engineering velocity opportunities, so very specifically related to that and having these clear forums that exist, I think endorses their use, right? It’s like we really want to hear from you. Just like you might make it easy for people to report bugs. These are cultural bugs. How can we surface them and work together on them and decide what’s important and move forward? And so I think that’s another critical component to our cultural infrastructure

‍That makes sense. Well, those forums remind me of something you mentioned at the beginning of this episode, which was the system of ownership. I’d love to know what that is.

This is long standing. There’s blog posts that were written 10 years ago, this is a core part of Asana’s DNA. We have, we call it areas of responsibility or AORs for short. And essentially it is a database that we’ve created in Asana that maps out who owns what, and in a way it plays out as a parallel org chart. It’s not our managerial chain, very deliberately, but it is an ownership hierarchy and it spans a wide range. So there are things like parts of our product and tech stack that are owned. So an example is something like mobile authentication is like owned by an individual. And so if you have questions or you identify a bug, there are also sub areas of responsibility.

Like iOS authentication is owned by someone else. Android authentication is owned by someone else. And that’s one pattern that exists across our product and technology stack, but also from a cultural perspective. So there is an AOR written for eng all hands. And there is an engineer who is responsible for directing and curating the content. And I partner closely, I am the parent AOR holder of our eng all hands effort. Interview questions have owners, everything has owners. And so it’s one, it helps for just like routing questions and nothing can fall through the gaps, but two, it formalizes and makes important the sense of ownership, such that when you are reflecting on your growth and impact as an engineer, it’s pretty easy to pull up these AORs that you’ve done work on.

We also within engineering structurally support this type of work in the way that we’ve set up our operating cadence. So we operate in sprints and we have these two week sprints and periodically throughout the year, we’ll have what we call off sprints and offs sprints are designed to one, create a little bit of the right slack into the system where sometimes sprints carry over, they enable teams to pay down technical debt, but they also allow individuals to spend a little bit of time reflecting on their AORs that might exist beyond their core work on their teams. So that off sprint comes up and you’re like, oh, that interview question, all the answers to that question have been leaked online. I’m going to need to rewrite a bunch of this and that’s my time to work on that.

Well, it’s a really impressive practice and it’s making me think there’s this idea of having cross functional teams that own specific areas of a product or a business that’s decoupled from the management hierarchy, right? But this is taking that to a whole nother level where you have people owning things that are decoupled from even teams. How do you decide what is and isn’t an AOR at Asana?

Difficult philosophical question. I would say it’s amazing to me that there are very few things that couldn’t be AOR able, like turned into an area of responsibility. And I think an important part of the system is being free to abandon an AOR or collapsing it. We see a lot of change and I actually at a metal level, I am the AOR owner of the AOR system. And so helping people transition AORs, if you’re burnt out from it or if it’s just time to do something new or if you frankly just don’t have time and bandwidth to do it anymore, we have a full process for transitioning those AORs. I see the things split a lot.

If you look at, I’ll give you an example, within our engineering interview process, there’s like a one core AOR that exists that has a portfolio of sub AORs where people are working on, how do we onboard new hiring managers? How do we train engineers as interviewers? How do we make sure that all of our questions are assessing the right set of skills that we want to see in our candidates? How do we help to customize new interview loops when we start to go after a new particular role? All of these are sub things that are owned. How do we help our hiring managers close candidates and talk about hard questions that they might ask? All of these things are owned and that also empowers individuals to make local decisions to make these things better. So I feel like there’s so much benefit that we derive from this system.

Changing topics a little bit again, how do you see things evolving for the EngOps domain over the next three to five or 10 plus years?

I mean, I think there are a lot of roles that have all, I think, like we talked a little bit before about TPMs and playing this role and helping, filling in the seams of the organization. And I sort of saw this, this evolution when I was at Dropbox, which we formed sort of a central services org. I’ve talked with a lot of folks at Facebook who have this, their mission control model. And I think that’s the natural evolution is to bring together this central set of services that can partner together that are looking organizationally wide. Some core components that I see us growing into are deeper analytics is one, and being able to leverage data, data becomes more valuable as your org grows and you can draw a different set of conclusions when you have just richer and better data, and others around tooling. So building out the set of tools that we need.

What’s really amazing about Asana is that a lot of the like thinking about organizational effectiveness is a core part of the product. And so the problems that we are facing and what we solve as what we see as an organization, we know that a lot of our customers see too. And so working on embedding that within our product itself. So I think a lot of the next layer of EngOps is not just managing these surface level programs, but really setting up the tooling and systems to scale these things broadly through better analytics, data, and capturing reporting. And then, yeah, just some core tools to automate a lot of the work that needs to happen.

Ryan, thanks for that answer. And we’ve covered so much in this episode. Thank you so much for joining us and hopefully we can have you on the show again in the future.

It’s really fun, Abi, I love talking about this stuff, hopefully that comes across.