How do you find time for cleanup work

A reader asks how do you find time for technical cleanup work. If OKRs and bugs take priority, when will you make improvements?

This was in response to What to work on next? where I listed priorities as: new bugs first, then OKR-aligned work, then ad-hoc requests, and make-it-easier work comes last. Michael notes that

In my experience, OKR and ad hoc requests are often effectively an unlimited amount of work, and it's very easy to never get around to #7.

Yep! That is true. You will never find time for this work, you have to make time.

Say no to "technical sprints"

I have never seen "technical sprints" succeed. Where you take a sprint, or a week, or a day, just to clean up tech debt or work on infrastructure that will speed up your work.

Leadership sees these as a favor to engineering. Thank you for all that you do, feel free to do more work as a reward for how awesome you are.

Don't fall for this.

You want leadership to understand that improvements are a key part of the work. As soon as they start seeing technical work as "okay we will pause our valuable roadmap so you can do your useless thing", engineering has lost. You are not seen as an equal contributor to business success.

Technical improvements are part of the work

I like to do technical improvement work as part of OKR-aligned and ad-hoc-requests work. Especially the low hanging fruit.

Do the big improvements when you:

a) Have an immediate use for them b) Know what done looks like c) Can do it in small steps

The last part is critical.

Better is good – make small steps

Biggest issue with large improvement projects is that they’re super hard to scope-manage and tend to balloon and balloon.

But because they're not the highest priority, you tend to get halfway there, put it aside, then never get back to finishing. Now you have WorkInProgress lying around and uncertainty on how to do critical tasks.

Do you use the old way or the new way? Will the new way be ready before the deadline? Will it be tested and working? What hidden problems does it have that we haven't found yet?

Use the gardening approach

The only way I've seen work is to:

  1. Set a long-term vision for what the world could be
  2. Make small steps
  3. When the codebase strays, nudge it back
  4. If the code always strays, adjust the vision

You want to have a long-term direction to aim towards then zig-zag around the ideal path towards the goal. Kick the can style.

Use code review to nudge people towards better practices. Make suggestions in architecture discussions that go in the right direction. Show others the new superpowers they get when your vision comes true. Give them taste of success right now.

Always empower engineers with superpowers they can see. Don't be the curmudgeon who says No.

If you get it right, everyone will make small improvements all the time. Before you know it, tech cleanup will be normal part of everyone's day. That's what victory looks like.

Cheers,
~Swizec