Iterating is hard, good reviews are not surprising, and EMs can actually code 💡
Monday Ideas — Edition #110
ℹ️ Bright Data — make your scrapers unstoppable
This week I am happy to promote Bright Data, which I have used for a long time to optimize our ScrapeOps 👇
Bright Data provides a single API to automate anything from proxy management to fingerprinting, unblocking, and browsers:
✅ Highest efficiency — achieves a 99.7% success rate with automated tools like IP rotation and CAPTCHA solving, reducing blocks and errors for 84% of dev teams.
⏱️ Get started in minutes — features a cloud-based, scalable infrastructure with no server setup needed, lowering maintenance for 81% of dev teams.
💸 Cost-effective — simplifies scraping by cutting infrastructure costs, with 92% of dev teams reporting lower operational expenses.
Back to this week’s ideas! 👇
1) 🔄 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 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. Bonus points if the existing feature is not performing well — which, instead, should be the whole point of iterating on it.
Also, when you don't iterate immediately on something, it becomes even harder to do it later, because of context switch, shifting priorities, and more.
As a consequence, to protect themselves, many product teams resort to trying to get everything right from the start — which leads to waterfall and invariably fails.
When you stop iterating, things are not lean anymore — they are just half-assed all over the place.
2) 🏅 Performance reviews shouldn’t be surprising
Last week we published an article about salary reviews. Nicola did an awesome job with it, and it shows: the newsletter prompted many replies and some great conversations.
Some of these chats weren’t much about reviews per se, but rather about communicating them well. In fact, I believe this is often the most important aspect of the whole process.
Last year I wrote a full guide on performance reviews where one of the main takeaways was: if people are surprised by your review, you did something wrong.
In fact, I believe performance reviews are mostly useful as a prime moment to act on feedback — by setting goals and priorities — rather than sharing it.
In healthy relationships, feedback is frequent and mainly shared 1) on the spot, and 2) in recurring venues like 1:1s. So, feedback in performance reviews should mostly ratify what has already been discussed privately.
You can find the full guide below 👇
3) 🔨 Things you can code as an EM
About a month ago, we published an article on how to stay technical as an engineering manager.
Among other things, it included a section about coding. As an EM, you often have limited time and a rather unpredictable calendar — so, if you want to do some coding, what should you spend your time on?
I surveyed some of the best EMs I know, and here are their best bets:
Dev tools 🚚
Do work that improves the developer experience of your team. This is a favorite of mine, because at once it 1) gets you in touch with important pieces of your tech stack, and 2) keeps you aware of the daily life of your engineers.
This way, if your engineers have a shitty experience, you’ll know it — and you’ll be putting in work to improve it, which helps win their trust.
Bugs / tech debt 🦠
Bugs and small pieces of debt are perfect candidates for some coding in your spare (work) time. If your team has some fixed allocation on maintenance, you can join them.
On top of this, joining on-call rotations as a manager is a great way to stay in touch with the state of your tech. However, only do this if you can be as capable as others to take care of things: don’t do it if you constantly need to page your secondary.
Tech exploration 🔭
You can also take some time aside to explore cool technology that may or may not be useful in the future. You can build prototypes, write down your considerations, and discuss your findings with the team.
The only caveat is that, for reciprocity, if you take some time for exploration, make sure you allow your engineers to do the same.
More ideas about staying technical in the full piece 👇
And that’s it for today! If you are finding this newsletter valuable, consider doing any of these:
1) 🔒 Subscribe to the paid version — if you aren’t already, consider becoming a paid subscriber. 1500+ engineers and managers have joined already! Learn more about the benefits of the paid plan here.
2) 🍻 Read with your friends — Refactoring lives thanks to word of mouth. Share the article with your with someone who would like it, and get a free membership through the new referral program.
I wish you a great week! ☀️
Luca