Monday 3-2-1 – best employees, coding managers, psychological safety 💡
Edition #24
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) 🌟 Values and best employees
There is plenty of advice that says we should write down the core values of our team/company — the ones that will “define culture” — but there is little advice about how to do it.
A useful trick is to think about your best employees, and work backwards from there.
What makes them special?
What do they do that you would like to see more of?
This should be enough to get you started!
2) 🧑💻 Coding as a manager
Should you keep coding as a manager? Is there a way to do so without turning into a bottleneck for your team? My friend Louis Bennett from Reforge gave me great advice on this:
🔨 Take on small, non-urgent tasks — It’s okay to take some tickets when you’re a manager. One strategy I’ve used effectively is to keep a queue of small work items for anyone to tackle between larger tasks. (Using the Eisenhower Matrix methodology, they should be important but not urgent.) If a work item can be started and then set aside easily mid-sprint – and assuming it’s not a bug that’s a direct result of a teammate’s previous work – it fits perfectly in this queue.
👯♀️ Pair with others — You can change your focus from solo work to pairing. By working closely with members of your team, you can help them uplevel while you also get deeper insight into how they work.
⏱️ Be realistic about your time — The amount of coding work you can do in a given work week is inversely proportional to the number of people whose work you are responsible for.
When it comes to the time you can spend coding, I like to approximate it mathematically as:
(1 - min(team_size/4, 1)) * working_hoursE.g. if you manage a team of 3 developers, and an engineer spends 32 hours/week on sprint work, you should be able to budget 8 hours. Responsible for the work of more than 4 people? Budget zero.
Louis also wrote a great guest post a few months ago covering the dreaded shift from engineer to manager 👇
3) 🗳️ Retrospectives and psychological safety
90% of a retrospective success is about psychological safety.
If you make people comfortable speaking their mind, the process will largely take care of itself.
Norm Kerth summarizes this in his prime directive:
Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.
In a healthy conversation, people don’t make it personal and don’t take it personally. They listen with an open mind, and focus on improvement rather than placing the blame.
More ideas on how to run good retrospectives 👇
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