How dbt Labs manages OKRs

At dbt Labs, we recently underwent a massive overhauling of our OKR (objective and key result) process. As a high-growth business with a quickly expanding team, we were experiencing shortcomings with our existing OKR framework, primarily around the tooling, self-service capabilities, and general OKR alignment between leadership and team goals. We’ll walk through how dbt Labs’ Data Team thinks about OKRs and why we decided to take the approach we took to create a new OKR process.

Spoiler alert: We ended up moving off of a SaaS tool to a (cue gasp) Google Sheets-based system to monitor our OKRs, but please–let me explain why and how that got us to a better place.

Why OKRs are difficult #

OKRs are a goal-setting framework that creates alignment between teams. The objective is the goal (“Be recognized as the greatest jaffle shop in Philadelphia”) and the key results are the metrics (“Grow clientbase 10% MoM and maintain an A+ Health Inspection score per quarter”) that indicate the status of completing that goal.

At dbt Labs, we describe objectives as the stories you want to tell at the end of the year and the key results as the check-ins to see if you’re progressing to that ending. However, along the way they should be adding context to what led up to us achieving (or not achieving) the objective.

For many leadership and data teams, OKRs are the core group of goals and metrics they use to understand the health of their business. By creating an OKR framework, teams and individuals can more clearly identify and prioritize high-value work and understand how that work aligns with greater company goals.

That’s great and all, but let’s be honest: OKRs get a bad rap. For both business users and data teams, they’re typically hard to identify, set-up, and regularly monitor.

At dbt Labs, we also felt major dissonance with the tooling, self-service capabilities, scalability, and accountability of our previous OKR framework:

• The tool: The SaaS reporting tool we were using for OKRs had an incredibly high barrier of entry and lacked flexibility. Business users had to rely on the Data Team to update the queries used to calculate KRs or even pull the data to report on the KRs. As a result, there was a major absence of self-service capabilities with this tool.
• The mystery: Once folks could look at how OKRs were tracking, there was a lack of clarity on how they should proceed. What if someone wanted to explore this data themselves? What were the calculations and queries used? Where would they start looking in our BI tool?
• The growth: At the beginning of 2021, dbt Labs was around 50 folks. At this size, most people had the historical knowledge and business context to understand metrics and business terms. As we’ve grown to 200+ people, creating a system that allows people to develop context was becoming challenging.
• The alignment: Some teams had built team-level KRs that cascaded from the company-level KRs, but that wasn’t universal across all teams. How could teams understand their impact if they couldn’t align it with the company’s goals?

Once we identified these problems, it became clear that we needed a different process that would allow us to create better alignment between team and company goals, support self-service analytics, and hold leadership members accountable for OKRs.

The OKR process at dbt Labs #

To quote Janessa Lantz, our VP of Marketing, “At the end of the day, it’s never enough to just put a dashboard out into the world.” In order to make the data actionable, our OKR framework would need to allow us to easily expose OKR performance, encourage data exploration, and ensure OKR owners would be held accountable for performance.

This led to some significant changes to our OKR process:

1. Implementing dbt metrics in our dbt project (!!)
2. Finding a new platform to serve our OKRs aka leveraging the Swiss army knife of modern technology, Google Sheets
3. Enforcing OKR ownership with monthly business reviews

Let’s break this down a bit.

dbt metrics for documentation

Our dbt models were already powering the data behind our existing KRs, but aggregations and calculations were made in our previous reporting tool. In this OKR revamp, we wanted a way to centralize documentation for our KR calculations. What better way than with dbt metrics? Now, we use dbt metrics to create consistent definitions and enforce ownership for OKR metrics.

For each OKR objective, we created a separate metric yaml file; for example, our first objective’s metric file is called o1_metrics.yml. Within each metric yaml file is the actual metric aggregation, time series specification, and relevant documentation for each KR in that objective.

o1_metrics.yml example metric:

metrics:
	- name: okr_1_kr_1_net_new_users
	label: Net new users
	model: ref('fct_users')
	description: '{{ doc(“okr_net_new_users”) }}'
	tags: ['2022 - O1']

	type: count
	sql: user_id
	timestamp: date_day
	time_grains: [day, week, month]
	meta:
		okr_level: 'Company'
		owner(s): 'Drew'
		team: 'Product'

The ability to add tags made it easier for business users to find specific quarterly KRs in dbt Docs. In addition, meta fields around ownership (owner and team) created greater transparency and accountability. Lastly, putting our KRs as metrics allowed them to be a part of the DAG: now, users could visualize all of the data sources and models impacting KRs.

We also made a separate markdown file for each objective (ex. o1_metrics.md) to create robust documentation around the objective and each KR. In each objective’s markdown file, we:

• wrote an overview of KR
• defined relevant business terms related to that KR
• provided detailed information on how that KR is calculated
• linked to any assets (BI tool dashboard link, Google Sheet link) related to the KR

Since these markdown files are available in both our git repository and dbt Docs, users could navigate through these files to find relevant information and assets more quickly.

We tip our hat to you, the humble Google Sheet

