Monday 3-2-1 — co-creating processes, iterations, hiring vs promoting managers
Edition #10
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 be receiving 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:
Hey! This is the 10th edition of the Monday 3-2-1 emails. This started as an experiment about sending more short-form Refactoring emails, alongside the regular ones.
What do you think about them? Your feedback matters!
Also, if you have any ideas to make them better, please tell me! Either in the comments or by replying to this email.
1) 🎽 Co-create processes with people
Engineering Managers often try new things to make their team work better. In the past, I personally tried:
Creating a dedicated weekly cycle for maintenance tasks.
Tracking basic engineering productivity metrics, with a monthly retro meeting.
Setting up a centralized process for writing release notes to be shared with all internal / external stakeholders.
When I think of new processes, I always wonder: will this work? Will people be happy about it? Is it just a hassle?
Over time I learned that the most effective way to counter these doubts, and reduce risks, is to involve engineers in the creation process, from day one.
Share what you want to obtain (goals), and a rough draft of the process you have in mind, and work with them to get to the MVP (minimum viable process).
This way you will get a better result, and people will be already invested in the process from day one. Win-win!
2) 🔨 Iterating is hard
In product and engineering we talk all the time about iterating.
However, I have found that this is harder than it looks, and only the best teams truly iterate over features.
Iteration, in fact, is most often discarded in favor of new features. That’s because getting buy-in for the new shiny thing is usually easier than justifying spending more time on what’s already there. Even more so if the existing feature is not performing well — which is instead the whole point of iterating on it.
Also, when you don't iterate immediately on something, it becomes very hard to do it later, because of context switch.
So, to protect themselves, many product teams resort to trying to get everything right from the start — which leads to waterfall.
When you stop iterating, things are not lean anymore — they are just half-assed all over the place.
3) 🎒 Hiring vs promoting managers
It is common advice that you should strive to promote (move) existing employees into management roles, rather than hiring managers from outside.
That’s for good reason. Promoting managers from within has many upsides:
They may have held implicit manager behavior for some time already, so you are just making it formal.
Promoting folks with long tenure means they often recruited their (now) reports. That already feels like manager behavior.
Guaranteed fit with the team.
However, you can only promote managers who have an interest in growing that way. My advice is not to over-do it, and to setup an off ramp (e.g. every 6 months) for fresh managers who want to go back to IC.
In the end, if you are growing fast, it is inevitable that you will hire most of your managers from outside. If you assume that just a fraction of your senior / long-tenured ICs will want to shift into management, you just won’t have the headcount to cover all the spots.
And that’s it for today — I wish you a great week! 🚀 If you liked the article, consider doing any of these:
1) ❤️ Share it — Refactoring lives thanks to word of mouth. Share the article with your team or with someone to whom it might be useful!
2) ✉️ Subscribe to the newsletter — if you aren’t already, consider becoming a paid subscriber. That also gives you access to the community and the curated library.
p.s. 30-days money-back guarantee, no questions asked!