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.
🔨 Retool
I have been a big fan of Retool for years now, and I am happy to promote it in the newsletter today.
Retool helps developers build internal software faster. You can read and write back to any database or API, and quickly assemble apps with 100+ pre-built components.
Then, you can customize your apps using JavaScript as and when you need, and ship your app with access controls - all in 1/10th the time.
Back to this week’s ideas! 👇
1) ✨ Engineers vs Product Engineers
The push for the Product Engineer role fits a broader trend in making product / tech roles wider and giving people more ownership and autonomy.
To me, the Engineers vs Product Engineers feud resembles the one between Product Owners and Product Managers.
Product Owners have mostly tactical responsibilities. They groom the backlog, write user stories, prioritize what to do next, and attend all the Agile meetings. Their focus is short to mid-term.
Product Managers have more strategic responsibilities. There is overlap with Product Owners about how they both shape what to do next, but PMs are also responsible for the product vision and success. Their focus is mid to long-term.
In PM-based teams, there is the opportunity for engineers to step in and take on some of the PO’s duties that the PM is not going to cover.
In high-performing teams, PMs provide direction and support but most often leave Engineers in charge of creating tickets and managing actual tasks. Requirements focus on outcomes, rather than how to explicitly build stuff, leaving engineers free to make decisions that matter.
This culture promotes more ownership and enables personal growth.
More on product engineers 👇
2) 🔨 Stacked diffs and trunk-based dev
Many big companies like Facebook and Google have a code review workflow that is not based on PRs, but rather on stacked diffs.
Stacked diffs are a way to have your code reviewed without firing up a PR. You take a portion of your local changes and make it available for review. You can stack these changes into multiple requests for reviews, so you never get stuck waiting.
This workflow, other than being faster, allows to (mostly) get rid of branches and work in trunk-based development mode instead. In turn, there is convincing evidence that teams who adopt trunk-based workflows achieve higher velocity and faster turnaround.
If this seems crazy to you, you may reflect on the fact that engineers working in some of the best companies in the world commit directly to master all the time (and often on a monorepo), unless they have a reason not to.
More ideas on code reviews 👇
3) 💼 Allocate engineering time for hiring
One of the most common mistakes I see in hiring processes is not explicitly allocating enough engineering time for it.
Engineers, in fact, need to be constantly involved:
✍️ They design the interview process — create and update exercises, take-home tests, questions, and more.
📞 They interview candidates — and manage the subsequent feedback process.
📋 They contribute to writing the job post — by setting requirements and responsibilities.
🧑🤝🧑 They bring in new candidates — via referrals.
Time spent on hiring should be taken into account in the general planning, because it is sizable.
Luca Marchi, Software Engineer at Picnic, reports on this:
All the senior engineers on the team have 2 hours per week allocated for the interviews.
In my experience, you may need even more time than that. Interviews require prep work, writing notes, decision meetings afterwards, and more. It is not uncommon for senior engineers to spend >10% of their time on hiring.
Joel Spolsky similarly advocates for involving most people on the team in interviews:
You should always try to have at least six people interview each candidate that gets hired, including at least five who would be peers of that candidate. [...] If even two of the six interviewers thinks that a person is not worth hiring, don’t hire them.
Six people might be too much for someone, but the main takeaway is that hiring needs wide consensus. That’s because you are not only testing for technical prowess, but also a wider cultural fit. You want your people to feel 1) excited to work with the candidate, and 2) committed to the hiring decision.
More on designing hiring processes 👇
📣 Join the Refactoring Talent Club
If you’re looking for a new gig, join to get personalized opportunities from hand-selected companies. You can join publicly or anonymously, and leave anytime.
If you’re hiring, join the Refactoring Talent Club to start getting bi-monthly drops of world-class hand-curated Engineering people who are open to new opportunities.
And that’s it for today! If you are finding this newsletter valuable, 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