The most productive teams I've run have been when using OKRs or OKR-like schemes.
They're hard to get right though. Its easy to add too much process, make planning too much of a burden, or not regularly check-in.
One concept that's helped lubricate things is "task-relevant maturity", which I first heard about in Andy Grove's _High Output Management_. It's a gross phrase but essentially means to that people who could accomplish a goal in their sleep need less help than someone who is facing something new. Accordingly, I've cut more slack to the former when laying out OKRs.
Its hard to overstate how valuable that is. Senior engineers who've been in the same space for eons chafe at having to do the same pedantic things as a junior engineer, and rightly so--they've seen a million managers and fads come and go.
To the point of the article I _really_ like the concept, but I'm wary of demanding another step for fear that it won't take. Usually I try something out by myself but keep it optional for a year or two---or forever.
You might resonate with Situational Leadership. The basic premise is almost exactly what you say above about senior engineers. In SL they break it down into four stages:
1. Beginner: you tell them exactly what to do and how to do it.
2. Novice: you mostly tell them what to do and encourage them to learn and experiment.
3. Experienced: you consult with them on what to do, and they mostly manage how to do it.
4. Expert: you give them the goal and mostly just ask them how they'll approach it and how long it will take.
The problem with OKRs is that they are a religion. Once a metric is established it becomes a god to worship at the expense of all else, until the harmful effects of such single mindedness become painful enough that the old god is deposed and a new god put in its place. With the same myopic thought process. True leaders call this blindness "focusing on what's important".
Simplifying something as complex as an engineering team or a company down to a couple of variables cannot possibly model the real world. You can't say this out loud though, because this goes against established leadership culture. You can't be one of them philosophers. We've got to have achievable goals here!
Example: once upon a time a goal was instituted where tasks were supposed to be assigned to the engineer with the most experience in a particular area. Focus! Faster time to close a ticket! Happier engineers - they work on what they are good at!
See the problem yet? Meeting the goal actually made it so that there were a ton of bottlenecks. If an engineer was out sick the team lost an expert in a particular area. Engineers got bored working on the same thing day in and day out. And because the OKR killed knowledge transfer it became impossible to tackle a problem as a group.
And so the old metric was declared a problem and a new ridiculously limited model of the world was put in its place.
Making your efforts focused on a thing seems like a good idea, given proper research and discovery is done and the metric to improve is measurable and meaningful.
I think the criticism you are voicing is more down to a management style rather than OKRs. I’ve never would isolate my team members in areas and prevent knowledge being focused in one person. Always let the group tackle the problem and let them decide on who is going to work on it. Encourage pair programming and especially during the problem discovery, involve the entire team (when tackling a large, new problem).
Smaller stuff can be picked up by the same engineer. A bug fix here, a small adjustment there. But as soon as you introduce a big chunk of business logic, it’s important to bring along the team. I feel like that’s not what happens to you, but I don’t see this as a fault of OKRs
> Progress is more like a hill than a straight line. Uphill: figuring things out (uncertainty, unknowns, problem-solving). Downhill: making things happen (certainty, confidence, execution)
This is the first time I've seen a "hill chart" and I found it a little confusing to look at - maybe because the shape looks like a normal distribution, where "the sides" are more uncertain and not less uncertain. If one turned a hill chart inside out, you'd get a chart like a dartboard, where as things are more certain you are closer to a bullseye in the middle, and less certain you are further away. I could see looking at OKRs that way.
I kinda like the hill chart but TBH it shouldn't look like normal distribution, but more like a half-circle. In my experience, most (SW) projects (at all levels of granularity) are S-curves (and not straight lines like in burndown chart). You're slow at beginning, because you're learning the domain and finding good abstractions. You're slow at the end because you're working out the kinks and fixing little details. The fastest progress is in the middle. So if the hill chart is supposed to show the difficulty in progress, it should look kinda like a derivative of inverted S-curve.
Going up is difficult but going down takes a lot longer than expected from the top, usually; so yeah, the hill should be skewed to the left and have a fat right tail.
The entire shape up philosophy from Basecamp is honestly the best project management style I’ve been a part of in software engineering. The inversion of thinking around time (how long do I want to take vs. How long will this take?) is the most critical aspect of it.
Yup, that is so obvious in hindsight but I hadn't thought of it that way before. "We're willing to spend this much time, will you be able to do it?" is a much easier question both to ask and answer than "how much time will it take?"
It also encourages collaboration over adversarial negotiation.
I think that completing a training or sharing the results are, technically speaking, deliverables not results; that's why that doesn't work as a OKR. OKR would ask for the measurable impact that completing those things has on business behavior (user-facing KPIs, or internal productivity / value measures).
My only encounter with OKRs sucked badly, and mismatches like that were one of the reasons.
This is the problem with both SMART goals and OKRs. They purport to be meaningful by measuring results, but results are outside of one's control and subject to the inputs of lady Fortune!
What we want to incentivise is not success, but the kind of behaviour that leads to success. But that, on the other hand, suffers even worse from Goodhart's law.
Cedric Chin dug deeply into this dilemma[1] about a year ago. His suggestion is to frequently follow up on both behaviour metrics and result metrics to build a tacit understanding of how one is affected by another. This then allows you to focus improvements on behaviour metrics, which are mostly in your control.
I have yet to try putting it to practise, but I like the idea.
Sure, OKR's can help keep multiple teams aligned on business and product goals. And that's an advantage that's too big to ignore. But the problem with OKR's is too often, they're handed down by well meaning people multiple levels removed from the day to day software development work. There can be a lack of ground truth. But too often they miss the bottom-up intelligence, creativity, and engineering needs that comes from the people who work on the product day to day. It's also important not to load your product roadmap into OKR's and call it a day, or else you'll end up with teams of people who check boxes and software that barely makes it out of the driveway. Personally, I would encourage a reflection period after each series of OKR's. Not to just discuss outcomes amongst the senior leaders, but to collect intelligence on the ground, talk to devs, talk to users, talk to support reps, and decide what really should be the priority. But hey, what do I know I'm just a person who's comment you're reading.
The biggest problem I've seen with OKRs as an engineer is that the objectives are business goals the engineering team has little or no ability to influence. Like, an objective of "onboard 5 new large customers" makes sense for the business, and the engineering team could definitely screw it up by, say, building a system that can't scale that high. But when the sales team only closes 3 new deals, the engineering team fails its OKRs no matter how good a job everyone did. I've seen this be quite demoralizing, especially when meeting OKRs is tied to bonuses.
The second-biggest problem is that the time horizons of OKRs are often longer than the interval between pivots that cause the old OKRs to no longer make sense.
Or building things that help retain current customers vs acquire new customers so sales has something to sell.
The bigger problem as I've seen it is engineers that don't see themselves as part of the business, either because of the culture or personal choice around lack of focus on soft skills.
All too often engineers spend zero time understanding the market and customers, and scaled agile, as it's typically implemented and managed, definitely doesn't help.
Readit News
They're hard to get right though. Its easy to add too much process, make planning too much of a burden, or not regularly check-in.
One concept that's helped lubricate things is "task-relevant maturity", which I first heard about in Andy Grove's _High Output Management_. It's a gross phrase but essentially means to that people who could accomplish a goal in their sleep need less help than someone who is facing something new. Accordingly, I've cut more slack to the former when laying out OKRs.
Its hard to overstate how valuable that is. Senior engineers who've been in the same space for eons chafe at having to do the same pedantic things as a junior engineer, and rightly so--they've seen a million managers and fads come and go.
To the point of the article I _really_ like the concept, but I'm wary of demanding another step for fear that it won't take. Usually I try something out by myself but keep it optional for a year or two---or forever.
Am I right that you idea is you're mapping the KRs to different points on the chart? Or is it about progress towards KRs?
It seems hard to decide where a KR lies in terms of uncertainty/certainty when it's just a measure
Simplifying something as complex as an engineering team or a company down to a couple of variables cannot possibly model the real world. You can't say this out loud though, because this goes against established leadership culture. You can't be one of them philosophers. We've got to have achievable goals here!
Example: once upon a time a goal was instituted where tasks were supposed to be assigned to the engineer with the most experience in a particular area. Focus! Faster time to close a ticket! Happier engineers - they work on what they are good at!
See the problem yet? Meeting the goal actually made it so that there were a ton of bottlenecks. If an engineer was out sick the team lost an expert in a particular area. Engineers got bored working on the same thing day in and day out. And because the OKR killed knowledge transfer it became impossible to tackle a problem as a group.
And so the old metric was declared a problem and a new ridiculously limited model of the world was put in its place.
Making your efforts focused on a thing seems like a good idea, given proper research and discovery is done and the metric to improve is measurable and meaningful.
I think the criticism you are voicing is more down to a management style rather than OKRs. I’ve never would isolate my team members in areas and prevent knowledge being focused in one person. Always let the group tackle the problem and let them decide on who is going to work on it. Encourage pair programming and especially during the problem discovery, involve the entire team (when tackling a large, new problem).
Smaller stuff can be picked up by the same engineer. A bug fix here, a small adjustment there. But as soon as you introduce a big chunk of business logic, it’s important to bring along the team. I feel like that’s not what happens to you, but I don’t see this as a fault of OKRs
This is the first time I've seen a "hill chart" and I found it a little confusing to look at - maybe because the shape looks like a normal distribution, where "the sides" are more uncertain and not less uncertain. If one turned a hill chart inside out, you'd get a chart like a dartboard, where as things are more certain you are closer to a bullseye in the middle, and less certain you are further away. I could see looking at OKRs that way.
Hill charts are a great way to keep people informed about a project status. I think they make much more sense than estimates.
It also encourages collaboration over adversarial negotiation.
Then you can have "fun" with it as to find meaningful purpose since their life is missing it elsewhere
But on the other hand i dont fully like them in my work life
First my job forces OKRs amount and treats them equally
So OKR like completing half day training and sharing the learnings has the same value as multi month engineering effort.
My only encounter with OKRs sucked badly, and mismatches like that were one of the reasons.
What we want to incentivise is not success, but the kind of behaviour that leads to success. But that, on the other hand, suffers even worse from Goodhart's law.
Cedric Chin dug deeply into this dilemma[1] about a year ago. His suggestion is to frequently follow up on both behaviour metrics and result metrics to build a tacit understanding of how one is affected by another. This then allows you to focus improvements on behaviour metrics, which are mostly in your control.
I have yet to try putting it to practise, but I like the idea.
[1]: https://commoncog.com/goodharts-law-not-useful/
Some technical skills increase or personal development objective
And that completion of training or certs is what is measured
The second-biggest problem is that the time horizons of OKRs are often longer than the interval between pivots that cause the old OKRs to no longer make sense.
The bigger problem as I've seen it is engineers that don't see themselves as part of the business, either because of the culture or personal choice around lack of focus on soft skills.
All too often engineers spend zero time understanding the market and customers, and scaled agile, as it's typically implemented and managed, definitely doesn't help.