Software ownership, removing controls, and tech simplification 💡
Monday Ideas — Edition #162
1) 🤖 AI coding is not enough
This idea is brought to you by today’s sponsor — CodeRabbit!
Last month we published a long article on how code reviews change with AI, and it is one of the most popular Refactoring articles ever!
It was made possible by a lot of chats I had with the folks at CodeRabbit, which is the #1 AI tool (# of installations) on both Github and Gitlab.
One of the core ideas of the article is that the dev process is a pipeline that includes several steps — so if we only increase the throughput of some parts thanks to AI, we are going to create bottlenecks elsewhere.
To reap the benefits of AI allowing us to write more code, we need to speed up also code reviews, testing, and documentation, otherwise we will produce more toil for humans in some of these steps.
So, since AI IDEs like Cursor are already commonplace, AI code reviews are not a nice-to-have anymore — they are essential to avoid drowning in PRs (or accepting a lower quality output). And that’s where CodeRabbit steps in 👇
2) 🎽 Teams own software — not individuals
In February, the legendary Charity Majors published an original article on Refactoring, called In Praise of “Normal” Engineers.
The article had an incredible reception: it was re-published (among others) by the IEEE, and Charity brought it on stage at LDX3 last week, where I sat among the audience in awe 👇
The article is a strong rebuttal of the common narrative around 10x engineers, and one of the strongest points that Charity makes is that individual engineers don’t own software — teams do.
It doesn’t matter how fast an individual engineer can write software: what matters is how fast the team can collectively write, test, review, ship, maintain, and revise the software that they own.
That’s because everyone uses the same software delivery pipeline: if it takes the slowest engineer at your company five hours to ship a single line of code, it’s going to take the fastest engineer at your company five hours to ship a single line of code. The time spent writing code is typically dwarfed by the time spent on every other part of the software development lifecycle.
So, if you have services or software components that are owned by a single engineer, that person is a single point of failure. Which is not to say this should never happen.
It’s quite normal at startups to have individuals owning software, because the biggest existential risk that you face is not moving fast enough, not finding product market fit, and going out of business.
But as you start to grow as a company, as users start to demand more from you, and you start planning for the survival of the company to extend years into the future… ownership needs to get handed over to a team. Individual engineers get sick, go on vacation, and leave the company, and the business has got to be resilient to that.
If teams own software, then the key job of any engineering leader is to craft high-performing engineering teams.
If you must 10x something, 10x this. Build 10x engineering teams.
You can find the full article below 👇
3) 📕 Remove controls
Speaking of 10x engineers, I feel that one of the companies that contributed the most to this mindset is Netflix, which prides itself on hiring only the top 1% and published an extremely popular (and opinionated) work about its culture: No Rules Rules.
While I admit some of the advice feels zero-sum-ish or straight not applicable to everyone (by definition, not everyone can hire the top 1%), there is a part I absolutely love, which is about removing controls.
Netflix believes in radically trusting people on your team and removing all kinds of guardrails that you can find in traditional companies, and they recommend doing so in three steps:
3.1) Remove policies 📑
Early in the book the authors recall how they ended up removing Travel, Expense, and Vacation policies.
This includes a lot of nuance and sensible advice, acknowledging well-known risks (e.g. no vacation policies, when left unsupervised, tend to make people take less vacation) and detailing how the process worked for Netflix.
The goal, however, is simple: reduce complexity and trust people's judgment. Policies are the simplest way to start doing it.
3.2) Share everything 🤝
The next step in reducing rules is about data.
Netflix shares pretty much everything with their employees: goals, financials, salaries, business performance — everything. It does so despite being a public company, which poses very practical risks, but their CEO believes the upsides easily trump the downsides.
3.3) Lead with context 🎯
The final goal of removing controls is about empowering everyday decisions. Netflix wants people to make their own calls, without being told what to do, nor asking for approval from their bosses.
To achieve this and make it effective, managers need to lead with context: they need to share everything they know about the goals to be achieved and what good looks like, so that people and teams can design their own initiatives and go for them autonomously.
We wrote a full review + summary of No Rules Rules for our Book Club 👇
4) ✂️ The great tech simplification
I believe that, over the past 15 years, web technology has become more complex, instead of the opposite.
I also had the fortune to speak with many incredible leaders about this, from DHH to Guillermo Rauch, and they all pretty much agree.
One of the likely reasons why this happened is that over time we brought in a lot of layering from big tech. In fact, a lot of the most relevant open source work of recent years comes from there.
In turn, tech layering led to job layering, creating some big divides, for example between backend and frontend engineering.
I believe we will spend the next decade undoing this. Signs were already there — think of the surprising resurgence of Ruby on Rails, or JS frameworks becoming increasingly full-stack — but AI is now enormously accelerating this because, if anything, it gives developers basic proficiency on any language/piece of tech.
So, think of all those features that are, like, 80% frontend + 20% backend, or vice versa: chances are these can now be owned by a single guy.
And the trend will only accelerate, by rewarding engineers who can own things from top to bottom.
As we discussed in recent articles, this doesn’t only apply to code. AI + good tooling reduces engineers’ cognitive load, opening up avenues for taking on more responsibilities. One angle is, of course, more coding (== full-stack), and another one is going after product.
So, full-stack engineering convincingly looks like the future of software engineering, and product engineering looks like the future of full-stack engineering.
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