<ul><li>Business and product strategy. As a principal engineer, it’s important to understand the overall strategy for your group and what you can do to support the goals it’s trying to achieve.</li><li>Team needs. Although you’re not part of a specific team, you’ll find yourself working with many teams across the business to achieve your goals. To prioritize effectively, identify the needs of the teams you work with most closely. </li><li>Engineering org needs. Are there problems within the org that you could help with? Look out for initiatives that particularly interest you or that could help you develop some of your growth areas.</li><li>Personal goals. Consider your personal goals. Identify your strengths, goals you haven’t yet achieved, and areas you might need to improve, and incorporate feedback you’ve received from your manager and peers. </li></ul>

Setting and prioritizing goals as a principal engineer

Prioritize by identifying risks associated with each of your inputs. Within the business and product strategy, some examples of these risks could be:<ul><li>Financial risks or strategic risks.</li><li>Technological risks: the business may have taken on complex projects, or started to explore a new problem space.</li><li>Operational and team risks: look out for teams without enough engineering support to achieve their goals, where your help might be incredibly valuable.</li></ul>

Prioritize by risk

<figure><img src="https://blog.intercomassets.com/blog/wp-content/uploads/2021/07/Setting-goals-as-a-principal-engineer-1-1800x840.jpg.optimal.jpg" alt="Setting goals as a principal engineer (1)" width="785" height="366"></figure>When you’re part of a team, you adopt the goals, objectives, and priorities of that team. As a principal engineer, you can effectively be operating as a team of one – and that makes it a little trickier to manage your time.&nbsp;At Intercom, we believe that a principal engineer should “set goals autonomously and at the level of scope and ambition usually associated with a team.” Before, you worked towards team targets – now you’re in charge of setting and keeping track of your own goals, agenda, and personal growth.&nbsp;<h2>How often should you set goals?</h2>Before joining Intercom, I worked as a tech consultant and had to account for every day to the client. It helped me to become more aware of the <a href="https://www.intercom.com/blog/continuous-flow-weekly-planning/" dir="ltr">importance of planning</a> and how to <a href="https://www.intercom.com/blog/embracing-the-deadline-how-engineers-benefit-from-delivery-dates/" dir="ltr">use my time more effectively</a>. It also meant that I started my principal engineer role at Intercom with goal-setting and time management habits already formed.As a company, Intercom sets quarterly goals (twelve-week periods) and cycle goals (six-week periods), so it makes sense for me to do the same when setting goals as a principal engineer. I share my quarterly goals with everyone I work with, then break them down into commitments for each cycle, which I share with my manager. I also set weekly goals to keep myself organized. It helps to break down large, abstract goals into achievable steps and makes it easier to track progress.<h2>How do you choose your work?</h2>Coding is just one of the many things a principal engineer works on day-to-day. You’re expected to develop a wide understanding of overall strategy and use it to decide what’s most urgent and important. At the same time, because you’re overseeing these wider strategic areas, you’re not part of daily team rituals like standups anymore – so you need to ensure you’re keeping up with essential context for your work.<BLOCKQUOTE>“There will always be an endless supply of low-effort, low-impact work to “snack” on – look past that to find the high-impact work”</BLOCKQUOTE>Without effective organization and planning, you can end up spending your time on small, low-impact tasks that build up to fill your days. There will always be an endless supply of <a href="https://www.intercom.com/blog/first-rule-prioritization-no-snacking/" dir="ltr">low-effort, low-impact work to “snack” on</a> – look past that to find the high-impact work. There is rarely a “high-impact backlog” ready to go, so you’ll often have to create it yourself. Here are the four main inputs I consider when building that backlog.<h3>Business and product strategy</h3>At Intercom, we identify teams working within the same area of focus or strategy as a “group”. For example, the “automated support group” includes a range of teams focusing specifically on optimizing every aspect of the automated customer support function within the Intercom product. As a principal engineer, it’s important to understand the overall strategy for your group and what you can do to support the goals it’s trying to achieve. Identify your group’s focus and how it fits with that of the wider company. Explore what’s coming up over the next quarter and year, and identify the risks and opportunities that may arise.&nbsp;<h3>Team needs</h3>Although you’re not part of a specific team, you’ll find yourself working with many teams across the business to achieve your goals. To prioritize effectively, identify the needs of the teams you work with most closely. They will already be aligned with the wider product strategy, but it’s important to identify any executional challenges they might have, ambiguous projects you could assist with, or teams that need more support to achieve their goals.&nbsp;<h3>Engineering org needs</h3>Are there problems within the org that you could help with? For example, is the engineering org encountering recruiting roadbumps, broken processes, or operational issues? Look out for <a href="https://www.intercom.com/blog/product-engineer-impact/" dir="ltr">initiatives that particularly interest you</a> or that could help you develop some of your growth areas.<h3>Personal goals</h3>Finally, consider your personal goals. Identify your strengths, goals you haven’t yet achieved, and areas you might need to improve, and incorporate feedback you’ve received from your manager and peers. For each strength, think about what you need to do to reach the next level and how each potential project might help you to grow in some way.<h2>Prioritizing your work</h2>Now that you have a list of high-impact work to tackle, how do you decide what’s most important? Prioritizing doesn’t mean choosing what to spend most of your time doing, it’s deciding the items on your list that you may need to drop everything else to work on – the <a href="https://www.intercom.com/blog/move-fast-and-optimize-for-the-long-term/" dir="ltr">trade-offs</a> you’re willing to make. For me, those are the business and product strategy needs. If that area isn’t doing well, then other inputs will almost certainly suffer – so these are my priority.&nbsp;<BLOCKQUOTE>“Look out for teams that don’t have enough engineering support, where your help might be incredibly valuable”</BLOCKQUOTE><h3>Prioritize by risk</h3>Continue to prioritize by identifying risks associated with each of your inputs. Within the business and product strategy, some examples of these risks could be:<UL><LI>Financial risks or strategic risks.&nbsp;</LI><LI>Technological risks: the business may have taken on complex projects, or started to explore a new problem space.&nbsp;</LI><LI>Operational and team risks: look out for teams without enough engineering support to achieve their goals, where your help might be incredibly valuable.</LI></UL><h3>Factor in your personal goals</h3>Once you’ve identified risks across your inputs, align your priorities with your personal goals. Which projects do you want to drive, which are you passionate about, and which will help you to <a href="https://www.intercom.com/blog/grow-your-team-by-focusing-on-strengths-not-weaknesses/" dir="ltr">build on your strengths</a> and improve in the areas you’ve identified?&nbsp;<h3>How can you nurture other engineers?</h3>Think about what you could delegate to other team members. Part of the role of principal engineer is to nurture other engineers. If you’ve built a list of impactful work that could help other engineers to grow, it’s important to share. This is the point where I would usually talk to engineering managers to find out if this work could help their teams develop in any way.<h2>Writing up your first draft</h2>You’ve had the important conversations, you’ve created your backlog, and you’ve prioritized your work – now it’s time to write up the first draft of your goals. I use a spreadsheet with a tab dedicated to each quarter, but you’ll be looking at this document a lot, so choose the format that makes most sense to you.&nbsp;At Intercom, each engineering career level is evaluated under several areas of competency, including ownership, <a href="https://www.intercom.com/blog/building-autonomously/" dir="ltr">autonomy</a>, and growth. I map each of my goals to the applicable competency areas to ensure that I’m addressing all of the performance requirements for my level.I evaluate my goals under five headings:<UL><LI>Engineering level competency area: here, I map the goal to the relevant competencies and impact areas of Intercom’s engineering progression track for my level.</LI><LI>Commitment: the task I’ve committed to.</LI><LI>Impact: how will the team or company be better off if I achieve my commitment?</LI><LI>Role: am I driving this work or supporting someone else?</LI><LI>Priority: is this a main or secondary goal? Would I drop everything else to attend to this goal?</LI></UL><h2>Share it around</h2>Decide who should have oversight of your document, and whose input will be most valuable. Once my first draft is complete, I share it with my manager, peers within my focus area, and people I work closely with in the wider org. I take note of their feedback and rewrite my document as many times as I need to. It’s a great opportunity to align focus with other teams in the company and to seek advice on other areas I should be thinking about.&nbsp;<h2>Set expectations</h2>Send the finished document back to the people who offered feedback and anyone who should be kept informed of your work. For teams I work with closely, I’ll usually include a document providing more detail on my focus for the quarter. This is a perfect place to reiterate the nature of the principal engineer role and set expectations as to how much, or how little, you plan to be involved with each project.For example, when the automated support group was forming within Intercom, I worked closely with them to help build the team’s structures and processes. Once they were more established and stable, I stepped out to focus on other projects.&nbsp;<h2>When things change</h2>If someone asks you to do something, it can be difficult to decide whether to change your plan or stick to it. The first thing I usually do is seek out context for the request. Has a company or team priority changed? If so, I might need to revisit and re-prioritize my work.Secondly, can the request be delegated to someone else with more availability? If not, decide if it’s possible to say “not no, but not now” and use the request as an input for your next goal-setting period.<h2>There are many benefits to planning in this way&nbsp;</h2>This method of planning has become an invaluable tool to help me focus on impactful work. Prioritizing tasks gives you more confidence to reschedule less urgent work to make room for higher-impact tasks. If you know what you want to achieve, it’s much easier to <a href="https://www.intercom.com/blog/product-strategy-means-saying-no/" dir="ltr">say no</a> to less important tasks and projects.<BLOCKQUOTE>“Because I tie each goal to a requirement for my engineering level, this document is a useful guide when it comes to self-assessments and performance reviews”</BLOCKQUOTE>Additionally, because I tie each goal to a requirement for my engineering level, this document is a useful guide when it comes to self-assessments and performance reviews. It clearly lays out what I did, who I collaborated with, and the impact that it had.Finally, it helps me to set expectations for each team I work with as a principal engineer. It details my role within each task or goal and how high it is on my list of priorities. Each team knows exactly where they stand and what to expect.Although the planning stages can be time-consuming, laying out your goals – and the steps you’ll take to complete them – will save you from spending time on low-impact work.&nbsp;Are you interested in <a href="https://www.intercom.com/careers" dir="ltr">joining Intercom</a>&nbsp;as an engineer? We’re hiring.&nbsp;<img src="https://blog.intercomassets.com/blog/wp-content/uploads/2019/07/Careers-at-Intercom-2019-updated-images.jpg.optimal.jpg" alt="Intercom careers" width="434" height="195">

