Leveraging goal-setting to scale your impact as your team grows

The limits of individual contribution as an engineering leader

When your engineering organization grows, the way you lead must evolve. When I managed a few teams, I relied on being close to the work: attending daily stand-ups, reviewing specifications, monitoring alert channels, scheduling post-mortems, and facilitating retrospectives. If something was amiss, I could see it, step in, and lead the actions to rectify it. That approach worked when the team was small, but it does not scale: It became harder to stay involved in every detail with a department of 40 people and tens of products.

As I was prioritizing my work on strategic tasks, I started noticing some of what I considered “business as usual” not being done up to our standards: Post-mortems happened less often, alert channels became noisy, and some projects started without proper specification reviews. None of these issues was critical on its own, but together they weakened our system and eroded our engineering culture. Overall, our engineering department was not operating at the level I was expecting. One can easily start wondering why the teammates are not operating up to the standards that were set. After all, they had been operating as expected for a while now when I was closely working with them. Why aren’t they autonomous now? But I realized I had never clearly explained what success was to me, nor what my expectations were. I was ensuring things were fine by acting directly. When I could no longer do that, the system drifted because the direction was not clearly and properly set.

I knew I had to delegate; everyone knows that. But it’s much harder said than done, even if you are willing to do so. People need to know what “good” looks like and how their work connects to the bigger picture. That’s when I dived deeper into goal-setting practices: At that time, I read about stewardship delegation from The 7 habits of highly effective people by Stephen R. Covey and the OKR framework in Who does what by how much ; and I learned from other leaders how to truly be data-driven in everything we do.

Why aren’t they autonomous by now?

Teams were talented and motivated, but they lacked a clear definition of success. I was wrong when I assumed that, because they had operated well before, they would continue to do so. Clarity is about defining outcomes and expectations. When teams know what “good” looks like, they can make decisions to reach expectations without constant supervision. If no directions have been cleary set and shared with everyone, then everyone thinks they know what they should do ; but no one has the same version of it. So people don’t exactly align on priorities and on what matters. This is where frameworks helped me rethink the delegation approach:

• Start with Why by Simon Sinek states that purpose comes first: People need to understand why we invest in certain initiatives before discussing how we do it and what we do.
• Who Does What by How Much reinforced the idea of quantifying outcomes instead of listing activities. There is no point in shipping more pull requests if they don’t bring value. And it is not enough to say “Deliver more value”; you need to define what value is and how it is measured.
• Covey’s concept of stewardship delegation reinforced that delegation is not about handing off tasks but about transferring responsibility with clear expectations, guidelines, resources, measures of success, and known consequences (for success and failure).

These principles shaped the system I recommend to foster alignment with the company’s strategy, while building a sense of purpose, autonomy, and accountability. The multi-level goal-setting framework described below allows to connect strategy and execution.

The Multi-Level Goal-Setting framework

Here is the framework I recommend. As with every practice or ritual, it does not come together straight away; discrepancies between each team are expected, and it takes time to introduce all the parts. And of course, taking it as a golden standard and pushing it onto another company will likely fail. This is what is working for me, at the moment, in my current context. Still, I believe many ideas can help you to think about what you need. The following outlines the main ideas and principles of the structured framework.

Defining the North Star for a year

First, the senior leaders should define yearly objectives, similar to the “objective” part of the OKR framework. Those objectives set the “North Star” for the company or a large department to align all teammates with strategic themes. Those objectives should be inspirational, timeboxed, qualitative, and specific so that it motivates the teams to achieve a broader purpose, while focusing on a concrete direction. Those objectives are often directly business-oriented (for instance: “Offer the best ecosystem of WordPress products for small and medium-sized companies to build their website by the end of the year”), but some can seem more internally focused, though they ultimately serve the business purpose (such as “Achieve state-of-the-art development lead time in the web industry by the end of Q3”).

It is key that the number of objectives one person in the company has to pursue is limited. If each C-level creates their own five objectives, then chances are a single software developer will have to pursue or contribute more than ten objectives (CTO’s obejectives, CPO’s objectives, CEO’s objectives, etc.), which is unrealistic. I don’t think there is a strict limit, but the goal of objectives is to ensure teammates can efficiently focus on the top priorities of the company, so having too many of them defies this purpose.

While those objectives are qualitative, it may be interesting to associate a Key Result with them, so that a measure of success is defined already. Note that Key Results will be mostly leveraged in the next part of the framework to link the inspirational objectives to concrete metric changes, but it may be interesting in some cases to add one already at the yearly level.

Quarterly Roadmaps: Connecting Execution to Strategy

Quarterly roadmaps should link the inspirational yearly goals to concrete changes that we can measure so that teams can take action. One can use Key Results to set quarterly roadmaps: they measure progress toward the objective and should be based on measurable outcomes. Here are Key Results that could be used with respect to the previously stated objectives:

