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) 🔄 Cycles are good
If you think your dev cycle brings too much overhead, you are probably just working with a cycle of the wrong duration.
Cycles enable improvement because they allow us to create feedback loops — they serve as an anchor for retrospectives, celebrations, and all kinds of healthy habits.
Recurring ceremonies are crucial for managers to have reliable spots in which to take action. Without them, you would either:
end up not working enough on problems, or
need to be on the alert all the time, which is taxing.
More ramblings on Scrum, cycles, and ceremonies 👇
2) 💛 Give more positive than negative feedback
For those who receive it, feedback should act as a way to assess their overall behaviour. This means identifying things they get right, things that they don’t, and adjust accordingly.
This balance isn’t always met — many managers I know give an outsized amount of negative feedback with respect to the positive one. There is a tendency to believe feedback should be mostly corrective, which is false and causes two obvious problems:
Self-evaluation — if most feedback people receive is criticism, they will think their performance is bad.
Bias against feedback — people will associate feedback with negative emotions, start avoiding it, and handicap their own growth.
I sit down with Matt Van Itallie, who taught how to give feedback at places like McKinsey and Harvard. He is clear about this:
The ideal praise-to-criticism ratio has been studied extensively. Research indicates that in the highest-performing teams this ratio is >5:1, that is, people receive more than five positive comments for every negative one.
If this seems outlandish to you, think about people in your team. How much do they really do wrong, in percentage of their total actions? Chances are even your average performers do 80% of things right. You should acknowledge those as well.
More ideas on how to give good feedback 👇
3) 🎒 Make new hires ship code in a week
Checking how long it takes for a new hire to ship code to production is good way to understand how effective and practical your onboarding is.
Outstanding companies make engineers ship code within the first week. That requires two elements:
Good tooling — it is easy to setup the dev environment, CI/CD is reliable, deployment is not gatekept.
Good dev process — work is broken down in items that 1) are small, and 2) don’t need deep context to be addressed.
Titouan Benoit, CTO at Dotfile, explains how they do it:
We have created a Welcome CLI to easy install everything you need to run the local dev stack. The CLI is working on both MacOS (brew, npm, curl) & Linux (apt, npm, curl+custom install)
After that, in the backlog, we maintain issues with the label #first-friendly to pick the first issue. These issues are mainly small, with a bit of product value and well documented.
🎓 CTO Academy
My friends at CTO Academy deliver online leadership courses, coaching and community support to global tech leaders.
They share my same passion in wanting to arm ambitious tech leaders and managers with the knowledge, skills and network required to achieve the career impact they want.
To celebrate these shared ambitions they are offering every Refactoring subscriber a 20% discount to join their Executive Leadership Course, The Digital MBA for Technology Leaders.
To redeem this discount offer just use the exclusive coupon code refactoringspecial at checkout.
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
The insights about the balancing of positive and negative feedbacks are really interesting!
I am currently reading The Culture Map by Erin Meyer that, among others, touches also this point. It analyses how the background culture of the two people having the feedback discussion can change the understanding of the provided feedback.
I had never thought about this aspect but can recall a few situations in which having considered it could have been useful.