# How Asana's Head of Engineering Sets Engineering Goals - Inside Asana

> Asana Head of Engineering, Prashant Pandey shares his advice for setting clear, actionable engineering goals.

Source: https://asana.com/inside-asana/engineering-goals

## 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](https://www.youtube.com/watch?v=ZiQObCgshM4) 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](https://asana.com/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](https://asana.com/resources/real-talk-working-from-home) 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](https://blog.asana.com/2019/06/women-engineering-leadership/) 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](https://asana.com/templates/for/other/company-goals-and-milestones). 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](https://asana.com/trust), 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](https://asana.com/vision). This company was founded with a very clear vision: to make [collaboration](https://asana.com/uses/team-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](https://blog.asana.com/2020/05/building-inclusive-remote-culture/). 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](https://asana.com/teams/engineering) 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](http://asana.com/resources/okr-goal-management-ebook) to start making a bigger impact today.

- [Microframeworks in the Admin Console](/zh-tw/inside-asana/microframeworks-admin-console)

工程

每個 Asana 部署都有一個系統管理主控台。 IT 系統管理員可以在此處設定公司使用 Asana 的方式，例如調整密碼要求、角色和權限、是否可以從 Dropbox 附加檔案，以及在預設情況下誰可以看見新專案。隨著 Asana 的發展，系統管理主控台累積了多年的自訂邏輯和臨時拼湊的解決方案，導致建立和維護管理控制項的成本越來越高。 以其中一項管理設定為例： ...

- [以規格為導向的開發：優點以及我們在三個月後學到的經驗](/zh-tw/inside-asana/spec-driven-development)

工程

#### 主任軟體工程師

三個月後，我們更清楚地瞭解了新增的架構在何時有幫助，以及在何時成為阻礙。我們的一位工程師正在準備資料遷移，並決定使用規格導向開發 (SDD) 來規劃工作。 SDD 的用意是幫助他們及早發現疏漏，使方法更易於審查，並為客服人員提供明確的方向。 最終的計劃非常詳細，從紙面上看來相當合理。 它將工作組織如下：問題 → 研究 → 規格 → 審查 → 實施 → 驗證 ...

- [我們在 2 週內完成了 Enzyme 遷移。這本應需要五年的時間](/zh-tw/inside-asana/migrating-off-enzyme-2-weeks)

工程

我們最近使用 AI，在大約一次衝刺中完成了多年的工程工作。 以下是其方法，以及為什麼它改變了我們對可能性的看法。五年問題早在 2022 年，我們就著手將 Asana 的前端測試套件從我們老舊的測試庫 Enzyme 移轉至 React Testing Library (RTL)。 Enzyme 已經失去社群支援，無法與較新版本的 React 正常搭配，並且鼓 ...

- [AI 隊友如何建立記憶：將工作轉化為可重複使用的知識](/zh-tw/inside-asana/ai-teammates-turn-work-into-reusable-information)

人工智慧 (AI)

工程

大多數 AI 產品將記憶視為個人功能，記住關於一位使用者或一段對話的事實。 但跨團隊協作的 AI 需要一種截然不同的記憶。 當 AI 系統能夠在先前學習的基礎上再接再厲時，就會變得更加實用。 但在企業軟體中，記憶不僅僅是儲存更多內容的問題。 更困難的問題是，讓記憶在共用工作中發揮作用，同時仍保持其可檢查、可治理且具有權限意識。這就是我們打算透過 AI 隊友 ...

- [10 tips for setting engineering goals from Asana Head of Engineering, Prashant Pandey](/zh-tw/inside-asana/engineering-goals)

工程

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 sa ...

- [工程](/inside-asana/engineering-spotlight)