We stopped roadmap work for a week and fixed 189 bugs

It’s Friday at 4pm. I’ve just closed my 12th bug of the week. My brain is completely fried. And I’m staring at the bug leaderboard, genuinely sad that Monday means going back to regular work. Which is weird because I love regular work. But fixit weeks have a special place in my heart.

What’s a fixit, you ask?

Once a quarter, my org with ~45 software engineers stops all regular work for a week. That means no roadmap work, no design work, no meetings or standups.

Instead, we fix the small things that have been annoying us and our users:

• an error message that’s been unclear for two years
• a weird glitch when the user scrolls and zooms at the same time
• a test which runs slower than it should, slowing down CI for everyone

The rules are simple: 1) no bug should take over 2 days and 2) all work should focus on either small end-user bugs/features or developer productivity.

We also have a “points system” for bugs and a leaderboard showing how many points people have. And there’s a promise of t-shirts for various achievements: first bug fix, most points, most annoying bug, etc. It’s a simple structure, but it works surprisingly well.

What we achieved

Some stats from this fixit:

• 189 bugs fixed
• 40 people participated
• 4 was the median number of bugs closed per person
• 12 was maximum number of bugs closed by one person

Here are some of the highlights (sadly many people in my org work in internal-facing things so I cannot share their work!):

• I closed a feature request from 2021! It’s a classic fixit issue: a small improvement that never bubbled to the priority list. It took me one day to implement. One day for something that sat there for four years. And it’s going to provide a small but significant boost to every user’s experience of Perfetto.
• My colleague made this small change to improve team productivity. Just ~25 lines of code in a GitHub Action to avoid every UI developer taking two extra clicks to open the CI’s build. The response from the team speaks for itself:

• I also fixed this issue to provide a new “amalgamated” version of our SDK, allowing it to be easily integrated into projects. It’s one of those things that might be the difference between someone deciding to use us or not, but building it took just one hour of work (with liberal use of AI!).

The benefits of fixits

For the product: craftsmanship and care

I care deeply about any product I work on. That means asking big questions like “what should we build?” and “how do we make this fast?” But it also means asking smaller questions: “is this error message actually helpful?” or “would I be frustrated using this?”

A hallmark of any good product is attention to detail: a sense that someone has thought things through, and the pieces fit together to make a cohesive whole. And the opposite is true: a product with rough edges might be tolerated if there are no alternatives, but there will always be a sense of frustration and “I wish I could use something else”.

Fixits are a great chance to work on exactly those details that separate good products from great ones. The small things your average user might not consciously notice, but absolutely will notice if they’re wrong.

For the individual: doing, not thinking

I sometimes miss the feeling I had earlier in my career when I got to just fix things. See something broken, fix it, ship it the same day.

The more senior you get in a big company, the less you do that. Most of your time becomes thinking about what to build next, planning quarters ahead, navigating tradeoffs and getting alignment.

Fixits give me that early-career feeling back. You see the bug, you fix it, you ship it, you close it, you move on. There’s something deeply satisfying about work where the question isn’t “what should we do?” but rather “can I make this better?” And you get to answer that question multiple times in a week.

For the team: morale and spirit

Having 40 people across two time zones all fixing bugs together adds a whole other dimension.

The vibe of the office is different: normally we’re all heads-down on different projects, but during fixit the team spirit comes out strong. People share their bug fixes in chat rooms, post before-and-after screenshots and gather around monitors to demo a new feature or complain about a particularly nasty bug they’re wrestling.

The leaderboard amplifies this energy. There’s a friendly sense of competition as people try and balance quick wins with meatier bugs they can share stories about.

There’s also a short update every morning about how the previous day went:

• total bugs fixed
• how many people have fixed at least one bug
• how many different products we’ve fixed things in
• who’s currently at the top of the leaderboard

All of this creates real momentum, and people feel magnetically pulled into the effort.

How to run a fixit

I’ve participated in 6 fixits over the years and I’ve learned a lot about what makes them successful. Here are a few things that matter more than you’d think.

Preparation is key

Most of what makes a fixit work happens before the week even starts.

All year round, we encourage everyone to tag bugs as “good fixit candidates” as they encounter them. Then the week before fixit, each subteam goes through these bugs and sizes them:

• small (less than half a day)
• medium (less than a day)
• large (less than 2 days).

They assign points accordingly: 1, 2, or 4.

We also create a shortlist of high-priority bugs we really want fixed. People start there and move to the full list once those are done. This pre-work is critical: it prevents wasting day one with people aimlessly searching for bugs to fix.

The 2-day hard limit

In one of our early fixits, someone picked up what looked like a straightforward bug. It should have been a few hours, maybe half a day. But it turned into a rabbit hole. Dependencies on other systems, unexpected edge cases, code that hadn’t been touched in years.