As a principal engineer, it can be difficult to manage your time. Here are some tips for setting and prioritizing goals.

productivity

Productivity

timemanagement

Time Management

computerscience

Computer Science

When you’re part of a team, you adopt the goals, objectives, and priorities of that team. As a principal engineer, you can effectively be operating as a team of one – and that makes it a little trickier to manage your time.

At Intercom, we believe that a principal engineer should “set goals autonomously and at the level of scope and ambition usually associated with a team.” Before, you worked towards team targets – now you’re in charge of setting and keeping track of your own goals, agenda, and personal growth.

Before joining Intercom, I worked as a tech consultant and had to account for every day to the client. It helped me to become more aware of the <a dir="ltr" href="https://www.intercom.com/blog/continuous-flow-weekly-planning/">importance of planning </a>and how to <a dir="ltr" href="https://www.intercom.com/blog/embracing-the-deadline-how-engineers-benefit-from-delivery-dates/">use my time more effectively </a>. It also meant that I started my principal engineer role at Intercom with goal-setting and time management habits already formed.

As a company, Intercom sets quarterly goals (twelve-week periods) and cycle goals (six-week periods), so it makes sense for me to do the same when setting goals as a principal engineer. I share my quarterly goals with everyone I work with, then break them down into commitments for each cycle, which I share with my manager. I also set weekly goals to keep myself organized. It helps to break down large, abstract goals into achievable steps and makes it easier to track progress.