• 10% of customers buying “Product A” then try “Product B” within a week.
• Software developers do code reviews within 24 hours after the PR is submitted on average.

If we achieve those targets by the end of the quarter, we will have made progress toward our North Star. It might be a first step, in which case another Key Result will follow up on the next quarter.

The Key Result approach does not define how the target will be achieved; it only defines what success looks like, so that everyone shares the same conception of success and of the targets. Defining how to get there should only come once the Objectives and the Key Results are defined. The great benefit of this approach is that it allows teams to try approaches or start projects and initiatives to move toward the target, and to measure objectively if the results are as expected. If there are signs of metrics moving in the right direction, you can double down on your initiatives; otherwise, you have a clear signal that a conversation must happen regarding next steps: maybe you know it’s too early to see changes, or maybe you expected changes already, and they are not happening, so you might need to change your approach.

Weekly Goals

The last level of the framework is at the weekly/two-week levels with weekly (or sprint) goals. Every Monday, each team posts its goals for the week and reviews last week’s achievements on Slack, publicly. This usually takes the form of a list of two to five bullet points describing outputs, and delivering the output must be measurable. “Make progress on the database migration” is not a suitable goal, as it is not clear what the expected output will be at the end of the week. It was challenging at first to come up with measurable outputs, but it’s worth it to take the time to define milestones and break down the work. As a result, “perform the database migration on staging so that tests can begin on Monday next week” is a suitable weekly goal.

This practice created visibility, accountability, and alignment at the team level. Teammates know exactly what they have to achieve in the short term, which gives them the insights they need to prioritize their daily tasks efficiently, and it gives visibility to other teams about what is being worked on by the engineering teams, so they can anticipate.

This multi-level system—weekly goals, quarterly roadmaps, yearly objectives—creates alignment without micromanagement. It gives teams clarity on what success looks like and autonomy to decide how to achieve it: Teams can and must define at a tactical level (weekly / sprint) what tasks they want to get done; then they have metrics, with the key results, to assess whether the outputs they produce make the company move toward the desired outcome.

Ownership of goals

The different levels of the system are owned by different levels of management. Especially in large organizations, company-wide objectives and metrics are owned by senior leaders: they are the ones with the broader vision across all the teams and departments that contribute to the objectives, so they should be the ones owning them. Then, ownership of key results, objectives, and tasks should be at the smallest department’s or team’s level that has full control over the means involved in this goal: if the target is related to a specific product, then the team responsible for that product owns the goal. This ensures that the group owning the goal has control over all the resources needed to achieve it. It may not always be possible, especially if cross-department collaboration is needed for the goal. In this case, collaboration is key, and it’s worth considering forming a temporary “macro team” to achieve the goal, composed of the multiple teams needed.

Note that owning does not mean being fully responsible for; noone should be participating alone in any goals, we have teams for a reason. Owning here means being accountable for: the company trusts the owner to deliver the expected results, but many people or means can and should be involved! It’s the owner’s responsibility to raise awareness of the involved teams about their goal, identify needed resources, ensure the work is prioritized, the data is collected and analyzed, the plan is adjusted, etc. In other words, the owner fuels and drives the execution, but many contributors can be involved.

I have been reluctant to set specific owners for team goals. I was (and still am) a strong believer in the “team first” approach, and assigning a single person to a goal seemed against this approach. Why should one specific person in the team own the OKR? Shouldn’t the team own it? I still believe that ideally, the team should own it. However, in practice, I have seen this approach fail often due to a lack of ownership. If it’s everyone’s problem, it’s no one’s problem. Putting a name next to a goal makes things much more concrete, especially in teams that are not used to goal-setting and goal-driven roadmaps. This person feels a much stronger ownership and therefore has an incentive to drive the work towards the goal. When assigning a goal to someone, I recommend taking the time to emphasize that owning does not mean doing everything yourself, and detail the available resources (along with clear expectations, guidelines, measures of success, and known consequences; as detailed in the Stewardship delegation framework of The 7 habits of highly effective people by Stephen R. Covey).

Following up on progress

Once all of this is set, then you are ready to start working toward your Key Results, and ultimately, your objectives! As it was outlined in this article so far, the goal of this framework is to allow iterations and experimentation. Therefore, teams must close the feedback loop and regularly reflect on their progress at each level:

• Every week (or sprint), teams reflect on what they achieved compared to what they committed to in their weekly goals. If all has been done, great! Otherwise, have the priorities changed? Should we re-prioritize the leftovers or move to something else? Even after a week or so, context may have changed.
• Progress towards Key Results should be reviewed multiple times in the quarter, so that teams have several iterations to have the opportunity to change their plans if their first approach does not produce the expected results. I recommend at least a 1-month cycle, but it could be more fine-grained with 2-week cycles.
• At the end of the quarter, final metrics of the Key Results should be reviewed. If the Key Result was achieved, let’s think about the next target to reach the objective! Otherwise, should we reiterate with it as a Key Result for the next quarter, or has something changed that makes us want to approach the objective differently?

