Monday 3-2-1 – balancing engineering work, strategy vs execution, referrals💡
Monday 3-2-1 – balancing engineering work, strategy vs execution, referrals💡
Edition #21
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.
🌱 Tech Career Growth
It is no secret that there isn’t much valuable content out there to help developers and tech leaders grow their careers. It is one of the reasons why I started Refactoring.
Recently I found the Tech Career Growth newsletter by Alex and Rahul, which is a great read if you're looking to advance your career as a developer.
Alex and Rahul also created Taro, which hosts high-quality discussions about software careers. Example: how to master your performance review (question from a Mid-Level SWE at Google)
This is not a sponsored post — it is just me recommending fellow creators who I believe are doing a great job!
Back to this week’s ideas! 👇
1) 🏦 Balance your engineering investment
The best way to understand where your time is going is to look at the balance of your engineering investments.
Unless you already have a good way of doing this, you can start with the Balance Framework, which helps you understand the nature of the engineering work.
With that framework, work is divided into two main areas:
🔴 Mandatory investments — to support running the business (keeping the lights on, KTLO).
🟢 Elective investments — anything that is up for discussion and can be prioritized.
Elective investments are further divided into three categories:
🔨 New things — work towards your business objectives, like new products, features, or integrations.
🔧 Improving things — improvements to existing features, including performance, reliability, and security.
⚙️ Productivity — improvements to engineering productivity. This may affect operations and other departments’ productivity as well.
Categorizing all of your work helps you have conversations based on data rather than intuition. You can define priorities, defend them based on grounded evidence, and build a sustainable work balance.
2) ⚖️ Tech execution vs tech strategy
As a tech leader, you should pay attention to your duties shifting from execution to strategy.
Your work in fact becomes divided into two areas:
🔨 The work with your engineering team
💼 The work with non-technical stakeholders
With your engineering team, you get to make design choices, guide development and review other devs' work. This is an evolution of your execution skills, and it can be a linear journey from your days of "pure" individual contribution.
With other stakeholders, instead, you discuss technical requirements, risks, and the overall tech direction of your product. This is a different beast as your focus shifts from how things should be built to what should be built and why.
This can be a hard change to navigate.
Designing a good technical strategy is a good starting point — as it provides a high-level direction that makes planning and negotiations simpler.
It also rallies your engineering team around a clear purpose, which motivates people.
3) 🗣️ Referrals bring top talent
Referrals are the best way to bring in high-quality candidates. Full stop. If you are a growing company, they will naturally be your main hiring channel for a long time.
Stripe hires 4x more engineers via referrals than via any other channel.
So you may want to encourage referrals by setting generous rewards for people who bring them in.
How generous? A head hunter usually takes 15-20% of the yearly gross salary. Within your team, you may settle around ~10% after the probation period, and make the formula simpler by defining fixed amounts based on the role of the candidate.
Pamela Gotti, CTO at Credimi, leverages referrals to make people participate actively in the hiring process:
We do encourage everyone in the engineering team to be owner of the hiring process too, meaning that referrals are really encouraged, and everybody is aware that the responsibility of growing the team is not HR's only :)
The [hiring] process for referrals is the same, except that the first [screening] step is not done by HR but by whoever reaches out to the candidate.
The flip side of referrals is that they may hurt diversity. By relying too much on them, you risk creating a workforce with too much of the same background. You may pair referrals with a good outbound strategy to counter this.
More on creating a good hiring process 👇
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
Perfect 3 topics on today’s list!
All of the topics are relevant to my current challenges and give food for thought and experimentation!