A few months ago, I found an article describing how a manager introduced small fixes days (which, coincidentally, I can no longer find) into their organization, and brought the idea to the team I managed.

The initial reasons for bringing it forward resonated with me on a personal level - as a manager who was still responsible for a lot of the actual software development, small things tended to nag at me throughout my work. When I grew tired of them nagging me, I would either steal away time to fix it, or file it away. I found that both of these approaches revealed their flaws in the long term.

Stealing away time, while good in the sense that the issues got fixed, carried a level of organizational dishonesty. Other people didn’t really have insight into what I was doing, and it took me out of alignment with the other people on the team, even for a short while. It was an opportunity for communication and prioritization dysfunction to take root.

Filing it away solved the transparency issue, but reduced the tendency for the work to get done. In our project, new issues would generally be dropped at the top of the list and then either sorted by myself or the product person. Simply creating the ticket externalizes the problem, and dropping it at the top of the project and sorting it during a grooming session brings it into people’s consciousness. I came to realize that in the context of so many larger issues and priorities, these types of issues generally wouldn’t get fixed - they were hard to justify on their own. I think we fundamentally knew they could have small positive impacts, but up against tickets aligned with organizational goals, they never stood a chance.

So, I brought the idea to the team, mindful of the fact that just because it resonated with me didn’t automatically translate to enthusiasm and adaptation.

The rigor of cultural adaptation and team buy in is valuable in my opinion, even though it tends to take longer for ideas to be adopted. Strong arming people into an idea would reduce the general sense of autonomy and create drag on the actual work. It felt right to put it up to the people it affected and measure both their response and their ideas for implementation. We wound up on a bi-weekly cadence, kicking off the chosen week with Monday set aside as a small fix day. It seemed to work, because it gave us a higher probability of not being bogged down, mentally, in ongoing work due to the natural break of the weekend. Granted, not every feature or fix ends cleanly on Friday afternoon, but it correlates nicely with the head scratching that sometimes occurs on Mondays. Fair enough to leave that general grogginess til Tuesday and embark on some small fixes for the day.

The small fixes lined up nicely with our existing system of rough estimation, which gave us ranges of small (1-3 days), medium (4-10 days) and large (greater than 10 days). It was relatively easy to add on an extra small designation which meant a ticket that would take less than one day. Once the small and untagged tickets were groomed to create the extra small designations, we grouped them together for easy reference.

By allowing us some to resolve those little hiccups we saw day over day, small fix days created a new source of momentum for the team. We may have been working through some larger projects, or doing releases which had some compilation time built into them. Small fix days created the oppportunity for completion and achievement. Even if projects are moving at a good clip, I think it’s wise to have this extra source of housekeeping.