I find that the usual Agile / SCRUM practices most engineering teams adopt align well with the above “follow up sessions”, especially for the two first points (weekly/sprint review and Key Result progress review). Rather than adding yet another meeting to the engineering teams, it’s worth letting them try to merge those sessions with their existing ones. For instance, weekly (or sprint) goal setting & review can be merged with the sprint planning sessions, as they have a very similar role. In that case, the list of goals and the review of previous goals is an output, artifacts of the weekly planning.

Getting the data

Key Results are a cornerstone of the proposed framework, so we are definitely taking a quantitative approach. Therefore, we need data. Without it, we can’t say if a target is achieved or not, or if the outputs we produce generate a change in behavior and make us closer to the outcome we look for. Therefore, without data, we can’t close the feedback loop and iterate: the data should tell us if our outputs are generating the expected outcome. Otherwise, we’re still just running a task-list hoping for the best.

If your company or team is not really data-driven, you may find yourself with Key Results that you can’t measure. The temptation is strong to change the metric to something close enough that you have access to. While using a proxy may be acceptable for a while, the benefit of the framework and OKR in general is that it forces us to measure what matters. You defined your key results as what mattered most. Therefore, it does matter to measure it properly; it is worth investing in this.

For product goals, we use MixPanel to track user behavior and adoption metrics. After a few months of top-down-led investments, most of our products have basic events implemented, allowing us to track the main steps of the customer journey, the moments of value, and the funnels that matter for our OKR. Teams now see the value of those investments and can take over in leading them to continuously improve our data.

For engineering goals, I have never found a suitable off-the-shelf product to measure metrics in a way that suited my teams. There are many great solutions out there, but I find it more powerful and not that hard to build my own data pipeline for engineering metrics. It gives me more flexibility to measure exactly what I need, given the context of the teams. I simply rely on a custom service (written in Django currently) that exposes endpoints for apps to send data to be stored in a database. Every time a ticket is updated, GitHub or JIRA sends a webhook, and the database reflects this change, with historization. Every time an end-to-end test sequence completes, an endpoint is called to store the results, etc. All this data is accessible to all the engineering and product teams. I can then build dashboards and alerts with Metabase to measure exactly what I need, such as:

• PR review time so that we see it dropping from over 100 hours to under 48.
• End-to-end sequence success rate to reduce flakiness.
• Time of tickets from “To Do” to “Done” so that we improve the development lead time.

Metabase also allows us to build alerts, so we can proactively see if we are going off track with regard to our objective. Some of those alerts, such as “PR waiting for review for more than 24 hours” made a huge difference in achieving our goals.

Django has the benefit of offering a built-in admin view, so that I can manually enter the data that is not automated yet. For instance, I manually review all the weekly/spring goals of my teams and enter in Django the percentage of completion of the previous goals. This routine keeps me up to speed with what’s going on in the teams, and gives them an objective view of how well they deliver what they commit to. This data-driven approach allows the team to see for themselves if they tend to overcommit for instance, so they can adjust their predictions.

The example of WP Media’s QA team

To illustrate the ideas in this article, I will take the example of WP Media’s QA team. This team is composed of 3 QA engineers who are closely working with the software engineers and product managers of two products: WP Rocket and BackWPUp. WP Rocket is the flagship of our ecosystem, with more than 5 million websites using it. Let’s imagine that we set the following objective for our WordPress department: “Offer the best ecosystem of WordPress products for small and medium-sized companies to build their website by the end of the year”. One aspect of this objective we could focus on is the quality of our WordPress products. Looking at our ecosystem, we could identify WP Rocket as a great example to get inspiration from. A large part of the quality is due to the QA team and processes: how can we export this expertise and share it with the other products? Among the OKR we can derive from this, here is one for the QA team:

• Objective: Automate repetitive tasks to free time for higher-value activities.
  • Key Results:
    • QA engineers can validate RC in less than 1 hour by the end of the quarter.

For this OKR, we need to measure how much time is needed for QA engineers to validate an RC. You may find this data in the test tools you use if you record manual testing, for instance. Manual tests would likely go way above 1 hour, so the team can try to automate the tests and measure the execution time of the test suite. Along the way, the team may learn that some tests are flaky, so they’ll resort to measuring execution time and success rate, and improve both.

Through the recommended framework, teams can prioritize their weekly tasks in order to achieve Key Results and, more globally, reach the objectives. Through regular meetings, people reflect on progress and can decide to adjust their roadmap if needed. Relying on quantitative measures also ensures proper alignment at all levels about what success means, and helps ensure the whole organization works in the same direction.