At Doist, we’re big fans of “deep work”. We believe that our team is maximally productive — not to mention happy — 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 a team communication 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 frontend developers, that primarily meant new feature development) at the expense of communicating with our support team and providing prompt bug fixes.
What do you do when your team’s “shallow work” is just as important as their “deep work”?
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 frontend team was notified about every frontend issue, so it was easy for everyone to assume someone else would get to it.
What do you do when your team’s “shallow work” is just as important as their “deep work”? In the case of product engineering, how do you empower your team to strike a balance between small improvements, bugs fixes, and general maintenance tasks on the one hand and building new, exciting, and highly requested features on the other? On top of those core engineering tasks, how does your team make time to communicate with stakeholders, both in and outside of the company, 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.
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 🦸♀️
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. On top of 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 — they’re not 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.
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 4 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 — usually 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 prioritization of tasks to work on 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 amount 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 are affected or a bug has a significant negative impact on the user experience.
To make time for all the other tasks, we introduced a second concept to our toolbelt: Housekeeping Days.
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. People have different interests: 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. The source of truth of all code-related issues stays in Github so we can connect it with our code and reference it more easily.
Normally when working on hard problems, we try to avoid switching contexts as much as possible…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.
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 to 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. Switching contexts 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 frontend 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 actually 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 out short-term reactive work with 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 Doist balance long-term projects with short-term demands, I think similar principles could be applied to many different kinds of teams.
If your team has struggled with these same problems, I’d love to hear how you’re solving them. What prioritization strategies does your team use to balance long-term projects with short-term demands? Share your thoughts and ideas in the comments below.