10 tips for setting engineering goals from Asana Head of Engineering, Prashant Pandey
As an engineering leader, one of the greatest gifts you can give your team is clarity of purpose, plan, and responsibility. Recently, Asana Head of Engineering, Prashant Pandey sat down with Plato to discuss why clarity is so important and how it impacts goals. Here are some of his insights and advice for setting engineering goals that are transparent and empowering to team members, no matter where in the world they’re working.
Q: How does the Asana engineering team approach goal setting and how has that approach changed since going remote?
A: At Asana, we believe in creating alignment through clarity. It’s how we approach building our product and how we set our goals as a company. Specifically we think about clarity in three buckets: clarity of purpose, clarity of plan, and clarity of responsibility.
Purpose is the why—why are we doing this thing or setting this goal?
Plan is the how—how will we go about executing it?
Responsibility is the who and what—what is each person contributing to achieve the goal?
We follow an OKRs methodology and set objectives at the company level through a combination of bottoms-up and top-down projects. Once goals are identified, individual teams set commitments for the goals and key results they will drive in support of these objectives.
In terms of how things have changed, I will say that building a distributed engineering culture is very different from working during shelter in place. We went from hiring people to work together in an office to reevaluating what we could realistically accomplish working apart. Right away we knew it would have an impact. We asked our engineering team to take a few weeks and get a lay of the land, then come back with a sense of the potential impact on their individual effectiveness and our collective velocity. From there we recommitted to our goals, either changing the timing of the goals we had originally planned or refocusing them entirely. Our commitment to clarity, even before shelter in place, allowed us to do this efficiently and still remain ambitious with our new set of goals.
Q: What are some of the roadblocks that teams run into when implementing OKRs or other types of goal setting frameworks?
A: The primary roadblock I see on customer teams is a disconnect between the goal planning process and execution. Most companies have a planning process. They take the time to think about their big objectives and lay them out in a formal document, but once that document is ratified, it’s in no way connected to the work they’re doing. And immediately we see that the execution starts to go in a whole different direction. Team leads and individual contributors might review the goals again every quarter or every six months but it’s not tied to the day-to-day. At the same time, it’s difficult for one team to see how another team is executing against company goals and that creates alignment issues as well.
Say a sales leader wants to see how the engineering team is progressing against a goal, they’ll likely have to go through a ton of emails to figure it out or hire a project manager to do it and create a status report. But as soon as the report is created the data is already stale because work is moving forward.
Having clarity and real-time visibility across departments makes your business more agile so you can make decisions about resourcing or prioritization in real-time. OKRs need to be connected to work. They need to be at the center of execution and easily changeable. In fact I think the best OKRs function as a way for teams to measure themselves, not for management to measure teams.
Q: What’s your advice for setting team goals when you’ve only been given vague direction or overly ambitious aspirations?
A: In general, I think one of your key responsibilities as an engineering leader is to create clarity out of ambiguity. If you find yourself in this position, think of it as an opportunity—not just a challenge—to take something vague and give your team clarity on how to approach it. You’ll earn a lot of credibility when you can create a clear plan for both your executive stakeholders and your team.
Q: What advice do you have for senior leaders looking to set non-product goals in areas like mentorship, process, or quality?
A: First figure out how much buy-in you need from your leadership team to set those goals. Then consult with the team to determine the most important of those goals. Let’s use quality as an example. If your team is already delivering product features at a high quality level maybe it’s not the right time to set a more aggressive goal. Maybe you just want to set baseline metrics so you can start measuring your work over time and get signal if things are going off track. Determining the amount of time and space you need to pursue your goals is also important. If there’s not enough time, you might be setting yourself up for thrash or flat out failure. That’s information you can use for setting goals next time.
I would also get into the habit of reframing these goals as business goals. Continuing with the quality example, if engineers ship low-quality features they’re going to be spending time triaging and fixing bugs later. That translates to wasted time and money which has a clear business impact. So how do you reframe your quality goal to communicate that? It’s not easy and requires a little bit of marketing but it’s a valuable skill to have.
Q: Should goals always be quantifiable?
A: The short answer is yes, teams should have a metric for measuring if they’ve met their goals or not. I generally advise teams to spend time setting metrics up front rather than arguing about it at the end of a project. But it’s not easy to quantify everything. You might have a squishier goal like, “We want to be more secure next year than this year.” Okay, so what does that mean? How do you quantify security? That’s something you have to think about. There isn’t one clear answer but you might be able to break it down into smaller parts like achieving two new security certifications, reducing data breached by X%, or achieving a particular SLA. Think about what would need to happen for your team to consider the project a success three to six months down the line and start there.
Q: How do you set goals for high performers?
A: Ask them to set the goals! As a manager, it’s not your job to set goals all day long. It’s a collaborative process where people are contributing and setting goals with each other. Leverage the skills on your team and encourage folks to develop those skills if they don’t have them already.
Q: How much should dev teams be involved in goal setting?
A: I believe the dev teams should always be involved, at least to some degree, because people are more committed to goals that they participate in setting. There are situations where they might not have all the right context, like in the medical industry for example, and it might be harder for the dev team to set goals alongside a PM with a lot of domain-specific knowledge. But in that case I would invest in training so that everyone is on the same page. The more context devs have about the problems they’re solving, the better the product will be.
Q: What’s Asana’s framework for prioritizing team and company goals?
A: At the company level, we use three inputs: customer feedback, product vision, and resourcing capacity. We start by collecting insights from customer-facing teams and measure those against our product vision. This company was founded with a very clear vision: to make collaboration more effortless. Once we lock in on our company-wide goals, it’s up to each team to decide how they’re going to aim their work toward those objectives.
Q: How do you balance exciting engineering goals with business imperative engineering goals?
A: I’d start by inviting your engineers to think about how they can translate projects they’re excited about to projects that will move your business forward. Make them answer the why: Why does this project matter? What business value does that deliver? In most teams that I’ve seen, there’s room to do work that folks are excited about, it just requires some additional thinking. The other thing you can do is more future planning. If your team is excited about something that’s lower-priority, acknowledge it and show them where it fits in the roadmap down the line, then align them to the goals you need to achieve now.
Q: Any tips for setting diversity and inclusion goals on an engineering team?
A: Make your D&I goals a business priority. Unless you hold that belief from a business standpoint, it is going to get deprioritized. I also recommend teams solve inclusion first. Make sure the underrepresented groups that you do have are comfortable and feel welcome. Start with the assumption that they don’t feel 100% included in everything, and start fixing that.
Uplevel your goal setting process today
Feeling inspired by these tips? Tell us how your engineering team approaches goal setting in the comments below. Or, if you’re looking for a new framework to setting and tracking goals, download a digital copy of the Asana Playbook to OKRs to start making a bigger impact today.
