I’d like to talk a bit about goals, their importance, some concepts and techniques for individuals (Team/group goals are a different topic).
Performance vs. developmental goals
There are basically two kinds of goals in a work setting - performance goals and developmental, a.k.a. growth goals. The key difference in theory is that performance goals focus on end results while developmental goals are learning & growth oriented. In reality most companies use performance goals in a very narrow way, e.g. to incentivize the sales team. This created a bad rap for performance goals and a shift in terminology.
I am strongly biased in favor of developmental goals for software engineers. The reason is that I find that most engineers are highly motivated to grow and are also intrinsically motivated to perform in their roles and are just fine without “the boss” telling them how to perform. In fact, after working with cca. 200 engineers I’m yet to find a single one who doesn’t want to perform well in their job.
Helping your engineers with good growth goals and coaching / mentorship can add a lot of value for them, though. It helps them focus, since there’s always just too many things to learn next, it helps them feel they’re progressing, it helps with the alignment with the company’s expectations of their career - which is ideally what the market wants already - and last but not least it makes them feel they’re at the right company. I find that growth opportunities are just as important to engineers as an exciting product to work on, great colleagues, good company culture and of course, fair compensation. I had engineers leave solely because they felt they’re not growing anymore.
There are some rate situations in which performance goals do make sense. One I can think of is when there’s already a gap between your expectations and the engineer’s performance. Closing that gap might require very narrow, outcome-focused goals, but note that this should only be temporary (until closing the gap or deciding to part ways). An example for a place for performance goals is a PiP (Personal Improvement Plan).
I’d also like to have an argument against ‘by default’ performance goals. Setting performance goals will feel like micromanagement and mistrust for your engineers. General expectations should be set by the leveling system you hopefully have in place, your company and team culture and your shared values. If none of these inspire and define good performance, then you have a problem there. Setting individual or team performance goals is a band-aid solution.
Your HR department might try to push you towards setting performance goals for your engineers for multiple reasons:
- They don’t deeply understand each department’s field
- They want a uniform process and set of training materials across the company
- They want an easy way to decide on promotions and compensation
My advice is to be proactive about this, reach out to them and make sure you give context about why you believe performance goals don’t fit your department.
OKRs, KPIs and SMART goals, oh my
OKRs (Objectives and Key Results) and KPIs (Key Performance Indicators) are two frameworks and concepts for goal setting
There are a plenty of articles about this topic, some very confusing. There’s also a false dichotomy floating around. No, it’s not an either-or situation.
OKRs
The best way to describe this framework is with this ‘formula’:
I will (Objective) as measured by (this set of Key Results).
You start out with high level Objectives which might be hard or impossible to measure by themselves then you come up with multiple Key Results. Key Results are like milestones but they don’t align on a linear timeline necessarily. They might or might not build/depend on each other.
Objectives are memorable qualitative descriptions of what you want to achieve. Objectives should be short, inspirational and engaging. An Objective should motivate and challenge the individual.
Key Results are a set of metrics/milestones that measure your progress towards the Objective. By definition the success of each key result needs to be easy do decide. It’s also OK not to achieve all of the key results! There’s usually not a 1-1 mapping between objectives and a set of key results.
Let’s see an example: you want to get better at programming in Go. An idea for an objective would be “I want to get confident at Go programming”. A set of potential Key Results could be:
- Write a CLI tool for updating our JIRA board
- Write a REST API service for X
- Convert my old Go project to use go modules
- Study and deeply understand the following pieces of the standard library: […]
You can get a sense. I find this framework really helpful for breaking down vague high level “things I want” to actionable and measurable smaller pieces.
You might have seen company/department level OKRs which probably looked different, the reason for that is those usually have numbers as targets in their key results. Some of them are KPIs!
KPIs
This is not a goal setting method! This is just a way to structure measuring things, usually performance, usually on the company/departmental level. E.g. for engineering you could have some of these KPI candidates: number of deployments per day, MTTR (Mean Time To Recovery), Cycle time. On a company level some examples are burn rate, profit margin, NPS (Net Promoter Score).
The most important thing about KPIs is which differentiates them from any other metric/indicator is that they measure the most important aspects of performance. You can have many supporting metrics but KPIs should be few and represent the performance
In a developmental goal scenario KPIs sometimes come in handy, mostly for making sure we focus on the real important things and not some vanity metrics. KPI targets are nice Key Result candidates sometimes. Such an example would be an engineer who wants to improve in code quality identifying e.g. mean pull request back-and-forth cycles as a KPI and then setting a target for it as a Key Result.
SMART goals
This is another framework that can be combined with others. This talks about how an ideal goal should look like:
- Specific (simple, sensible, significant).
- Measurable (meaningful, motivating).
- Achievable (agreed, attainable).
- Relevant (reasonable, realistic and resourced, results-based).
- Time bound (time-based, time limited, time/cost limited, timely, time-sensitive).
The OKR framework guarantees some of these but this is still good guidance.
Consider the previous example: “I want to get confident at Go programming”. Is this a SMART goal? Well… it’s not specific, it’s vaguely measurable (very subjective), probably Achievable, probably Relevant and not time bound.
You could wrangle a bit with making it a SMART goal but I found that some things (the personal and motivating aspect especially) can get lost in that effort. I grew to prefer OKRs over religiously SMART goals.
Again, this is another aspect to take into account and good guidance in general.
Not clinging to goals
Now we got to the most important discussion about goals.
Your engineers set the most amazing developmental goals, so full of energy, motivation, ready to take on the world - then life happened. Should they feel bad? Should you be disappointed as their manager?
Hell no. Of course it’s not nice when someone constantly ditches their goals but goals reflect an intent AND a life situation. Both can change. People might find out that Go is not their thing after all and jump to Rust instead. Did they fail their goal? Of course not. Hell, COVID might happen and people end up cramped together with flatmates or family, not really feeling energetic enough to keep learning. They might not be doing super well in work/life balance.
I might do a separate posts about the buddhist concept of non-attachment and stoicism to give some more perspective here. The bottom line is that goals in general work best if you don’t cling to them but use them as north stars and proxies.
How can you support your engineers in setting and achieving goals?
First and foremost by being supportive, not demanding (see the previous section).
Depending on the level and experience of the individuals you might need to be more suggestive, using your own past experience to come up with good goal ideas.
Make sure they understand it’s for them and you’re not there to dictate goals, merely to support them.
Understand that you’re not always the best person to help them in reaching their goals! There’s a difference between coaching and mentoring and maybe already coaching is better done by someone else in specific areas. Remember, you’re there to support, not to dictate! If you feel someone else is better suited to help in a specific area, connect them!
Make sure they have enough actual support for achieving their goals, such as time and mentorship during working hours! I actually have a post about it: Learning at work is work
I hope this article was useful for some of you out there, most things are trivial here, no great revelations but I sure could have used it a few years back :)