Goals Planning for your DevRel Team using OKRs

Goals Planning for your DevRel Team using OKRs — 12 minute read

Setting and achieving meaningful goals for a DevRel team is a complex challenge. It is an integral part of DevRel strategy, and must be done right.

This article introduces you to the OKRA framework. This is a method for planning Objectives and Key Results (OKRs) for your team. The additional “A” is for emphasis on actions. This framework is the result of about 5 years of iteration. It is a hands-on, spreadsheet-centric, approach to planning. It can be applied to any team that uses OKRs - and this article draws from specific examples that relate to DevRel teams. We will round off with goal setting tips, and strategies to plan and execute them well.

Time to plan your team’s goals effectively! Let’s begin with a step-by-step guide.

Goals

The heart of goal setting in OKRs is two-fold:

  • Choose goals that matter
  • Work out how to measure progress towards these goals

That is really all there is to it - but it is far from simple to do those two things right.

The OKRA framework builds on OKRs. It front-loads thinking about the actions required to attain those goals. In my experience, the number one reason that OKRs fail is usually not a lack of productivity (as one might assume). Instead, they tend to fail when goals are planned improperly. Usually: Not considering how to accomplish them, or lacking enough detail. If you have thought to yourself, “Why are we even working on that?” … this is likely the underlying reason. Goals need to be SMART.

SMART

The is an acronym for: Specific, Measurable, Achievable, Relevant, Time-bound. A well defined goal should have all these traits.

These traits are merely descriptions of an ideal. However, it is very hard to bake a cake by looking at a picture of one. It is much easier to do so by reading a receipt.

The OKRA framework is that very recipe for SMART goals. Imagine a table where:

  • The rows are your list of goals. This is the cake.
  • The columns are attributes that prompt you to think about those goals. Methodically. These are the recipe ingredients list.
  • The cells are filled in by following step-by-step instructions. Re-iteratively. These are the recipe directions.

OKRA spreadsheet - completed example for a hypothetical DevRel team

This comes in the form of a spreadsheet. Once you work through it, you will have a list of SMART goals for your DevRel team.

Getting Started

  • Access the OKRA template spreadsheet.
  • Make your own copy of the template.
  • Now you’re ready to start customising it for your DevRel team!

The Process

The columns in the spreadsheet are grouped into six groups:

  • Group 1: Goals
    • Objectives: The goals
    • Key Results (KRs): Metrics for the goals
    • Type: Lead or lag
  • Group 2: Metrics
    • Start Value: Value of the metric at the beginning of the cycle.
    • End Value: Target value of the metric at the end of the cycle.
    • Units: The thing that gets counted.
  • Group 3: Actions
    • Preparatory Actions: Prerequisite tasks that do not necessarily improve the metric.
    • Metric Actions: Tasks, which when performed, should improve the metric. (Not applicable to lag metrics).
  • Group 4: Definitions
    • Measurement: Define the method for counting/ measuring the metrics, and where it will be recorded.
    • Notes: Additional details about the KR.
  • Group 5: Resourcing
    • Responsible: Responsible for the correct completion of the KR.
    • Accountable: Answerable for the correct and thorough completion of the KR.
    • Consulted: Opinions are sought about the KR, typically subject-matter experts.
    • Informed: Kept up-to-date on progress.
  • Group 6: Timeline
    • Start Date: When the KR begins.
    • End Date: When the KR should be completed by.
    • Status: On track, behind schedule, et cetera.

These groups should be addressed in batches. After completing each group, revisit and iterate on values in the previous groups. For example, after completing “Group 3: Actions”, revisit “Group 1: Goals” and “Group 2: Metrics”.

The details about how to fill in each column and group are provided in the spreadsheet itself.

You can also watch my demo based on a hypothetical DevRel team. It shows the process of completing this spreadsheet, with commentary.

Intro to OKRs - OKRA for DevRel teams - DevRel Strategy

For reference, this is the example completed in the video.

Tips

Filling in the spreadsheet following the step-by-step instructions is rather mechanical. This involves a very logical or mathematical mindset/ approach. However, doing that alone will not yield the best outcomes when planning goals!

Better outcomes are achieved through thinking laterally, and incorporating higher level considerations. These considerations can be grouped into:

  • The design of KRs,
  • resourcing, and
  • wider integration.

Note that this is not intended as an exhaustive list. Rather, they are examples of the types of considerations. They should be used as inspiration for employing further considerations of your own.

Design of Key Results

Split or join KRs:

When creating KRs, sometimes there are two (or more) of them that are very similar. For example, they may have similar names. Or their actions may have significant overlap. If this is the case, consider joining them into a single KR. On the other hand, some KRs may not “feel right”, or they may seem “confused”. For example, there is no clear unit for the value that is being measured. Or that the actions have a clear split into different sets of activities. If this is the case, consider splitting it into two (or more) KRs.

Think of SMART principles:

The step-by-step approach of the OKRA approach holds your hands to a large extent. This does not substitute for actively considering SMART principles though. Continue to think critically about these principles. Apply them in each iteration of a group of columns.

Measuring outcomes vs work:

There is a field of thought which avoids goals which measure the output of a team. This tends to be popular among product managers (PMs). Instead it exclusively focuses on goals which measure the outcomes of a team. This is great in theory. However, in practice, I have found that this works far better at the upper management level. This works less well in a team that includes individual contributors.

This is why there is a “type” column in which each KR is either a lead or a lag. Consider having a mix of leads to lags. It is best to have this mix proportional to the mix of managers to individual contributors. If there are too many of one type or the other, reconsider the selection, or design, of your KRs.

