ποΈ Join our Workshop on Engineering Maturity!
Last week we published our exclusive industry report about how engineering teams use data to work better.
It was the result of surveying 300+ CTOs, VPEs and managers to explore the real-life use cases for how leaders are driving developer productivity using engineering metrics.
On January 29th we are hosting a workshop, together with LinearB CTO Yishai Beeri, to go through the report insights.
Here is what weβll discuss:
π A cohesive view of engineering metrics β learn how to connect popular frameworks like DORA and SPACE, and how to assess the full scope of your teamβs performance.
π Real-world playbooks β actionable steps to implement data-driven practices in your organizations and how to leverage data for continuous improvement.
πͺ Real stories from the trenches β understand how real-world teams use metrics to drive change.
You can register below π
1) π The Return of the Waterfall
Earlier last year I had a fantastic chat with Kent Beck on our podcast.
One of the most insightful bits was about the evergreen feud between Agile and Waterfall.
Kent believes Waterfall has made a sneaky comeback in many circles, including not only big tech, but also small and high-growth startups, whereβespeciallyβit shouldnβt belong.
In fact, Kent says that Agile vs Waterfall is mostly about power structure, rather than business opportunity:
β¬οΈ Waterfall β is about hierarchical decision-making, where what needs to be done is defined and transmitted in top-down fashion.
π Agile β has a bottom-up feedback loop that is a threat to traditional power structures. It empowers engineers, designers, and builders.
So, while Agile obviously leads to better products, it is also uncomfortable for those used to being at the center of decision making and power.
Adopting Agile requires embracing such discomfort, letting go of egos, and truly empowering engineers.
We collected the best ideas from our podcast season in this article from last year π
2) πͺ£ Fighting the sunk cost fallacy in software
It is the start of a brand new year, so itβs the perfect time toβ¦ review our cognitive biases β said no one ever! Yet, here is me writing about the sunk cost fallacy.
Sunk cost fallacy is our tendency to continue investing in a project/activity because of the time/effort/money we have already put into it, regardless of whether the future costs outweigh the future benefits.
In software, one of the ways this is most often displayed is by over-committing to an initial plan, even when it becomes more rational to invest resources in a different way.
But the final goal of software, of course, is to deliver value, not to deliver plans, so if you find better ways to deliver value to users, you should change the plan and go for it.
A practical way to limit the sunk cost fallacy, other than talking yourself out of it, is⦠to limit costs. For example, to avoid the temptation of fixating on a plan, invest in a plan that is detailed just enough to support your decision making, not more.
Or, to avoid sticking too long with a leaky abstraction because of all the work you have put into it, create small abstractions in the first place.
In engineering, in most cases, smaller is better. This is obvious to hear, but it takes a lifetime to master.
I wrote a long piece on my favorite mental models last year, and itβs one of my favorite articles π
3) π
Talent at all costs
One of the most influential books I read last year was No Rules Rules, about Netflixβs culture.
The firstβand probably most importantβprinciple of such a culture is talent density, which means: only hire and retain the best.
This rule is backed by a three-part belief: 1) an agile company needs innovators β 2) innovators are high performers β 3) high performers thrive among other high performers.
The last part is crucial. An A+ team makes everybody perform at their best, and helps with retention too. But it is also incredibly hard to achieve. So Netflix developed very practical recipes about it, especially when it comes to retention and firing:
π Retention β Pay top dollar
Hiring great talent is hard, so once you bring it on board you need to do everything in your power to retain it.
To do so, Netflix pays top-of-market salaries, and even encourages employees to regularly window-shop to figure out their true market value. If they receive a superior offer, Netflix is happy to match it.
In the book it is unclear how managers figure out top market value for their employees, outside of employees telling them after shopping around, but Netflix has indeed a reputation for paying top dollar, so I am not going to nit-pick.
πͺ Firing β The Keeper Test
Netflix notoriously fires fast, and gave its approach a name: The Keeper Test.
Each manager is supposed to periodically run their directs through the keeper test. For each of them, the manager needs to ask herself whether, faced with the possibility of losing them, she would fight to retain them. If the answer is no, the person needs to be let go.
Hastings admits this approach is ruthless and has the potential to create fear and anxiety. Netflix counters this in two ways:
Stick to A+ talent β top performers are less concerned with job security because they know they can always find a new job.
Remove the shame of being let go β Hastings is fond of saying the company is like a professional sports team. In a sports team turnover is natural, and there is no shame in changing jerseys.
π My take
The talent density ideas are among the most controversial in the book β or, at least, it is not advice that all companies can apply, because hiring well is a zero-sum game. Just like paying top dollar is.
Netflixβs core belief here is that, if anything, top talent is still underrated*,* especially in tech, so you should arbitrage that. In a nutshell: top engineers, paid top of the market, are still a bargain.
You may or may not agree with it, but still, this is the cornerstone of Netflix culture, and a lot of the advice in the book, in terms of organizational principles, evolved by having this in mind.
You can find the full summary + my review of the book here:
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