Engineering teams often complain about the amount of tech debt in their codebase. It’s not easy to improve that. There’s often no time to dedicate to involved tech debt improvements. The good news is that a little goes a long way, especially if you do it regularly.

OKRs are a great way to define direction and drive continuous effort. Reducing tech debt is not a one-time activity. It is an ongoing effort to keep the amount of tech debt manageable. OKRs are a perfect tool for reducing tech debt in an engineering department. Read on to see how you can do it with your team!

Story time. Here’s a small case study of how I helped the engineering team in a Silicon Valley startup reduce tech debt while fostering best practices and bootstrapping a mentality of quality.

It was not obvious where to start. Engineers complained about the code quality. The code base was fragile. There were few automated tests. We had a linter definition, but the code was a mess.

When I asked around, there were no clear problems. Everyone claimed to run automated tests and the linter. We had commit hooks. People claimed to use the linter in their IDEs. After spending some time with the team, it became clear that the reality did not reflect that. Tests often failed, and we had over 14,000 linting errors. There was a mismatch between what the team believed and the reality of what was happening. The first step was to make the reality visible.

I decided to start slow since the team had never used OKRs. They never tracked metrics before. We decided to tackle linting errors and warnings.

We set a goal to reduce the number of linting errors and warnings from 18,000+ by 50%. We also tracked the number of linter ignore statements to ensure we did this well.

Initially, the team was reluctant because "it's only linting, and it does not matter." Every week, I measured the linting errors. At least at first, I tried to measure and failed. The linter was not working right. It took a few weeks to get the linter to work reliably.

We started looking at the linter numbers weekly in the engineering weekly meeting. At first, it seemed that no one cared much. I kept at it. Every little improvement or slip was called out. Sometimes, people were praised by name if they fixed many linter issues. Eventually, the team was fixing linter errors here and there on their own, as part of the work.

The number of linting issues started going down, slowly at first, and picking up pace. Occasionally, someone would spend a few hours, and the number would drop by a lot. Over time, we got the number of linting errors down to two. Yes, from 14,387 to precisely two. There was no herculean effort. It was the combined effort of a group of people who were steadily reminded that linting matters.

In the end, it took more than a quarter to get the number down. We moved on to other OKRs, but still tracked this metric. What eventually happened was magical. The team embraced code quality. They fixed the tooling. They drove other efforts on their own. There were plans in place to put in more sophisticated style analysis and run another OKR against that. The team matured in their development practices beyond just linting because of the relentless drive on one seemingly insignificant OKR. All it took was showing a boring bar graph and the week-over-week change.

This is just one example of how you can drive OKRs. Linting might not be your biggest problem or the one you care about. Still, but grabbing on to something and driving it forward, you often end up pulling other related things in the right direction.

You can use OKRs with engineering metrics to improve lots of things:

• fix the top 10 Jira tickets tagged with #techdebt
• reduce linting errors by 20%
• reduce the number of functions with a cyclometric complexity of 10+ by 50%
• research five static code analysis tools
• increase unit test code coverage from 56% to 62%
• decrease the number of uncaught client exceptions by 25%

You can go many different ways. When you do this, make sure you follow these steps:

1. Start by deciding what makes sense to improve and getting buy-in. You don’t need any time commitment. If you can get one, great. If not, make sure to make the key results realistic and achievable with tiny bits of effort.
2. Define the OKR, making sure the key results are clear, measurable, and feasible.
3. Make sure you have a way of measuring the key result. If not, create the measurement method before you define the OKR.
4. Create a way of recording the OKR results every week and share them with the team. It might seem like you are repeating yourself and that no one cares. Keep going and challenge the team to make the smallest positive improvement in the next week.
5. Each and every week, show the state of the OKR to the team. Ask the team what they can do to drive it. Challenge them to make the tiniest dent. The goal is to overcome the initial friction and get moving. Over time, you will pick up speed.

Let’s get specific. Let’s say that your team says that your codebase is hacky, and you agree. Here’s one way you could define an OKR.

• Create an OKR titled "Reduce tech debt by removing the worst hacks in our codebase."
• The first key result would be "Identify 30 hacky places in code, and create Jira tickets for each of them by Jan 31st."
  • scale: 0-30. Each created Jira ticket counts for 3.33% of progress.
• The second OKR would be "Refactor 15 out of the 30 hacky places identified by Jira tickets, by March 31st"
  • scale: 0-15. Each resolved Jira ticket counts for 6.66% of progress.

Each week, communicate the progress with the team. This could be a slide on a team-wide weekly meeting. Or it could be a Slack message or email. The key thing is to present the same OKR and show the progress while encouraging people to look at it. Ask people if they are looking at it. Challenge people to solve one ticket. No one needs to spend a whole day driving all the progress. Ten minutes might be enough to take care of one item and drive one of the key results one notch up.

Tech debt is cited as a problem by many software development teams. There’s never any time to “fix it.” The goal is not to fix the tech debt but rather to manage it. By creating OKRs and presenting progress each week, you can keep the goal on top of everyone’s mind. Many little actions aligned in the right direction add up to a lot of progress if done regularly.