Coding is just one of the many things a principal engineer works on day-to-day. You’re expected to develop a wide understanding of overall strategy and use it to decide what’s most urgent and important. At the same time, because you’re overseeing these wider strategic areas, you’re not part of daily team rituals like standups anymore – so you need to ensure you’re keeping up with essential context for your work.

“There will always be an endless supply of low-effort, low-impact work to “snack” on – look past that to find the high-impact work”

Without effective organization and planning, you can end up spending your time on small, low-impact tasks that build up to fill your days. There will always be an endless supply of <a dir="ltr" href="https://www.intercom.com/blog/first-rule-prioritization-no-snacking/">low-effort, low-impact work to “snack” on </a>– look past that to find the high-impact work. There is rarely a “high-impact backlog” ready to go, so you’ll often have to create it yourself. Here are the four main inputs I consider when building that backlog.

At Intercom, we identify teams working within the same area of focus or strategy as a “group”. For example, the “automated support group” includes a range of teams focusing specifically on optimizing every aspect of the automated customer support function within the Intercom product.

As a principal engineer, it’s important to understand the overall strategy for your group and what you can do to support the goals it’s trying to achieve. Identify your group’s focus and how it fits with that of the wider company. Explore what’s coming up over the next quarter and year, and identify the risks and opportunities that may arise.

Although you’re not part of a specific team, you’ll find yourself working with many teams across the business to achieve your goals. To prioritize effectively, identify the needs of the teams you work with most closely. They will already be aligned with the wider product strategy, but it’s important to identify any executional challenges they might have, ambiguous projects you could assist with, or teams that need more support to achieve their goals.

Are there problems within the org that you could help with? For example, is the engineering org encountering recruiting roadbumps, broken processes, or operational issues? Look out for <a dir="ltr" href="https://www.intercom.com/blog/product-engineer-impact/">initiatives that particularly interest you </a>or that could help you develop some of your growth areas.

Finally, consider your personal goals. Identify your strengths, goals you haven’t yet achieved, and areas you might need to improve, and incorporate feedback you’ve received from your manager and peers. For each strength, think about what you need to do to reach the next level and how each potential project might help you to grow in some way.

