Apps + Coffee Connection: Set goals that motivate your engineering team

This blog is part of a series that delivers insights from the monthly meetups of Bugsnag’s Apps + Coffee Connection (ACC) community.

What’s the goal of setting goals? Far from rhetorical, this question is smart to ponder when embarking on goal-setting exercises. For many engineering leaders, it’s no small feat to define the goals and results that teams and individual contributors should try to achieve—especially while aligning this work with company goals. The January ACC meetup debated different types of goal-setting frameworks, contemplated what it takes to achieve alignment, and looped back around to the popular topic of technical debt to discuss its role in goal-setting conversations.

Leaders are shifting towards OKRs for stronger alignment

Two commonly-used frameworks for setting goals include Objectives and Key Results (OKRs) and Key Performance Indicators (KPIs). Many participants noted a recent shift in their own organizations towards the OKR framework, in large part because it’s designed to galvanize companies around specific sets of goals. In contrast, KPIs are focused on performance indicators and tend to be viewed as more directive than inspirational. 

As the name suggests, OKRs represent the Objectives you are trying to solve for or accomplish, and Key Results are the measurable outcomes that align to each objective. The idea is that leaders set OKRs at the top, and these goals flow down to teams and individuals to inform their OKRs. As a participant stated, “Because we do team OKRs that align with company objectives, it makes each team and each individual understand the impact of what they are doing and how it folds into the bigger company picture.”

Another participant summed up the overall benefit of this strategy by stating, “OKRs are great for keeping disparate parts of the organization swimming in the same direction.”

Several people voiced what they appreciate about OKRs over KPIs. One participant stated that they’re not as stressful: “If you don’t hit your OKRs, it’s seen more as a learning opportunity, which contributes to a positive working environment.” Another participant added, “OKRs are iterative, too. So if you’re reviewing them quarterly, you can refine them when the landscape changes. That’s important.”

When it comes to measuring success, one participant explained, “It’s not that important to get to 100% but more like 70%.” Another chimed in: “I think 70-80% is a good benchmark. If OKRs are too easy, they’re pointless, but if you can’t achieve a good chunk of them, you create demotivation across the organization. There should be enough ‘stretch room’ to make fundamental steps forward to improve the objectives or to change the perception.”

Considerations to heed with OKRs

As with many organizational challenges, coordination and communication across teams were identified as two of the most important factors when setting OKRs, especially if you want to promote predictability and transparency (and who doesn’t?).

“It’s all about getting to that sweet spot where you’re meeting the top-down objectives for the company, while also aligning with the bottom-up objectives of the people on the ground and the teams doing the work,” a participant stated. “There’s no easy way to do that without communication. It’s key in setting OKRs.” 

In a similar vein, managers want to ensure that engineering teams don’t find themselves being criticized for things that are not their fault. “Finding ways to roll up what an engineer does on a day-to-day basis to company goals is an interesting challenge, especially around communication,” one participant said. “On an engineering team, I can build a product and get it out quickly and efficiently, but if the product design is poor and we don’t hit the product objectives, it’s not necessarily a reflection on the engineering team and certainly not on the individual engineers.” 

That’s why several participants emphasized how important it is for Engineering and Product teams to align on what the objectives are and to develop a partnership around goals. As a participant shared, “It’s one thing having beautiful code, but if it doesn’t functionally do anything of value, then it’s difficult to meet those key objectives for the organization.”

When to use OKRs versus KPIs for teams

At a team level, OKRs and KPIs can be used in parallel because they represent different ways of approaching the goal-setting task. Simply put, OKRs are about outcomes, and KPIs are about output.

To elaborate, KPIs focus on hitting performance targets, and these goals tend to stay the same throughout a defined time period. Several participants noted the importance of having a means to track output and holding a clear understanding of what’s expected.

In contrast, OKRs are used for alignment around objectives, and they can change quarter to quarter, or even in the middle of the quarter. As one participant explained, “When you use OKRs, you treat the Key Results as outcome-based rather than output-based. You don’t want it to be a to-do list that people follow; we have enough tools and methodologies for tackling our roadmaps. It’s about keeping the culture focused outside of the day-to-day tasks.”

To motivate engineers and teams, participants recommended connecting goals to larger company goals. Not only does it create alignment, but it’s easier to show the value of the team’s work. A participant pointed out that it’s often about telling the right story around successes as well and emphasizing how they meet the needs of the organization.

From a leadership perspective, OKRs can also be used as a way to shield teams and ensure everyone works towards the established goals. “OKRs give management an opportunity to protect teams from being pulled into low-value, high-urgency activities if they are not aligned with your objectives for a particular quarter,” a participant explained. 

