This week, I'm offering a suggestion for those awkward periods when you're waiting for the roadmap to take shape and looking for useful work to fill your sprint.

Often tech debt ideas are the answer to times like these. First off, ahem, meaningful tech debt issues should be on the regular roadmap 🥰. The risk with ad-hoc tech debt work is that it often expands unexpectedly. Particularly as shipping a refactor requires much more time and QA than a normal deploy. If you're not prepared, your devs will start to go down this path, and when it's time for roadmap work the gears might start to grind as planning meetings collide with "one last fix/deploy/test".

And sure, the backlog could help, but items often land there because they're not critical, and they're often not well triaged. We should be engaged in clear meaningful work as much as possible.

An alternate option I've had a lot of success with is setting up crowd-sourced pain-point system that I call "Papercuts." A Papercuts is small, yet disproportionately irritating issue that wouldn't be a top priority list unless the CEO points it out. They are everywhere and often go overlooked by usual work planning processes.

The key to a successful Papercuts process is to make the collection of the issues as easy as possible and to broadly share that process. A good Papercut can come from anyone.

My go to process is to set up a small Google Form (as they allow file uploads nicely), put it at a memorable URL (internalsite.com/papercut), and remind people about it regularly. Positively acknowledging people who contribute and announcing resolved Papercuts keeps the momentum going. Resist the urge to add triage questions to your form. Keeping it light encourages more submissions. My simplified Papercut form has:

• Your email/name other way to followup
• A short description of the Papercut
• An option to upload a file
• From 1-5 how painful?
• From 1-5 How often?
• A short comment that thanks them for their time

And honestly, looking at them now, those two ranking questions are a little too much. If they're filling out the form, that's enough signal that it needs attention.

Once you're getting data, you've now got a list of things that are:

• Emotionally significant to people at the company
• Potentially valuable product feedback
• Very rewarding to fix
• Don't have specific deadlines

This is a special thing! Triage the results in a regular basis, get them into your tracking systems, and celebrate progress. Papercut work earns devs cross-team respect and boosts engineering's organization-wide reputation. Plus, since they're typically minor issues, they fit snugly into those strangely quiet periods.

Good things happen when you actively empathize with others' frustrations

See you next week!