Let’s say we can split a technology venture (software, biotechnology, hardware, etc.) into three parts: (1) the research & development (R&D) part, which comprises the product, engineering, design, and research; (2) the business development part, which comprises the sales, marketing, and customer success functions; (3) the back office part, which comprises operations, legal, human resources, and finance functions.
This paradigm inherently simplifies overlaps between functions, but if we accept the philosophies of Steve Blank, Y-Combinator, lean entrepreneurship, etc. as guiding principles for an efficiently run technology venture, such a division of responsibilities makes sense. You need the organization that produces your offerings, the organization that takes the offerings to market, and the organization that maintains the company.
With this set-up in mind, the evaluation of performance is a key question for any leadership team to answer. How do we actually evaluate performance across teams? How do we set objectives to ensure that teams are held accountable for execution, and that teams have a common understanding of what results to navigate towards?
This is where OKRs (objective-key results) tend to be deployed.
An OKR is a set of high-level objectives, key results that map to those objectives, and initiatives that map to those key results that are set by senior leadership of each division within a company on some regular cadence (e.g., annually, quarterly, etc.). The common or intuitive approach for setting OKRs starts with each function head (VP of Product, Head of Engineering, etc.) working with their teams to determine reasonable OKRs that support senior executives’ company-wide goals. Typically, each team sets its own OKRs and is solely responsible for its own OKRs.
However, this common or intuitive approach, especially in the technology world, is at best, inefficient, and at worst, can be extremely counterproductive to the success of the company.
In technology ventures, R&D organizations need to operate cross-functionally in order to deliver a product that (1) satisfies the business requirements, (2) meets technical requirements, (3) delivers usability to the end-user – product, who surfaces business, end-user, and market insights, determines the vision, scope, and objectives of a development initiative; engineering, who internalizes these objectives and provides technical estimates and roadmaps for each initiative; design, who internalizes the end-user persona and provides a recommended UI and UX that optimize value for the end-user. While these are broad strokes of responsibility, the key point is that the optimal value of delivery across an organization requires alignment within R&D.
And this logic ladders up to the trisected view of the company as well: R&D has to work with business development to determine market demands, customer requests, go-to-market etc. R&D has to work with the back office to fulfill people operations, protect IP, formalize moats, etc. Business development has to work with the back office in order to hire the right resources, manage existing roles, ensure their use of resources maps to commercial opportunities, etc.
As you may now suspect, OKRs set independently within each organization promote execution and strategies that don’t necessarily support one another.
The discussion around evaluating performance tends to start with quarterly/annual OKRs that different functions (e.g., sales, engineering, product, people operations, etc.) within a technology company are tasked to reach. While the “objective key results” approach for goal-setting is useful to promote visibility and accountability across functions, it does little to incentivize or promote cross-functional efficiency. If the engineering organization has a set of delivery OKRs, design has its own OKRs, and product has its own OKRs, the core R&D half of the company is split among different objective functions which may or may not necessarily be aligned with each other. As a result, managers within each organization may not be targeting the same or symbiotic activities across organizations.
I’ve seen this “OKR” trap emerge in nascent, growth-stage technology companies, and it can seriously hamper or confuse the objectives within each function in a company, especially within the R&D side of the house. If engineering sets a suite of objectives for delivery, but their delivery goals are not tied to the insights of the product team or the inputs of the design team, they are effectively pushing efforts into the delivery of items that don’t have market validation, that don’t have end-user validation, etc. If the business development side of the house sets sales objectives that don’t map to realistic product delivery, they run into a conundrum of either rolling back customer dialogue or over-promising results that can’t be delivered.
So how do we avoid this trap?
OKRs should first be set at the company level; then at the trisected piece of the house level (i.e., business development, research and development, back office); then at the function level. That way an organization can ensure that each set of OKRs feeds into a unified vision for where a company should devote its resources.
To make this concrete, let’s imagine a technology venture that builds authentication-as-a-service; their end-users are IT teams and developers, and they are industry agnostic, although their current customer profile are large non-technology companies that are building technology services for their customers. Let’s say this venture is setting its OKRs for the new year.
In the new proposed approach for setting OKRs, senior leadership starts by setting OKRs that dictate the strategic priorities of the company: the objective may be to grow ARR by 20% without increasing operational costs by more than 10%, and the key results may be to secure 5+ new flagship enterprise customers and unlock a new service that can be upsold to existing customers.
Then, within each trisected portion of the company, OKRs would be set. The R&D side may set the objectives of (1) reducing delivery costs and (2) identifying the MVP of a new service to be upsold, with key results being (1) reducing deployment costs by 20%, (2) interviewing 20+ potential customers and end-users to identify business requirements for an MVP, and (3) designing the prototypes for an MVP to run commercial experiments. As such, it’s not difficult to imagine other portions of the company setting OKRs that feed into the overall company strategy, as well as specific functions within each portion determining OKRs that fit into their portion’s OKRs.
Altogether, by mapping OKRs to the strategic vision of the company as well as to the specific responsibilities of each function within a company, a common language is established across managers of different functions with respect to what should be prioritized. This language then allows managers who are interdependent in the execution of objectives for a company to generate initiatives that are actually cross-functional, and not nominally labeled as such. Further, managers would be able to make resourcing decisions that support the collective insights across teams and drive towards the mutually agreed upon outcomes, rather than assuming full ownership of driving the company towards its outcomes (and thus, making decisions from a single perspective).
Every organization needs a mechanism of accountability. And while it may make sense for each class of roles within an organization to set its own objectives, such thinking overlooks the interdependence between organizations to deliver the best results to shareholders, customers, and end-users. As such, accountability alignment should be thought of as a hierarchy of results, not just within the OKRs themselves (objectives, key results, initiatives), but holistically within the company and its constituent organizations.
nah