OKR risks for individual engineers (and what might work better)

Several participants agreed that setting OKRs at the individual level can be challenging. One stated, “OKRs point to a team effort and rarely represent the effort or performance of an individual,” while another participant added, “I think the risk of OKR as part of performance reviews is that it can lead to sandbagging [making things too easy].”

Of course, the spirit of OKRs is that they shouldn’t be bound to things like performance appraisal. One participant pointed out why individual contributors may rankle at using OKRs: “Pursuing an OKR for which you didn’t have a voice on the definition can be very hard, and a poorly-defined OKR can kill all of the purpose. If it’s tied to performance and compensation, it can have catastrophic consequences.”

These points beg the question: how should performance appraisals be conducted? How do you build a nurturing environment around your team that empowers growth and goal achievement?

One participant stated that he’s found success with the criteria outlined for SMART (Specific, Measurable, Attainable, Realistic, and Timely) goal-setting. “What I’ve liked about SMART goals is sitting down with team members and getting them to come up with the goals. I think it’s an effective strategy that builds ownership and trust,” he said. “There are times when you need to persuade someone to do something, but it’s more likely to be realized when an engineer is able to set reasonable metrics for themselves to help track that goal.”

Equally important is to look at goals carefully and to think about whether there are unintended results. Motivations must always be aligned with the work at hand. As an example, one participant stated, “For a junior developer, it’s probably not good to have a goal to contribute code that has 50% less bugs than last quarter. You run the risk that the developer will be very safe and maybe step away from risk or innovation because they are more focused on bugs. However, for a QA engineer, it may be a very good goal because they’ll focus on extending the mechanisms used for testing to let less bugs into production.”

Don’t forget about career goals!

Hand-in-hand with quarterly goal-setting is understanding and folding in longer-term career goals. The idea is to demonstrate commitment to backing broader development and providing reassurance that there will be opportunities and structure to the process. 

As one manager explained, “I believe I should be pushing my direct reports towards career goals however I can. They may not get there tomorrow, but there’s always something to work on. If they’re not working towards something for themselves, it’s atrophy. And if they’re not going in a direction of their choosing, they’re treading water.”

The current job market also factors into this way of thinking, as one participant pointed out: “Especially now, when people have a lot of options of where they can work, it’s good to keep them incentivized to stay and grow with you.”

When the question was raised around setting up individual plans for goal setting, some managerial ideas were shared, including:

• Look at where the individual is now from skills-perspective versus the role and determine how to level-up within that role. 
• Find out where individuals see themselves in the future and figure out how to map them to a coach who can help.
• Help further someone’s career with soft skills training or other educational training.

The role of technical debt with OKRs

Because OKRs are company-wide, a great idea for engineering leaders is to tie your OKRs to technical debt to help communicate the business impact of it. As a participant explained, “It allows engineers to say, in order to realize this objective, we have to do this other stuff as well, and then you can reach the outcome.” 

Again, participants stated that collaboration with Product teams around technical debt is key because you want it to be part of the culture to address it, as well as part of the goals and process. The “why” around technical debt—what’s the impact, what happens if we don’t do it now—can help elevate discussions and enable Product owners to recognize when features must be delayed in order to deal with tech debt.

One participant described the success his team was having working with Product: “We are bringing everything to a common language in which we can think the same, and we can prioritize new features and product stuff versus tech debt and technical initiatives at the same level and in the same room.”

For this strategy to work, it’s important to have high-customer awareness amongst members of technical teams. Customer-motivated engineers are extremely important and not very common. This dearth can be viewed as a goal for them to work towards. Another idea is to create objectives that tie two goals together that are traditionally a developer goal and a Product goal, such as improving developer productivity and improving the customer experience.

Measure outcomes but remember to keep it human

On a final note, one participant offered up sage advice: “One common trap is to measure outputs versus measuring outcomes. It’s much easier to measure outputs, but the outcomes are more important, and there’s often a significant gap between the two. Measuring outcomes and tying them back to the actual work that produced them requires some deep thought.”

Another participant agreed, stating that “outcome classification is a skill.” He went on to stress today’s work situation: “With remote working, it’s good to provide some more scope on goals. While it’s difficult to quantify, you want to give people time to focus a little more on themselves, such as their well-being and their mental health. At the same time, it’s important to keep up team morale and have a bit of fun. We will all be more remote moving forward, and people must enjoy the teams they are working on.” ‍

Interested in participating in conversations like this? Join the monthly discussions with the Apps + Coffee Connection community by registering here.