Interest clubs, maintenance cycles, and personal work 💡
Monday Ideas — Edition #84
Hey, Luca here, happy new year! Welcome to the first edition of the Monday Ideas 💡 of 2024!
Every Monday I send you an email like this with 3 short ideas about making great software, working with humans, and personal growth.
Paid members also receive a long-form, original essay on Thursday, like the last one:
To receive all the full articles and support Refactoring, consider joining 1400+ engineers and get the paid membership!
p.s. learn more about the benefits of the paid plan here.
1) 🎟️ Interest clubs
In any company you are able to find clusters of people with similar interests, like pets, videogames, or cooking.
People might have a lot in common outside of work, but they might be unsure about talking about it at work. They may wonder if they are even allowed to do so.
The best way to nurture this is to create a structure that signals the permission for such things to happen. Just like having a ping pong table at the office signals that people can play ping pong.
So, you can create dedicated spaces for the most popular interests in your team. These can be as simple as Slack channels, and if people are serious, they can easily turn into recurring events, and more.
These clubs work best when you can identify and encourage a core behavior that drives people engagement. Example: in a club around movies, the core behavior might be members posting their review every time they see a movie, with others leaving their comments below.
I have written more about creating good remote relationships in this previous article 👇
2) 🔄 Create maintenance cycles
One of the best strategies for doing regular maintenance — like updating libraries, improving coverage, or fixing small bugs — is to allocate a fixed time for it, say between 20 and 30%.
You can do this continuously — e.g. on a weekly basis — or through a rotating process where people are periodically assigned to a maintenance-only schedule.
Here are a couple of variations that I learned through the community:
🪖 Bug Duty
Radoslav Stankov, ex Head of Engineering at Product Hunt, wrote a full article about their bug duty process.
A different person from engineering is assigned to the Bug Duty every sprint. During that sprint, they don't work on a project. Instead, they work on the bug backlog.
This process works especially well in small teams, where knowledge of the codebase is widespread, and you may generally have full-stack devs. In larger orgs, you can counter the higher specialization by assigning multiple people to bug duty at the same time, covering the various platforms / layers (e.g. frontend + backend).
In any case, try to keep only one person responsible for the process at a time, for building ownership.
A variation of this is implemented at Swarmia as well. Ari Koponen, Head of Platform, weighs in:
We also have a rotating "Chief Firefighting Officer (CFO)" role. The CFO fixes immediate customer support needs, keeps taps on our production systems, merges dependency updates (PRs generated by Renovate), etc.
🎽 Maintenance Team
The larger version of the bug duty process is to assign a whole team to maintenance for a period of time. These are sometimes called quality sprints, or bug bashes if focused on finding and fixing bugs.
Similar initiatives exist for various types of engineering work: you may hear about security sprints, or accessibility sprints.
My take is that such dedicated cycles work well in creating momentum and fixing a large number of issues all together, but suffer from being—inevitably—infrequent, so they can’t be your only maintenance strategy.
If you do a quality sprint once every four sprints, on paper it’s a healthy 25%. In practice, though, with weekly sprints, that means fixing bugs only once a month, which is definitely not enough. If you have multiple teams, rotating them works better, as long as any team can own bugs from anywhere in the product.
I wrote more about handling maintenance in modern teams here 👇
3) 🪨 Rocks, pebbles, and sand
There is a famous story, that you have probably heard, about a professor who teaches a life lesson to his students by means of a simple metaphor.
This metaphor is about a jar, that first gets filled with rocks, then pebbles are added, and finally sand. If you want to make room for everything, the order in which you put stuff in the jar matters: rocks leave room for pebbles, which in turn leave room for sand. The opposite is not true: if you put pebbles first then you can’t fit the rocks, and so on.
A couple of months ago I borrowed this idea to talk about work. Like the items in the story, not all work is created equal 👇
🔴 Rocks — High Intensity
Rock work is your most important work: it is the one that requires the most of your energy and creativity. It produces original output and gives you a sense of fulfillment.
Examples of rock work for various roles might be: system design, creating design docs / PRDs, coding complex stuff, running good 1:1s, or, in my case, writing newsletter editions.
It is the work that you need to perform at your very best.
🟡 Pebbles — Medium Intensity
Pebbles aren’t necessarily smaller tasks than rocks, but they require less of your energy per unit of time. While rocks need the best of you, for pebbles you just need to clear some bar, or keep a standard.
For managers, pebbles might be going through status updates, checking-in on things, and unblocking small decisions. For engineers, they could be coding small changes, squashing bugs or adding missing tests.
🟢 Sand — Low Intensity
Sand work is basically chores — you do them because you have to, but there isn’t a lot of intelligence involved.
Examples of my personal chores are moving notes between various tools, publishing interviews on youtube, updating spreadsheets, or sending some email sequences.
Infamous engineering chores are: going through CI/CD, updating dependencies, or attending meetings where you never speak (sigh).
In my experience, you should always aim to spend ~50% of your day on rocks — high-intensity work.
In fact, there is a balance to be found here: you can’t do intense work all day long, as it is too draining and you can’t keep up in the long run. At the same time, spending most of your day on small things leads to lack of meaning, impact, and personal growth.
So, how do you optimize your basket? Here are a few strategies, based on the type of tasks:
🪚 Break Rocks — for hard, intense work, break it into smaller tasks and turn parts of some rocks into pebbles and sand. To simplify writing, create templates. To simplify processes, create checklists. To simplify coding, improve platform.
↪️ Delegate Pebbles — simpler tasks are easier to delegate. They also make for opportunities for younger co-workers to prove themselves.
🤖 Automate Sand — chores should simply be automated. For example, it is easy these days to create workflows and integrate various tools by using AI and low-code tools.
I wrote a full article about organizing your work 👇
And that’s it for today! If you are finding this newsletter valuable, consider doing any of these:
1) ✉️ Subscribe to the newsletter — if you aren’t already, consider becoming a paid subscriber. 1400+ engineers and managers have joined already! Learn more about the benefits of the paid plan here.
2) 🍻 Read with your friends — Refactoring lives thanks to word of mouth. Share the article with your with someone who would like it, and get a free membership through the new referral program.
I wish you a great week! ☀️
Luca
I loved the idea of bug duty, rather dedicating 25% time of team, it is better to dedicate engineer.
This post is filled with Rocks.
The Rocks concept goes incredibly well with timeboxing - scheduling parts of your day to specific tasks you want/need to get done. Put your big rocks on your calendar to ensure they have time dedicated to them. Ideally do this at the start of your week, or the day before, so that your goal setting is planned instead of reactionary.