Some of them are rather impossible, like teaching all devs on how to do devops within 2 months, so they can be self sufficient.
There's so much wrong with this key result it's incredible :( One big reason that OKRs can fail is just flat out bad OKRs. Teaching all devs to do "devops" within two months ignores the actual issue that they seem to be trying to solve (which I'm guessing is that not having sufficient ops is hurting the company and velocity). It's far too easy to fail and puts pressure on individuals rather than letting the team find the right solution.
If your teams are fairly self-organising, if you are small-a agile and building your process as you discover more, you can plan in things like “dev A will spend 50% of this sprint learning dev-ops, without doing feature work or tech debt; and 10% shadowing dev B who already does Ops”.
That seems actionable, and measurable. Over two or three sprints/iterations/retrospectives, you’ll probably be able to measure the impact of the training (more successful releases, higher uptime, or more story points covered because ops is less a bottleneck etc).
The 'ing' at the end of the verb suggests that this is an activity, rather than an objective nor a key result.
If your company is using the term "OKRs" to refer to things that aren't OKRs, then perhaps they could use some help from someone who has used OKRs successfully elsewhere.
The same thing could happen with any new way of working. Imagine a company where no one has used TDD before. Some leaders decide everything must use TDD from now on. People try to work in this new way but, lacking experience and role models, they write their tests at the wrong level of abstraction and end up constraining future refactoring instead of enabling it. Would such an experience mean that TDD is bad or useless?
New executive hired who loves OKRs. Ends up not changing anything because the engineering OKR is “work on the product roadmap” aka what we’ve always been doing.
Only lasting impact is there are a few more slides in the company wide meetings.
At least this Key Result is measurable: 100% devs know how to do devops. :)
But who is the individual accountable for implementing this Key Result? For a task that broad, I hope a department manager is responsible for creating a training problem, not individual devs responsible for teaching themselves.
Estimation based on initial guts should be quadrupled and rounded to the nearest quarter... so 9 months. This should provide a 90% percentile chance of success.
I’m not a fan of it myself. The idea feels like growth hacking, but over many quarters it doesn’t feel great to always be falling short of goals. I always assumed this is part of the OKR model, but maybe it’s just my company.
How do OKRs relate to devops timelines?