Monday 3-2-1 – Feedback, tech strategies, generalists 💡
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:
1) 🎽 Evalutative vs Developmental Feedback
I recently learned the difference between evaluative and developmental feedback.
It’s one of those mental models that seem so obvious in hindsight — and so useful to consider.
Evaluative feedback is when you tell someone where they stand (e.g. you are doing great and you will be promoted — or not)
Developmental feedback tells someone how they can improve.
The evaluative feedback tends to override everything else in the mind of the receiver.
For this reason, great performance reviews need to bring an outsized amount of developmental feedback to the table – to counter the bias of people who tend to listen more to the evaluative one.
More on giving feedback 👇
2) 🔨 Tech strategy is a conversation
The technical strategy of your company is the plan of how engineering enables the product and company strategy, and drives them forward.
In the best companies, this doesn't happen strictly top-down, but more as a conversation.
Product and Engineering are mutually influenced — many of the most successful products of all times where in fact enabled by engineering breakthroughs.
📱 Steve Jobs was shown a prototype of a multi-touch screen and then decided they could build a phone with it.
🎧 Spotify decided to go all-in on mobile because it was the right choice business-wise and it was finally technically viable (encoding + buffering tech + mobile networks performance)
3) 🎒 Generalists are open
Generalists have several strengths, and they all come down from a major one: they are open.
If you are a generalist and you are looking for an edge you may have over specialists, it isn't in your skills, but more in the way you think.
That’s because when you specialize in something, you slowly become biased. Your toolbox is made of some specific tech and processes, and you risk to become overly attached to them, because you feel your career depends on them.
You risk to move from the "choose the right tool for the job" mode, to the "when you only have a hammer, everything looks like a nail" mode.
This is not inevitable. The best specialists I know keep themselves updated and jump timely on new trends. But it's not always easy — you may find yourself in local optima that are uncomfortable to leave.
Generalists, instead, keep optionality by developing a wide array of skills. They don't feel attached to a particular one and are more open to pick up new things.
More on generalists 👇
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!
p.s. 30-days money-back guarantee, no questions asked!