3 ms·

One of our senior leadership people read the book, got in his mind that we need this at the company, got together the managers of all departments, they figured

One of our senior leadership people read the book, got in his mind that we need this at the company, got together the managers of all departments, they figured out some OKRs and now everyone’s off working on implementing them. Some of them are rather impossible, like teaching all devs on how to do devops within 2 months, so they can be self sufficient.

scaryclam 6y ago
"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.
- the_other 6y ago
  This has flicked a lightbulb on for me. 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).
sukilot 6y ago
Before OKRs did you have any plans or goals or strategy? How do OKRs relate to devops timelines?
emptysea 6y ago
Similar story at my place. 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.
- arkitaip 6y ago
  Engineering is clearly run by malicious compliance geniuses.
WrtCdEvrydy 6y ago
> teaching all devs on how to do devops within 2 months 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.
- eric-hu 6y ago
  At my company, management has repeatedly said OKRs should target failure. So like if you think you can get a major feature set done in 15 weeks they want you to target 10. 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.
  - WrtCdEvrydy 6y ago
    By the next stage, you'll have products being delivered made up of 50 JIRA tickets with 250 bug tickets being moved to whatever your long term Maintenance and Support team is... but someone will get to play with themselves over the thought that it was delivered on time.
rahimnathwani 6y ago
"teaching all devs on how to do devops within 2 months" 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?
cpeterso 6y ago
> teaching all devs on how to do devops within 2 months, so they can be self sufficient. 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.

scaryclam 6y ago

"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.

the_other 6y ago
This has flicked a lightbulb on for me. 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).

sukilot 6y ago

Before OKRs did you have any plans or goals or strategy? How do OKRs relate to devops timelines?

emptysea 6y ago

Similar story at my place. 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.

arkitaip 6y ago
Engineering is clearly run by malicious compliance geniuses.

WrtCdEvrydy 6y ago

> teaching all devs on how to do devops within 2 months 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.

eric-hu 6y ago
At my company, management has repeatedly said OKRs should target failure. So like if you think you can get a major feature set done in 15 weeks they want you to target 10. 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.
- WrtCdEvrydy 6y ago
  By the next stage, you'll have products being delivered made up of 50 JIRA tickets with 250 bug tickets being moved to whatever your long term Maintenance and Support team is... but someone will get to play with themselves over the thought that it was delivered on time.

rahimnathwani 6y ago

"teaching all devs on how to do devops within 2 months" 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?

cpeterso 6y ago

> teaching all devs on how to do devops within 2 months, so they can be self sufficient. 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.