The North Star Framework
The North Star Framework is a tool for connecting day-to-day work to business strategy. It is compatible with any goal setting frameworks (such as OKRs) to which it adds a layer of long term vision and stability. Indeed, whereas time-bound goals rarely exceed the quarter, your North Star remains relevant as long as your strategy holds.
John Culter’s North Star Playbook is the best place to learn about the framework:
A team using the North Star Framework identifies a single, meaningful metric and a handful of contributing inputs. Product teams work to influence those inputs, which in turn drive the metric. The North Star is a leading indicator of sustainable growth and acts as a connective tissue between the product and the broader business.
A company equipped with the North Star Framework has the tool to put day-to-day work into context. Echoes adds the practical way of materializing this link, from which many insights can be built:
- For leadership: visibility into how ongoing bets are distributed across the north star inputs.
- For product-engineering management: confidence that execution aligns with expectations.
- For individual contributors: a strong sense of purpose by showing connecting each piece of work to business strategy.
We will use Amplitude’s example from their own playbook to illustrate how to configure Echoes.
Product teams work to influence the inputs to the North Star metric. Echoes, on the other hand, lets you connect work items to what we call their intended outcomes. Intended outcomes are a customizable tree of desirable outcomes for your organization, which we can use to map our North Star inputs:
These intents are published across your product-engineering tools on which Echoes is enabled, such as:
GitHub repository labels
GitLab repository labels
JIRA custom field options
Linear issue labels
Echoes provides a consistent way to materialize the link between day-to-day work and the North Star, regardless of how individual teams choose to operate locally, and with minimal overhead.
As much as we may like 100% of efforts to contribute to our business strategy, reality tends to get in the way. A significant part of product-engineering work is about keeping the lights on and preserving our ability to deliver quality software sustainably. While not captured in the North Star Framework, neglecting these areas of work will inevitably lead to dire outcomes for the company.
How you want to capture these other transient intents as part of Echoes is up to you. By default, Echoes suggests two additional intended outcomes:
- Throughput: all changes intended at preserving our own ability to deliver software safely and sustainably.
- Risk mitigation: all changes intended at mitigating risk (e.g., fixing security issues, managing dependencies, or legal compliance).
Notice we have now grouped the North Star inputs under the North Star itself. This is not strictly necessary as no work should directly attempt to influence the North Star, but does help with readability.
As work gets tagged with its intent, Echoes automatically collects this data and gives you visibility into the activity through the lens of your North Star.
This table shows the evolution of the allocation of efforts over time (here on a month-to-month basis), aggregating the entire organization regardless of its size. All it took is for teams to label GitHub pull requests, GitLab merge requests, JIRA tickets, or Linear issues with their intent. In the spirit of aligned autonomy, local differences in how teams operate in terms of processes and tools doesn’t matter to Echoes.
Sizable organizations will want to see this data presented with a team breakdown. Echoes can show how efforts are flowing from the organization tree on the left, to the intended outcomes you have configured on the right, both in a diagram and a table form.
This insights are used:
- To communicate how product-engineering is allocating its focus to the entire company, using the universal language provided by the North Star.
- By product-engineering leaders to continuously assess whether execution on the field matches expectations. It helps detect when a team appears to be going off-rails without having to wait for the next checkpoint.
- By individual contributors to understand how their day-to-day work fits into the business strategy, giving a strong sense of purpose.
We can go further and map our time-based goals and bets, with two added benefits:
- Assisting individual contributors in linking their work to North Star inputs.
- Providing product-engineering managers with visibility into the allocation of efforts against ongoing bets.
Time-bound goals in Echoes are called initiatives. They can capture a milestone (such as a major release), a project, or the delivery of a sizable cross-team feature.
The composition of an initiative captures which outcomes it contributes to. In Amplitude’s playbook, one example initiative is the templating feature which affects the CoL (consumption of learnings) input. We will map this initiative in Echoes, defining that it contributes solely to the CoL input.
Like our North Star inputs before, this initiative will get published to your product-engineering tools in each platform’s most appropriate way. Work items labeled with the initiative will see their efforts ventilated on its components according to their respective weights, providing an additional layer of details in our understanding of the activity:
We can see in this graph how the efforts the Backend team invests in the templating feature is really contributing to the “Consumption of learnings” input, itself contributing to influencing our North Star Metric.
The North Star Framework is a powerful tool to communicate business strategy. Echoes is the perfect complement to materialize practically the link between the day-to-day work and the business strategy, through the lens of the North Star.
In the same spirit of aligned autonomy, Echoes overcomes the local differences in how teams operate but reveals how our efforts are distributed across North Star inputs. These insights are used to communicate what product-engineering is focusing on, to give confidence that execution matches our expectations, and to give individual contributors a strong sense of purpose.