Heroes and Housekeeping Days

At Todoist, we’re big fans of deep work. We believe our team is maximally productive and happiest when we’re able to block off hours at a time to focus completely on our most cognitively demanding tasks.

As a team that builds productivity apps, our culture has naturally grown around this idea. We’ve always strived to minimize meetings and collaborate asynchronously as much as possible. The goal is for our team members to have control over when they connect to respond to messages and when they disconnect to focus on their highest impact work. (We feel so strongly about this idea that we built an async messaging app to help us do it.)

But last year, we had to come to terms with the fact that our focus on deep work was creating some pretty dysfunctional situations. We were prioritizing our long-term projects (for my team of front-end developers, that primarily meant new feature development) at the expense of communicating with our support team and providing prompt bug fixes.

In theory, everyone was responsible for replying to some support issues each day. But shifting focus between heads-down, deep product work and more reactive, communication-heavy support work in the same day was hard to do.

To make matters worse, no one felt ultimately responsible for making sure each support issue got a response. The whole front-end team was notified about every front-end issue, so it was easy for everyone to assume someone else would get to it.

In the case of product engineering, how do you empower your team to strike a balance between small improvements, bug fixes, and general maintenance tasks on the one hand and building new, exciting, and highly requested features on the other? In addition to those core engineering tasks, how does your team make time to communicate with internal and external stakeholders and keep abreast of new developments in their field?

On an individual level, the prevailing answer to these questions is task batching and time blocking. Batch your shallow tasks together and block off specific chunks of time during the day to handle them all at once. That way, you minimize the amount of context switching you have to do and maximize your uninterrupted hours for deep work.

An un-timeblocked vs timeblocked schedule

We wanted to figure out a way to apply those same productivity principles at the team level. The result was two new and complementary tools that have allowed us to strike a balance between long-term projects and short-term demands: Heroes and Housekeeping Days.

The Hero Role

Our monthly rotating system of heroes allows our team to balance deep work with more reactive work.

Each month, one person on each product team becomes the Hero. Their main responsibilities are to communicate with the support team, triage bugs, file them in our bug tracker, and fix the most urgent ones. Along with those tasks, the Hero takes care of smaller platform parity improvements to ensure that our various apps don’t diverge too much, as well as refactorings to improve the general health of our code base.

That’s a lot of work for one person. It’s a very reactive, communication-heavy role that can get stressful, particularly after a new feature is released. That’s why we rotate the role on a monthly basis.

We also ensure that the Hero can focus fully on their support duties. That means they aren’t assigned to any other product development work during that month. While being the Hero is a communication-heavy task, that doesn’t mean our Heroes are on pager duty 24/7. We still respect a 40-hour work week. We never expect responses on weekends except in emergencies, and we take vacation plans into account when we decide who the Hero will be that month.

In Twist, we have a custom group for each team Hero that we update each month. That way, anyone can simply tag Frontend Hero in a thread and know that the right person will be notified.

The flexibility of the Hero role is both a blessing and a curse. Being attentive to our support team and our users means the Hero is unlikely to block off four hours or more for deep work, something that developers and other creators need for max productivity. However, having one person assigned to these reactive tasks enables everyone else on the team to block off those hours to work on longer-term projects, which usually involve new feature development.

At the same time, being close to users’ requests, feedback, and bug reports gives the Hero a unique perspective into their problems and struggles. When everyone takes a turn at being Hero, it keeps our team from being too heads-down in our work and forges a stronger connection between our developers and our users.

In turn, that user-focused perspective helps inform our team’s product priorities. And as an added benefit, knowledge on our team is less siloed because Heroes have to touch many parts of the codebase to do their work well, not just the parts that they’re most familiar with.

In the Hero role, the right task prioritization is always a fine line to walk. It depends on your personal energy level (e.g. am I concentrated enough to work on a challenging refactoring versus fixing a small style bug?), what’s happening around you (e.g. all other clients implementing a new feature), the number of users affected by a bug, the recency of a problem, the availability of workarounds, and many more factors.

While there’s no one-size-fits-all guide for how the Hero should prioritize their tasks, we try to work on the most impactful things first. For instance, when a large number of users is affected or a bug has a significant negative impact on the user experience.

Housekeeping Days

Everyone on the team reserves one day per week for more shallow/reactive work, aka housekeeping.

To make time for all the other tasks, we introduced a second concept to our toolbelt: Housekeeping Days. Each member of the team (except the Hero) spends one day per week on Housekeeping.

There’s no strict definition of what housekeeping means. Normally on Housekeeping Days, we fix bugs that have been filed and prioritized by the Hero, or we work on refactorings to keep our code healthy and our technical debt in check. Sometimes, we use this time to learn something new related to our current or upcoming work. For example, taking a course on testing, reading up on new technology releases, or experimenting with new technologies.

Housekeeping is a personal day. If the Hero hasn’t explicitly asked for help on an issue, people have the freedom to choose which tasks they want to work on. Some like to fix bugs in our logic layer, while others like to work closer to the UI.

Most people pick a couple of Github issues at the beginning of the week and add them to their Todoist so they can keep track of them and schedule them as they see fit. Github remains our source of truth for all code-related issues so we can connect it with our code and reference it more easily.

Our Housekeeping Days ensure the team isn’t fully swamped by product work for weeks on end without time for anything else. It also gives the team explicit permission to put off small but important tasks until their Housekeeping Days in order to focus fully on their product work the rest of the week. That way they’re able to block off large chunks of uninterrupted development time the other four days of the week.

Housekeeping Days also act as a release valve when the Hero role gets stressful. The Hero is able to offload some of their tasks to the team by asking for help with a specific bug or problem.

Normally when working on hard problems, we try to avoid switching contexts as much as possible. Context switching is expensive and hinders deep work or flow states in development and other creative work.

But sometimes it can be beneficial to take a step back, work on something else, and come back rejuvenated with a fresh set of eyes. Not only do Housekeeping Days give us time to focus on small but important tasks, they also have the psychological advantage of resetting our brains after focusing deeply on a large feature for an extended period of time.

We have a snippet thread each week about our Housekeeping tasks alongside our other product work so everyone on the team knows what’s happening and what has happened. These snippets often spark discussions and inspire other teammates to look into similar questions and problems.

The Hero role and Housekeeping Days are simple concepts on the surface, but I’ve seen firsthand how they’ve made our front-end teamwork work more effective and less stressful. All team members start each month, week, and day with both the clarity of knowing what work they want to focus on and the freedom to focus on it (mostly) free of interruptions.

Everyone on the team has the opportunity to work closely with our support team and hear directly from users without sacrificing the more heads-down work of new feature development.

Deep work still plays a crucial part in our daily work, even during our Housekeeping Days and Hero months. Sometimes we have to close Twist in order to focus on a bug fix and get it done. But by explicitly separating short-term reactive work and longer-term feature development, Heroes and Housekeeping Days ensure that we strike a balance between both modes while minimizing the amount of context switching.

As managers and team leads, it’s important that we see our team members’ personal productivity challenges as our problems too. Are we setting our teammates up for clarity, focus, and success? Or are we saddling them with competing priorities and little practical guidance for how to balance them?

While this article has focused on how the development teams at Todoist balance long-term projects with short-term demands, I think similar principles could be applied to many different kinds of teams.