Revisit TODO items:

During the planning stage, we need to fill in for each of the attributes of a KR. However, in the initial plan it is almost impossible to know the granular details needed by OKRA. It is fine to make assumptions or educated guesses. Perhaps better, even.

How to do this without losing momentum or getting too side-tracked? Simply add TODO as markers to come back to. Sometimes placeholders are necessary.

After the initial plan is completed, it is critical to revisit these TODO items. The assumptions must be validated. The educated guesses must be replaced with the actual values. The placeholders must be followed up on. If there is a proof-of-concept needed, begin a spike on it - before the start of the planning cycle.

Resourcing

Pick appropriate time periods:

By default, we tend to use the same time period across all KRs in the spreadsheet. For example, for quarterly OKR planning, all KRs match the upcoming quarter’s dates. This may seem sensible, but is a common trap that results in poorly designed goals. When completing the final group - which includes start date and end date - always revisit the start value and end value.

Also consider who will be resourcing the actions (primarily responsible). Ask whether it is feasible to accomplish this goal in this time period with these resources. If not, either extend the time period, or decrease the change in the values.

Note that there is also a third option, which is to increase resourcing. But this option is typically unavailable. Exceptions: When you have a new hire, or you are able to convince other teams to allocate your team their resources.

The two types of actions:

Consider resourcing for the preparatory actions and the metric actions separately. By definition, it is very hard to impossible to work on these concurrently. This is because the preparation is usually a prerequisite to the rest of the KR being executed. Sometimes, the preparatory actions themselves need significant time or resourcing. You may estimate that it will take as much time as the metric actions.

If this is the case, you will need to consider removing that KR altogether. Or replacing that KR with a version of it that only focuses on the preparatory actions. Perhaps with a view towards tackling the metric actions in the next OKR cycle.

Assign to teams/ sub-teams:

… rather than to individual team members during the planning stage. This results in fewer factors to consider. It serves to reduce the decision workload during the initial plan.

Reassign to individuals post-planning:

After the initial round of planning is complete. The team should discuss which individuals should be involved in each KR. Use RACI: Responsible/ accountable/ consulted/ informed.

Some individual members may be allocated to specific DevRel sub-function areas. When this is the case, this will be straightforward. Sometimes, this is an opportunity to consider allocating differently too. For example, in a Developer Education KR, the Developer Success members may be jointly involved.

Wider Integration

Top-down vs bottom-up:

Top-down planning in this context is where the organisation as a whole plans its OKRs. Which cascades down to its top-level functional areas. Which finally cascades down to the individual teams. This tends to work well in the general sense, but not too well for DevRel teams. For the top-down approach to work well, top level management needs to understand what individual contributors do. For say, a software engineer individual contributor, this works out well.

However, for a DevRel individual contributor, this usually is not the case. DevRel is a relatively newer, relatively more niche function within technology companies. Thus, top-level management rarely understands it well.

Consider where DevRel sits within the organisation:

To complicate things further, the DevRel function is atypically multi-faceted. Even at an individual contributor level. It is quite common for DevRel to sit underneath another top-level function. For example, under product or marketing. When this happens, the other facets of DevRel tend to be deprioritised. For example, marketing facets may get deprioritised when DevRel sits under product.

To solve this, it is better for DevRel to plan its OKRs bottom-up. Subsequently, connect it to the top-down plan from the organisation, meeting somewhere in the middle.

Rollup metrics:

DevRel’s OKRs are slotted into the wider organisation’s OKRs, as with any other team. Multiple KRs get “rolled up” into a single objective of the hierarchical level above it. Anticipate this, and refactor the team’s OKRs accordingly. For example, during the initial planning stage, you may have KRs grouped into objectives.

These objectives may be based on DevRel sub-function areas. If you peek at the OKRs one level up, you may find that there is no natural alignment. If so, shuffle the grouping of the DevRel team’s KRs into objectives such that alignments are possible.

Team buy-in:

If you are leading a DevRel team, do not plan the OKRs for your team in isolation. Instead involve everyone, right from the beginning, on the team to hash out ideas for the KRs for the next cycle.

The team should consider all the following:

  • (1) OKRs from the current or previous OKR cycles,
  • (2) a brainstorm on new ideas,
  • (3) the wider organisational metrics, and
  • (4) resourcing availability during that time period.

In my experience, the most effective approach is to involved them from the get go

  • (1) Hold a retrospective meeting. What went well, and what did not, in the previous planning cycle? What does the team think it should start doing, and stop doing, in the next cycle?
  • (2) Hold a kick-off meeting. Explain the exercise - either for the first time, or a recap. Conduct a brainstorm.
  • (3) Make a copy of the spreadsheet from the template, and share edit access with the team.
  • (4) Task each team member to come up with between 3 to 5 KRs, asynchronously. The team may already have assigned DevRel sub-function areas. For example, Developer Marketing, Developer Education, Developer Success. If so, each member should focus on their dedicated areas.
  • (5) Hold a finalisation meeting. The team discusses the pros and cons of each KR and decides what to keep, change, or delete. Importantly, all KRs must have no ambiguity (especially TODOs).

Next

That is a wrap!

If you are part of a DevRel team, please do try out the OKRA framework in your next iteration of goal setting as a team.

Get a copy of the OKRA template; or take a look at the completed example.

I would love to hear how it worked out for you/ your team (both good and bad)! Drop your comments on this article itself. Or reply to the tweet about this article. Or leave a comment on the youtube videos accompanying this article.

Thanks

Thanks to Owanate Amachree, Bianca Buzea, and Joshia Seam for reviewing this article.