They spent the entire fixit week on it. And then the entire week after fixit trying to finish it. What started as a bug fix turned into a mini project. The work was valuable! But they missed the whole point of a fixit. No closing bugs throughout the week. No momentum. No dopamine hits from shipping fixes. Just one long slog.

That’s why we have the 2-day hard limit now. If something is ballooning, cut your losses. File a proper bug, move it to the backlog, pick something else. The limit isn’t about the work being worthless - it’s about keeping fixit feeling like fixit.

Number of people matters

We didn’t always do fixits with 40 people. Early on, this wasn’t an org-wide effort, just my subteam of 7 people. It worked okay: bugs got fixed and there was a sense of pride in making the product better. But it felt a bit hollow: in the bigger picture of our org, it didn’t feel like anyone else noticed or cared.

At ~40 people, it feels like a critical mass that changes things significantly. The magic number is probably somewhere between 7 and 40. And it probably varies based on the team. But whatever the number is, the collective energy matters. If you’re trying this with 5 people, it might still be worth doing, but it probably won’t feel the same.

Gamification

The points and leaderboard are more than a gimmick, but they have to be handled carefully.

What works for us:

• Points are coarse, not precise: We deliberately use 1/2/4 points instead of trying to measure exact effort; the goal is “roughly right and fun”, not accurate performance evaluation.
• Celebrate breadth, not just volume. We give t-shirts for things like “first bug fix”, “most annoying bug fixed”, not just “most points”. That keeps newer or less experienced engineers engaged.
• Visibility over prizes. A shout-out in the daily update or an internal post often matters more than the actual t-shirt.
• No attachment to perf reviews. This is important: fixit scores do not feed into performance reviews. The moment they do, people will start gaming it and the good vibe will die.

We’ve had very little “gaming” in practice. Social norms do a good job of keeping people honest and 40 is still small enough that there’s a sense of “loyalty to the cause” from folks.

The AI factor

The big challenge with fixits is context switching. Constantly changing what you’re working on means constantly figuring out new parts of the codebase, thinking about new problems.

AI tools have mitigated this in a big way. The code they write is less important than their ability to quickly search through relevant files and summarize what needs to change. They might be right or wrong, but having that starting point really reduces the cognitive load. And sometimes (rarely) they one-shot a fix.

This docs change was a perfect example of the above: an update to our docs which catches out new contributors and AI was able to one-shot the fix.

On the other hand, in my record page change it was more useful for giving me prototypes of what the code should look like and I had to put in significant effort to correct the bad UX it generated and its tendency to “over-generate” code. Even so, it got me to the starting line much faster.

Criticisms of fixits (and why I still like them anyway)

I’ve definitely come across people who question whether fixits are actually a good idea. Some of the criticisms are fair but overall I still think it’s worth it.

“Isn’t this just admitting you ignore bugs the rest of the time?”

To some extent, yes, this is an admission of the fact that “papercut” bugs are underweighted in importance, both by managers and engineers. It’s all too easy to tunnel on making sure a big project is successful and easier to ignore the small annoyances for users and the team.

Fixits are a way of counterbalancing that somewhat and saying “actually those bugs matter too”. That’s not to say we don’t fix important bugs during regular work; we absolutely do. But fixits recognize that there should be a place for handling the “this is slightly annoying but never quite urgent enough” class of problems.

The whole reason we started fixits in the first place is that we observed these bugs never get actioned. Given this, I think carving out some explicit time for it is a good thing.

“Isn’t it a waste to pause roadmap work for a whole week?”

It’s definitely a tradeoff. 40 engineer-weeks is a lot of manpower and there’s an argument to be made it should be used for actually solving roadmap problems.

But I think this underweights the importance of polish of products to users. We’ve consistently found that the product feels noticeably better afterward (including positive comments from users about things they notice!) and there’s a sense of pride in having a well-functioning product.

Also, many of the team productivity fixes compound (faster tests, clearer errors, smoother workflows) so the benefits carry forward well beyond the week itself.

This only works at big companies!

I agree that a full week might be too much for tiny teams or startups. But you can still borrow the idea in smaller chunks: a “fixit Friday” once a month, or a 2-day mini-fixit each quarter. The core idea is the same: protected, collective time to fix the stuff people complain about but no one schedules time to address.

Fixits are good for the soul

The official justification for fixits is that they improve product quality and developer productivity. And of course they do this.

But the unofficial reason I love them is simpler: it just feels good to fix things. It takes me back to a simpler time, and putting thought and attention into building great products is a big part of my ethos for how software engineering should be done. I wouldn’t want to work like that all the time. But I also wouldn’t want to work somewhere that never makes time for it.