Monday 3-2-1 – watercooler meetings, sizing work, future accomplishments 💡
Edition #19
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
🎒 Hiring & Onboarding
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) 🎽 Watercooler meetings
To create stronger relationships within your distributed team, consider organizing watercooler meetings every week.
Molly Struve, Senior SRE at Netflix, runs them with a well-defined process:
Each meeting has a topic — you share that in advance, so people know it and it feels like a real event.
Process has an advocate — who always joins and proposes the topics.
The meeting lasts 15 minutes — it might last longer, but this way if people are busy they have an excuse to leave. At the same time, 15 mins is the sweet spot to do it everyday without making people feel guilty about pausing from work.
You can check out Molly’s full talk here.
I wrote more about remote relationships here 👇
2) 🔨 Do not use time to size work
I have quite a strong opinion that using man-days, or time in general, as the main measure of engineering work is not ideal.
Time is bad for three reasons:
👥 It depends on the developer — the estimate is bound to the person that is assigned to the task. Junior vs Senior devs might take very different times to complete the same task.
⚒️ It depends on other activities — even though you can strive to measure an absolute effort, devs naturally take into account the time they expect to lose on concurrent activities, like maintenance, meetings, and interruptions.
🗓️ It turns estimates into deadlines — it comes natural to set deadlines based on the sum of days that come up from estimates. This creates a commitment that is fragile — see (2) — and imprecise, because estimates are rough. It also puts more stress on developers, which may lead to the vicious cycle of inflated estimates.
Instead of time, you can use indirect measures like t-shirt sizes, story points, or, in some cases, just counting tasks.
I wrote more about estimating software work here 👇
3) 🎒 Write responsibilities as future accomplishments
In a job post, a good way to present responsibilities is to write them in the form of future accomplishments.
This is similar to writing product requirements in the form of future press releases.
It helps your reasoning and makes things practical. It is also a form of inversion 👇
And that’s it for today! If you liked the article, 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
How can "time inflation" be addressed through the 90-90 rule? Hofstadter's Law noted that time estimates are always wrong, and the 80-20 Principle (or 90-50 in this case) noted that just like how 20% of time is ample for 80% effectiveness, half of the time will create 90% effectiveness... but that means that wrapping up will require the other half. https://taylorpearson.me/interestingtimes/terminator-mode/
If the billing is based purely on time then it will be severely off. If the billing is based on initial velocity than it will be extremely off, requiring developers to create "noble lies" to compensate. What can be done to make sure that clients won't force time crunches?