5 ms·

Why didn’t you make OKRs out of refactoring, integration tests, etc.?

duncan-donuts 8y ago
Refactoring is a really tough sell for an OKR. We use OKRs and we have had a couple quality initiatives in the past that were tied directly to OKRs and even then it’s hard to get that work prioritized. At the end of the day as long as users aren’t complaining product is going to index on features and value added. I’ve never been somewhere that would let you make a goal around redoing something that already works (even if it works like shit). I think the reason for that is it’s hard to come up with a key result that can be measured once the work is done — other than “it still works the same”
- nickbauman 8y ago
  Should not be a tough sell. Refactoring, from an OKR perspective, means you are protecting the ability to ship. Which means that there are tacit implications to OKRs. Nobody would want you to prioritize some rando OKR that would cause code quality to drop to the point that it impacts shipping (because now there are, say, bugs that shut off entire functional areas or something stupid like that). OKRs have built-in assumptions and these tend to be around protecting existential abilities of the company, like shipping code.
- titanomachy 8y ago
  This is an interesting point. I wonder if it might be easier at larger companies, since you can use metrics like "we are receiving fewer complaints that our system is hard to integrate with or understand". You might improve on some measure of "velocity", but on a small dev team that's so noisy as to be nearly meaningless. I guess you could track employee frustration as a primary target.
- james_s_tayler 8y ago
  I've been thinking about this lately. Mainly OKRs around developer experience. As an objective that's an easy one to come up with plenty of key results that actually tie in to refactoring, retiring old systems and upgrading existing ones. Currently where I work we have a fixed allocation % of dev/test time for technical improvements. In practice it works really well if you approach it strategically and use it to achieve things over the long term. Things you can just chip away at that steadily improve the health of the code, architecture and product. I find if it's used on a purely operational basis where you just ad-hoc improve stuff you find then it's not super effective, but it's pretty solid when the team is onboard with leveraging it to achieve better and better DX over the long term. Otherwise "refactoring" barely ever gets done and products slowly suffer bit-rot. I think OKRs are a perfect fit for such a scenario. We don't use them, but I kinda use them internally as part of my mental model.
kamaal 8y ago
OKR's are mostly done with things that move the needle with respect to money or user engagement/metrics. That more or less mandates building new products, features and services. Refactoring, tests etc don't fit anywhere in the OKR model.
- wahnfrieden 8y ago
  OKR is not a comprehensive planning tool either. It doesn’t have to explain all the work that you do, directly.
- xtracto 8y ago
  The way I have factored these and other type of tech debt is to factor it in as development efficiency. Particularly for startups, as they grow, one engineering team objective is to remain efficient as the team is growing. The way to achieve that? By refactoring code and introducing automation (like CI, CD, etc). This gets reflected in the cost of developer time per feature / project. Which can be represented as a KR in the. OKR framework.
- closeparen 8y ago
  Right, so you do it outside the model. We have a % of engineering capacity reserved for non-customer-facing work. Unfortunately it is mostly spent responding to infrastructure / dependency churn, just treading water rather than getting ahead, but it helps. No one is going to criticize you for refactoring what needs refactoring, as long as you are also making progress on your OKRs.
sanderjd 8y ago
IMO, it is difficult to write an OKR for this sort of work that is focused on measurable impact. "Write an integration test for xyz" is not really what OKRs are designed for. You can do that (and lots of people do), but it tends to be frowned on. The reason for this is that it's not clear how it rolls up into the larger company OKRs. Where does "wrote integration test for xyz" fit into the company's "increase monthly active users by x%" KR? I think the general trickiness is that OKRs are inherently backward-looking. A lot of technical improvements have to do with risk mitigation. The risk of nasty bugs (testing), the risk of future functionality being slow to develop because of poor architecture (refactoring), etc. But it isn't clear (to me) how to write OKRs for mitigating future risks.
- closeparen 8y ago
  OKR work is a subset of engineering time. We deal with things like interviews, meetings, tech talks, training, migrations, and maintenance work outside the framework. You should always be making progress on OKRs, but it’s not the only thing you do. Engineering has its own overhead, not every hour is billable.
  - NSSec 8y ago
    I'd say OKR work is/should be all work. Each task should be aimed toward moving forward on the goal. It doesn't mean however, that you can directly link one specific task to the OKR. It's just part of the strategy to achieve the goals. Let's consider a KR of 'increase active users by X%'. * Interviewing/hiring isn't going to move the needle on getting X% more active users by itself. Having more engineering time available for new (critical) feature work might, however and you have to do interviewing to get new hires. * Training in and of itself isn't going to move the needle either. But having a more knowledgable engineering team probably will, by being able to move faster or better. You have to do training to improve knowledge. * Maintenance work might not move the needle on active users FORWARD (or it might, if you have a lot of bugs that prevent users from actually using your stuff) but it might prevent it from going BACKWARD.