Now that you have a list of high-impact work to tackle, how do you decide what’s most important? Prioritizing doesn’t mean choosing what to spend most of your time doing, it’s deciding the items on your list that you may need to drop everything else to work on – the <a dir="ltr" href="https://www.intercom.com/blog/move-fast-and-optimize-for-the-long-term/">trade-offs </a>you’re willing to make. For me, those are the business and product strategy needs. If that area isn’t doing well, then other inputs will almost certainly suffer – so these are my priority.

“Look out for teams that don’t have enough engineering support, where your help might be incredibly valuable”

Continue to prioritize by identifying risks associated with each of your inputs. Within the business and product strategy, some examples of these risks could be:

<ul><li>Financial risks or strategic risks.  </li><li>Technological risks: the business may have taken on complex projects, or started to explore a new problem space.  </li><li>Operational and team risks: look out for teams without enough engineering support to achieve their goals, where your help might be incredibly valuable. </li> </ul>

Once you’ve identified risks across your inputs, align your priorities with your personal goals. Which projects do you want to drive, which are you passionate about, and which will help you to <a dir="ltr" href="https://www.intercom.com/blog/grow-your-team-by-focusing-on-strengths-not-weaknesses/">build on your strengths </a>and improve in the areas you’ve identified?

Think about what you could delegate to other team members. Part of the role of principal engineer is to nurture other engineers. If you’ve built a list of impactful work that could help other engineers to grow, it’s important to share. This is the point where I would usually talk to engineering managers to find out if this work could help their teams develop in any way.

You’ve had the important conversations, you’ve created your backlog, and you’ve prioritized your work – now it’s time to write up the first draft of your goals. I use a spreadsheet with a tab dedicated to each quarter, but you’ll be looking at this document a lot, so choose the format that makes most sense to you.

At Intercom, each engineering career level is evaluated under several areas of competency, including ownership, <a dir="ltr" href="https://www.intercom.com/blog/building-autonomously/">autonomy </a>, and growth. I map each of my goals to the applicable competency areas to ensure that I’m addressing all of the performance requirements for my level.

I evaluate my goals under five headings:

<ul><li>Engineering level competency area: here, I map the goal to the relevant competencies and impact areas of Intercom’s engineering progression track for my level. </li><li>Commitment: the task I’ve committed to. </li><li>Impact: how will the team or company be better off if I achieve my commitment? </li><li>Role: am I driving this work or supporting someone else? </li><li>Priority: is this a main or secondary goal? Would I drop everything else to attend to this goal? </li> </ul>

Decide who should have oversight of your document, and whose input will be most valuable. Once my first draft is complete, I share it with my manager, peers within my focus area, and people I work closely with in the wider org. I take note of their feedback and rewrite my document as many times as I need to. It’s a great opportunity to align focus with other teams in the company and to seek advice on other areas I should be thinking about.

Send the finished document back to the people who offered feedback and anyone who should be kept informed of your work. For teams I work with closely, I’ll usually include a document providing more detail on my focus for the quarter. This is a perfect place to reiterate the nature of the principal engineer role and set expectations as to how much, or how little, you plan to be involved with each project.

For example, when the automated support group was forming within Intercom, I worked closely with them to help build the team’s structures and processes. Once they were more established and stable, I stepped out to focus on other projects.

If someone asks you to do something, it can be difficult to decide whether to change your plan or stick to it. The first thing I usually do is seek out context for the request. Has a company or team priority changed? If so, I might need to revisit and re-prioritize my work.

Secondly, can the request be delegated to someone else with more availability? If not, decide if it’s possible to say “not no, but not now” and use the request as an input for your next goal-setting period.

There are many benefits to planning in this way

This method of planning has become an invaluable tool to help me focus on impactful work. Prioritizing tasks gives you more confidence to reschedule less urgent work to make room for higher-impact tasks. If you know what you want to achieve, it’s much easier to <a dir="ltr" href="https://www.intercom.com/blog/product-strategy-means-saying-no/">say no </a>to less important tasks and projects.

“Because I tie each goal to a requirement for my engineering level, this document is a useful guide when it comes to self-assessments and performance reviews”

Additionally, because I tie each goal to a requirement for my engineering level, this document is a useful guide when it comes to self-assessments and performance reviews. It clearly lays out what I did, who I collaborated with, and the impact that it had.

Finally, it helps me to set expectations for each team I work with as a principal engineer. It details my role within each task or goal and how high it is on my list of priorities. Each team knows exactly where they stand and what to expect.

Although the planning stages can be time-consuming, laying out your goals – and the steps you’ll take to complete them – will save you from spending time on low-impact work.

Are you interested in <a dir="ltr" href="https://www.intercom.com/careers">joining Intercom </a> as an engineer? We’re hiring.

Setting and prioritizing goals as a principal engineer

Setting and prioritizing goals as a principal engineer

Prioritize by risk

CURATED BY

Related collections

More like this