Getting your engineers engaged with OKRs

The Objectives and Key Results (OKRs) framework provides a great way for engineering orgs to cascade important goals through every level of the company.

Strategic themes – such as cost control and platform resilience enhancements – can be materialized in operational objectives such as reducing logs and implementing timeout policies.

The system creates a huge opportunity to get engineering teams contributing to a company’s wider objectives. But often, getting engineers engaged with OKRs is easier said than done.

At Farfetch, our executives set their goals, and how they’ll be measured, at the beginning of every half for the next six months. After that, managers and team leads like myself are expected to set objectives at our own levels that contribute to the higher-level goals. By the end of the goal-setting period, every engineer should have their own set of OKRs that address the company objectives.

The process has led to many wins for the company but has also presented some challenges. The main goal of any engineering team is to deliver their own initiatives and projects on time and with quality. If engineers are assigned OKRs that aren’t aligned with their key initiatives, even if they’re contributing to wider strategic goals, they will inevitably become side projects, and engagement can become a problem.

Having lived through a few of these cycles, I’ve learned a lot about what works and what doesn’t when it comes to getting engineers engaged with OKRs. I’m going to walk you through the key challenges I faced with my team and my solutions for overcoming them, before sharing a rundown of our OKRs successes.

Challenge 1: Setting the right goals

It’s not always easy to translate the company goals into things an engineering team can change or improve in their daily work or products. Examples of things that engineers can usually contribute include cost reduction, service desk tickets reduction, and technical evolution. The challenge for managers and team leads is to find ways to do this by setting objectives that engage and make sense to the engineers.

Of course, engineers are more likely to feel more engaged with tasks that make real sense to them. With senior engineers, it’s a good idea to involve them early on in the goal-setting process. Setting goals that really challenge the team is another great way to get their buy-in.

When defining the OKRs, it’s helpful to gather a list of possible challenges. I usually do the following:

• Reach out to the product managers to understand the goals they will address and whether they would benefit from some contribution from the engineering team. Since our engineering team is fairly business-oriented, they often welcome these suggestions given by the product team.
• Reach out to the principal engineer for ideas around short- or mid-term engineering opportunities that would contribute to their goals. These conversations often bring up technical challenges that engineers love to address, for example, proof of concepts (POCs), spikes, or studying a new area).
• Generate open ideas for ways we can develop our services in line with a company goal.

Once you have a list of potential goals, you can schedule some time to talk with the team and present and discuss the challenges. After almost two years of doing this, my team and I have created an open environment where even the engineers feel safe to bring their own ideas and challenges. After these meetings, each member is expected to define the goals that make the most sense for them.

It’s also a good idea to encourage OKRs sharing, which means a challenge can be addressed by more than one engineer. Having a partner to share an objective with reduces the workload and mainly improves the commitment to deliver it.

Challenge 2: Finding time for engineers to pursue OKRs

Because high-level OKRs are mainly side-projects for developers, carving out time for folks to work on them is a significant management challenge. You have to balance the immediate impact on key projects with the long-term impact on company goals.

In order to give space to the engineers to work on their OKRs, I always carve out bi-weekly slots for learning. Since some goals involve studying something new and applying it, or producing a POC or some documentation, this learning time is critical and a great weekly motivator.

For OKRs that are also meaningful in terms of product development, you can negotiate some additional recurring slots to tackle them. The same goes for OKRs that help the engineers prepare for future product-development projects (for example, getting familiar with a new technology or tool). These negotiations should happen between the team lead, the product area, and any other stakeholders. The closer the goals match with product development objectives, the easier it is to carve out time.

Our successes

Despite the challenges, my team’s OKRs have led to some big wins. After a couple of years applying the insights and ideas I’ve described, we were able to achieve the following:

• We modernized the test automation solution of the main service in our cluster to TestServer runner and WireMoq for mocking. This is an example of an OKR that saved significant pipeline time since the tests run faster. It was aligned with a ‘Platform technology evolution’ OKR in 2020/H2 for our back-office area.
• We proposed a new domain model for our main service. A group of engineers worked together to discuss the use cases, business concepts, and ubiquitous language, eventually proposing a new domain model. This was aligned with the same ‘Platform technology evolution’ OKR in 2020/H2. The following year, we were able to use the proposed domain model in a major refactoring of the service.
• We produced a POC of a report to the Service Desk area with details about how a particular service handles a request. A group of engineers worked together to develop an MVP with useful information, reducing the number of tickets escalated to our cluster. This was aligned with a ‘Service desk tickets reduction’ OKR in 2021/H2.
• We migrated some cluster services to a new pipeline model. A group of engineers worked together to configure some of our services to be built in this new pipeline model that would be faster and more flexible. This was aligned with a ‘Tools leverage’ OKR in 2021/H2.
• We gained knowledge in some key areas. A number of engineers took on research and knowledge sharing OKRs on topics including onion architecture (one engineer did a presentation for the back-office technical community) and contract tests (some engineers presented their research to the cluster with a POC).

Reflections

OKRs can be a useful management tool, allowing you to break the team routine; give your engineers opportunities to learn and apply new things; and work on tasks that would normally be difficult to add to the roadmap since they don’t have a direct impact on your product. 

It’s not always easy to get engineers engaged with OKRs, but since we started to apply the insights I’ve shared in this article, my team have reported that they see more value in the system, feel more engaged, and are more committed to achieving the goals. I hope you can learn from our experiences and that you see the same results.