- deleted 8y ago
  [deleted]

Refactoring is a really tough sell for an OKR. We use OKRs and we have had a couple quality initiatives in the past that were tied directly to OKRs and even then it’s hard to get that work prioritized. At the end of the day as long as users aren’t complaining product is going to index on features and value added. I’ve never been somewhere that would let you make a goal around redoing something that already works (even if it works like shit). I think the reason for that is it’s hard to come up with a key result that can be measured once the work is done — other than “it still works the same”

nickbauman 8y ago
Should not be a tough sell. Refactoring, from an OKR perspective, means you are protecting the ability to ship. Which means that there are tacit implications to OKRs. Nobody would want you to prioritize some rando OKR that would cause code quality to drop to the point that it impacts shipping (because now there are, say, bugs that shut off entire functional areas or something stupid like that). OKRs have built-in assumptions and these tend to be around protecting existential abilities of the company, like shipping code.
titanomachy 8y ago
This is an interesting point. I wonder if it might be easier at larger companies, since you can use metrics like "we are receiving fewer complaints that our system is hard to integrate with or understand". You might improve on some measure of "velocity", but on a small dev team that's so noisy as to be nearly meaningless. I guess you could track employee frustration as a primary target.
james_s_tayler 8y ago
I've been thinking about this lately. Mainly OKRs around developer experience. As an objective that's an easy one to come up with plenty of key results that actually tie in to refactoring, retiring old systems and upgrading existing ones. Currently where I work we have a fixed allocation % of dev/test time for technical improvements. In practice it works really well if you approach it strategically and use it to achieve things over the long term. Things you can just chip away at that steadily improve the health of the code, architecture and product. I find if it's used on a purely operational basis where you just ad-hoc improve stuff you find then it's not super effective, but it's pretty solid when the team is onboard with leveraging it to achieve better and better DX over the long term. Otherwise "refactoring" barely ever gets done and products slowly suffer bit-rot. I think OKRs are a perfect fit for such a scenario. We don't use them, but I kinda use them internally as part of my mental model.

kamaal 8y ago

OKR's are mostly done with things that move the needle with respect to money or user engagement/metrics. That more or less mandates building new products, features and services. Refactoring, tests etc don't fit anywhere in the OKR model.

wahnfrieden 8y ago
OKR is not a comprehensive planning tool either. It doesn’t have to explain all the work that you do, directly.
xtracto 8y ago
The way I have factored these and other type of tech debt is to factor it in as development efficiency. Particularly for startups, as they grow, one engineering team objective is to remain efficient as the team is growing. The way to achieve that? By refactoring code and introducing automation (like CI, CD, etc). This gets reflected in the cost of developer time per feature / project. Which can be represented as a KR in the. OKR framework.
closeparen 8y ago
Right, so you do it outside the model. We have a % of engineering capacity reserved for non-customer-facing work. Unfortunately it is mostly spent responding to infrastructure / dependency churn, just treading water rather than getting ahead, but it helps. No one is going to criticize you for refactoring what needs refactoring, as long as you are also making progress on your OKRs.

sanderjd 8y ago

IMO, it is difficult to write an OKR for this sort of work that is focused on measurable impact. "Write an integration test for xyz" is not really what OKRs are designed for. You can do that (and lots of people do), but it tends to be frowned on. The reason for this is that it's not clear how it rolls up into the larger company OKRs. Where does "wrote integration test for xyz" fit into the company's "increase monthly active users by x%" KR? I think the general trickiness is that OKRs are inherently backward-looking. A lot of technical improvements have to do with risk mitigation. The risk of nasty bugs (testing), the risk of future functionality being slow to develop because of poor architecture (refactoring), etc. But it isn't clear (to me) how to write OKRs for mitigating future risks.

closeparen 8y ago
OKR work is a subset of engineering time. We deal with things like interviews, meetings, tech talks, training, migrations, and maintenance work outside the framework. You should always be making progress on OKRs, but it’s not the only thing you do. Engineering has its own overhead, not every hour is billable.
- NSSec 8y ago
  I'd say OKR work is/should be all work. Each task should be aimed toward moving forward on the goal. It doesn't mean however, that you can directly link one specific task to the OKR. It's just part of the strategy to achieve the goals. Let's consider a KR of 'increase active users by X%'. * Interviewing/hiring isn't going to move the needle on getting X% more active users by itself. Having more engineering time available for new (critical) feature work might, however and you have to do interviewing to get new hires. * Training in and of itself isn't going to move the needle either. But having a more knowledgable engineering team probably will, by being able to move faster or better. You have to do training to improve knowledge. * Maintenance work might not move the needle on active users FORWARD (or it might, if you have a lot of bugs that prevent users from actually using your stuff) but it might prevent it from going BACKWARD.
deleted 8y ago
[deleted]