4 ms·

Quite recently I quit a company just as they were bringing in OKRs. The reason they bought in OKRs was because they felt that the engineering organisation was f

Quite recently I quit a company just as they were bringing in OKRs. The reason they bought in OKRs was because they felt that the engineering organisation was failing to meet the needs of the company. So they put together a list of Objectives and key results. They basically said "This is what we have to do to be successful". There were a few small hitches. Half the Objectives were outside the scope of the engineering team. We could execute perfectly, but if our internal customer fucked up, our objective would be blown. They explained this was because it doesn't matter if we meet some technical objective if it turns out that wasn't necessary for the company to make money. The second small hitch was they were diametrically opposed objectives. We were to going to increase our release cadence 10x. We were also going to reduce production issues by 100%. That's right, our objective was 0 production issues whilst massively increasing our release cadence with 0 extra resources. The third issue is that they were unacheivable - we were supposed to deliver a 3 year project that would take 10 people in 1 year with 5 people. It missed that the reason the engineering org failed to deliver was that the internal customer would change the requirements of 6 month projects roughly once a week. It was basically an exercise in trying to pin blame on engineers for the failure of the company. It didn't bother me too much because I was quitting anyway. OKRs don't fix dysfunctional organisations.

theptip 4y ago
> OKRs don't fix dysfunctional organisations. Very true. However -- note that the process of implementing OKRs has caused the leadership team to write down their expectations, which previously might have been unspoken. This is a first step towards resolving the problem. The next step is for the CTO to push back, hard, on the bits of these that aren't actually realistic, and hopefully get the leadership team aligned on what can actually be done. And so, the process of OKRs potentially has value here in flushing out unrealistic or mismatched expectations between different parts of the org. This is one of those rare "my way or the high way" moments in leadership; as CTO at this company it's your job to either get the leadership team to realize that they are asking you for more than you can be expected to deliver, or quit. You can't stick around and put your name on a plan that you know is impossible; otherwise you're going to be the one that failed for every quarter to come. And even worse, you can't sign your team up for this BS. It's your job to shield them from this kind of shit. > Half the Objectives were outside the scope of the engineering team. Shared OKRs are difficult, but sometimes they are unavoidable. The most difficult business problems usually are cross-functional. At their best, OKRs can help to make these cross-functional dependencies more explicit, and foster communication and collaboration around them. If they are trying to have engineering take full ownership of a shared OKR, that's a big problem. But if you clearly call out the shared ownership, and consider both parties responsible for implementation, then I think that's OK. > We were to going to increase our release cadence 10x. We were also going to reduce production issues by 100%. That's right, our objective was 0 production issues whilst massively increasing our release cadence with 0 extra resources. As a tangential point, increasing release cadence can definitely decrease your long-term rate of issues (see "Continuous Delivery" by Humble[1]) -- this forces you to automate manual processes, and manual processes are one of the main places that errors creep in. Though I think "count of issues" is a very poor metric, you're better off with an uptime metric. And "100%" is the only strictly-incorrect number to pick for uptime, because it is literally impossible; my (super-unscientific, don't hold me to this) rule of thumb for business people is "every extra 9 costs you 10x". So do you need 99.9% uptime or 99.99%? [1]: https://www.amazon.com/Continuous-Delivery-Deployment-Automation-Addison-Wesley/dp/0321601912 https://www.amazon.com/Continuous-Delivery-Deployment-Automa...
- Traster 4y ago
  I’m glad you mentioned this, yes the CTO quit 6 months later.
egman_ekki 4y ago
Having measures of success that are opposites of each other actually makes sense (as explained also in the High Output Management). That way you ensure you won't go too much into increasing release cadence at the cost of introducing too many bugs and vice versa.
- Traster 4y ago
  For the purposes of quantifying this we weighted one of those worth 95%.

theptip 4y ago

> OKRs don't fix dysfunctional organisations. Very true. However -- note that the process of implementing OKRs has caused the leadership team to write down their expectations, which previously might have been unspoken. This is a first step towards resolving the problem. The next step is for the CTO to push back, hard, on the bits of these that aren't actually realistic, and hopefully get the leadership team aligned on what can actually be done. And so, the process of OKRs potentially has value here in flushing out unrealistic or mismatched expectations between different parts of the org. This is one of those rare "my way or the high way" moments in leadership; as CTO at this company it's your job to either get the leadership team to realize that they are asking you for more than you can be expected to deliver, or quit. You can't stick around and put your name on a plan that you know is impossible; otherwise you're going to be the one that failed for every quarter to come. And even worse, you can't sign your team up for this BS. It's your job to shield them from this kind of shit. > Half the Objectives were outside the scope of the engineering team. Shared OKRs are difficult, but sometimes they are unavoidable. The most difficult business problems usually are cross-functional. At their best, OKRs can help to make these cross-functional dependencies more explicit, and foster communication and collaboration around them. If they are trying to have engineering take full ownership of a shared OKR, that's a big problem. But if you clearly call out the shared ownership, and consider both parties responsible for implementation, then I think that's OK. > We were to going to increase our release cadence 10x. We were also going to reduce production issues by 100%. That's right, our objective was 0 production issues whilst massively increasing our release cadence with 0 extra resources. As a tangential point, increasing release cadence can definitely decrease your long-term rate of issues (see "Continuous Delivery" by Humble[1]) -- this forces you to automate manual processes, and manual processes are one of the main places that errors creep in. Though I think "count of issues" is a very poor metric, you're better off with an uptime metric. And "100%" is the only strictly-incorrect number to pick for uptime, because it is literally impossible; my (super-unscientific, don't hold me to this) rule of thumb for business people is "every extra 9 costs you 10x". So do you need 99.9% uptime or 99.99%? [1]: https://www.amazon.com/Continuous-Delivery-Deployment-Automation-Addison-Wesley/dp/0321601912 https://www.amazon.com/Continuous-Delivery-Deployment-Automa...

Traster 4y ago
I’m glad you mentioned this, yes the CTO quit 6 months later.

egman_ekki 4y ago

Having measures of success that are opposites of each other actually makes sense (as explained also in the High Output Management). That way you ensure you won't go too much into increasing release cadence at the cost of introducing too many bugs and vice versa.

Traster 4y ago
For the purposes of quantifying this we weighted one of those worth 95%.