Beyond coding, mandatory on-call, ROI of ceremonies 💡
Monday 3-2-1 — Edition #40
Hey, Luca here! welcome to the Monday 3-2-1 ✨
Every Monday I will send you an email like this with 3 short ideas about engineering management, technical strategy, and good hiring.
You will also receive the regular long-form one on Thursday, like the last one:
To receive all the full articles and support Refactoring, consider subscribing if you haven’t already!
p.s. you can learn more about the benefits of the paid plan here.
1) 📺 Knowledge Sharing through Writing
Last week I was guest of my friend Patrick on the Beyond Coding channel, on Youtube.
We had a great, 45 mins conversation about writing, knowledge sharing, and my journey as a creator. I put the full video below 👇
Patrick is a great host and conveniently organized the video in many chapters. You can find topics such as:
and more!
2) 🚨 Should on-call be mandatory?
Being on-call can be considered part of the duties of any engineer, so there is no wrong in making it mandatory.
Especially if you are introducing it from scratch, mandatory on-call for all engineers is healthy to build ownership and to make sure no critical areas of the code are left uncovered by docs and playbooks.
Eventually, however, consider making it voluntary.
People may be more or less okay with being on-call depending on things like their family responsibilities. If the team is big enough and the process is battle-tested, then it's probably best to let people choose whether they want to be on-call or not.
You can find more ideas about how to create a good on-call process in this recent article 👇
3) 📊 ROI of ceremonies is non-linear
No one wants to waste their time on useless meetings or ceremonies, so, for each of them, you should try to figure out their return on investment. As Louis Bennett from Reforge says:
If a team’s ceremonies create more value than the opportunity cost of its attendees’ time, then the ceremonies are arguably not overhead. And… the converse is also true.
In my experience, however, this can be hard to assess, because in most ceremonies the cost component is constant, while value is not.
Example: I may find that daily standups are 80% of the time not worth the hassle. But roughly once a week you may have one where you discover a crucial roadblock, and that value possibly repays the cost of all the other standups.
Same goes with retros, 1:1s and other processes that look unnecessary until they don't.
As humans we are bad at assessing situations where the value distribution is uneven. We only get better with experience.
More thoughts on ceremonies, scrum, and modern dev processes 👇
🔨 Tools of the week
I weekly promote tools that I tried myself and can personally recommend 👇
Stepsize • track issues in your editor
Stepsize allows engineers to track and fix technical issues (like tech debt and refactoring work) directly from your editor.
It integrates with your existing tools like Jira, GitHub, or Linear, so you can link issues to code, and make them visible in your codebase, without leaving your editor.
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. You can learn more about the benefits of the paid plan here.
2) ❤️ Share it — Refactoring lives thanks to word of mouth. Share the article with your team or with someone to whom it might be useful!
I wish you a great week! ☀️
Luca