1) 💬 Join the CTO Craft Community
This idea is brought to you by this week’s sponsor, CTO Craft!
In September I will keynote for the CTO Craft Con in Berlin — if you are there, let’s meet!
I have known the CTO Craft folks for a long time, and if you are looking to level up your leadership skills, you should definitely join their community, which includes 18,000+ tech leaders just like you.
Whether you’re navigating your first CTO role, or sharing wisdom from years in the game, the membership gives you access to expert mentoring, exclusive events, and a network of supportive peers.
It’s all about learning, sharing, and growing together 👇
2) 🪴 Decent performance, for an inordinate amount of time
These days I am reworking some of my habits, especially around journaling (will soon write more about it!), which made me think of Atomic Habits, which we reviewed last year.
One of the takeaways from Atomic Habits is that overnight successes are mostly a myth. When you look closely, you find that success stories are usually the result of producing decent performance over an inordinate amount of time, rather than extraordinary, one-off feats.
This resonates with my experience. The most successful people I personally know, in fact, are all 1) extremely disciplined and 2) willing to think long term. And in a world where skills only get cheaper—thank you, AI—this mindset may be the only true edge we have left.
The more modern culture pushes us towards instant gratification, the more the ability to plan and execute on a years scale gets scarce and valuable.
So the question becomes: what is it that 1) brings compounding value, and that 1) you are capable and willing to do for 10-20 years?
Linking here our full review of Atomic Habits, which is one of my favorite books 👇
3) 🔍 Hire for the unlearnable
When you hire engineers, what you should test them for totally depends on the role, but there is a key question you should ask yourself:
What can you mentor people on, vs what should they bring from home?
Most of the times, you should only hire for the latter.
That’s because of two factors:
🎓 Great teams create great mentors — who are happy to pass on knowledge and grow younger folks. We always ask ourselves whether people on our team are learning, but are they teaching, too? Mentoring colleagues is an incredible growth experience.
📈 Smart people learn fast — usually faster than we account for. That’s especially true in the AI age.
This also means that in well-functioning teams, where senior leaders act as mentors and knowledge is transferred efficiently, you can hire mostly junior engineers and get away with it.
Charity Majors wrote an incredible piece in the newsletter a couple of months ago, which discussed this among other things.
So, you should hire for skills that are hard to learn, or those where your team is unable to mentor new hires. In today’s terms, this usually means less memorization and more quality thinking:
📇 Memorization — is specific knowledge about frameworks and languages. With AI, this is devaluing at a pretty fast rate.
🧠 Quality thinking — is system design, product mindset, and good communication. This is timeless and still makes a huge difference.
My hard and fast recipe is: for quality gaps—hard-won experience that your team lacks—hire senior talent; while for pure bandwidth, hire junior talent.
We wrote a three-part series about what good hiring looks like in 2025. You can find it below 👇
4) 🧑🚒 Heroic culture is anti-engineering
Hardcore culture seems to be naturally embedded in startups’ DNA, and these days it feels on the rise again, fueled by RTOs, various Elonisms, and more.
There is nothing inherently wrong with hustling and (occasional) long hours, but hustling cultures often degenerate into heroic cultures.
In heroic cultures, effort is rewarded instead of outcome. So you may end up rewarding the guy who puts out the fires, rather than the one who prevents them from happening.
No need to say, the best engineering work is usually about the latter. Nothing glamorous or heroic: it is invisible, and even boring.
This reminds me of the famous WWII story about planes and survivorship bias, which by now I feel everybody knows, but it is always worth mentioning.
During the war, the US military analyzed planes that were coming back from engagements, to figure out where they would need the most armor. For a good while, they focused on the areas where, statistically, planes got hit the most, and reinforced those.
Abraham Wald, a Hungarian mathematician, pointed out that those numbers only considered planes that came back — despite getting hit. Engineers should have focused on areas that apparently didn’t get hit much, because planes that got hit there probably crashed.
If the aircraft is only reinforced in the most commonly hit areas, this is survivorship bias because data from crashed planes is ignored; in fact, those hit in other places did not survive.
So, just like with planes, what’s most visible ≠ what’s most valuable.
And that’s it for today! If you are finding this newsletter valuable, consider doing any of these:
1) 🔒 Subscribe to the full version — if you aren’t already, consider becoming a paid subscriber. 1700+ engineers and managers have joined already! Learn more about the benefits of the paid plan here.
2) 📣 Advertise with us — we are always looking for great products that we can recommend to our readers. If you are interested in reaching an audience of tech executives, decision-makers, and engineers, you may want to advertise with us 👇
If you have any comments or feedback, just respond to this email!
I wish you a great week! ☀️
Luca