After working with the dbt Labs Leadership Team, we established the final vision of what we wanted out of this new OKR process—our version-controlled metrics definitions and documentation to be exposed in a platform that:

• allowed folks to view OKRs and their current performance
• acted as a central hub for all data assets (documentation and dashboards) for each KR
• connected back to our data warehouse
• and allowed an easy pathway for self-service analytics where folks could drill into dashboards for a deeper look into the metric inputs, understand how key metrics are calculated in the BI tool, and encourage independent explorations.

This OKR performance platform would ideally be a tool that has a low technical barrier or learning curve and allows stakeholders to perform their own self-service analytics work.

After some competitive research, we found our solution in our own backyard: Google Sheets. Surprised at how basic this is? Don’t be! Google Sheets are a bit of a jack of all trades and fit many of our requirements:

• Lowered the technical barrier: Teams would no longer need to rely on the Data Team to write a query to calculate a KR. Rather, they could pull the data from our BI tool and calculate their team-level KRs in a way that makes them most comfortable and feel the most empowered.
• Flexible for calculations: We could measure variances and the KR’s current status that makes sense for the KR within Google Sheets, and stakeholders had the ability to view those calculations.
• Consolidated data assets: We could link to related dashboards, dbt Docs on metrics and models all within a single place. This would allow for more stakeholder self-service motions since they can investigate on their own when they see a metric underperforming or overperforming. It also means for new folks they can have all the resources they need for OKRs in a single place.

We ultimately decided on creating a detailed Google Sheet for each KR and having the aggregated values from there linked to an OKR “Hub” sheet that would show a quick view of current performance for all OKRs.

Side note: using Google Sheets was also a humble reminder—sometimes simpler is better.

Bringing it all together

Let’s check on what we had done so far:

• Documented all the KRs in with dbt metrics
• Decided on Google Sheets as the hosting platform for KR tracking

The only thing left to do at this point was to bring it all together, or more clearly, pipe down KR performance numbers into their respective Google Sheets. Let’s get into it!

Note: While we’re using fake, randomly-generated data for the screenshots below, they represent what we do internally for syncing KR performance to Google Sheets.

1. Created separate dashboards in our BI tool to track performance for every single KR. These dashboards provide historical and current performance for their KR and are viewable by anyone within our BI platform.

1. Scheduled these dashboards to copy into their respective Google Sheet on an automated daily cadence. We add some quick aggregates and percentages in the individual KR sheet to provide a quick performance overview.

1. Created the OKR “hub” Google Sheet that would simply pull the data from each KR sheet to compile an overview of OK performance.

Now, users could get a quick overview of all OKR statuses, look at specific KR performance, and explore the data all from a single area. Is it the most extravagant interface you’ve ever seen? Probably not. Is it incredibly intuitive and navigable? We think so. In this case, function won over form.

Training and holding our team accountable

We just spent all this time setting up part of dbt metrics, creating new data models, making all the dashboards for KRs, and getting them down to Google Sheets. People are just going to go and use them regularly, right? Well…

Like all data work, there was some enablement that needed to happen to onboard folks and encourage usage. For the majority of business users who are likely not looking at the OKR performance everyday, we created Loom videos to show folks how to navigate the Google Sheets and find all the information they may need. Because not everyone has time to look at the relevant assets, we also hold synchronous weekly data office hours that people can attend if they have any questions, such as using the OKR system.

For leadership team members and OKR owners, there was more active habit-building that had to happen. I became extremely involved in our monthly business review (MBR) meetings where each leadership team member will cover their OKRs’ performance. Embedded data team members started meeting monthly with their team leads to talk through why certain KRs are performing well and where others are struggling. Now, our data team is plugged into OKR work and leadership team members have a regular cadence at looking at OKR performance and digging into the data.

Reflecting on the future of OKRs at dbt Labs #

As I was working through writing this post, I was asked, “What was the biggest win from changing how we did OKRs?” As a data person(™), my initial reaction was around the fact that we created a usable, centralized, and true self-service hub for OKRs. But when I talked to leadership team members about this, they emphasized the accountability this project brought to them and other business users.

Looking and reviewing OKRs is now a regular practice for the leadership team at dbt Labs. Team leads are also now involved in OKR creation and tracking. Most importantly, we’re developing the muscle to identify more appropriate and trackable OKRs as a team.

We’ve barely scratched the surface of OKRs at dbt Labs and we still have a lot to learn about our business. I see a lot of opportunity for OKR improvement, primarily around team KRs and stakeholder education. Particularly, I’m excited for:

• Expanding team OKRs: I would love to see more teams with their own KRs cascaded underneath company-level OKRs. It’ll take time to get there, but our growing data team will help get our business folks there :)
• Centralizing data literacy: I literally dream about the day we create a dictionary of our business terms to use universally across OKR documentation. If you’re already doing this for your business, please hit me up on Twitter or the dbt Community Slack (@erica)—I’d love to hear your thoughts!

Overall, overhauling the OKR process at dbt Labs was an incredible opportunity to start exploring dbt metrics, remind ourselves that sometimes simpler is better, and develop greater accountability for OKRs.

Last modified on: