Hey, Luca here, welcome to a weekly edition of the💡 Monday Ideas 💡 from Refactoring! To access all our articles, library, and community, subscribe to the full version:
Resources: 🏛️ Library • 💬 Community • 🎙️ Podcast • ❓ About
🎨 Brought to you by Atono!
This free email is brought to you by today’s sponsor, Atono!
Atono is the complete platform for product teams to plan, build, run, and improve — all in one place. It’s built by a team of industry veterans with strong opinions on how software should be made, and they’re building it fully in the open.
Personally I am a big fan of the product and last week we also published a full piece with the Atono team about how to create a successful product engineering culture.
You can learn more about Atono below 👇
1) 📗 Accelerate ≠ DORA metrics
A few months ago we read Accelerate in our community book club.
This is the seminal book about measuring software delivery, which gave origin to the famous DORA metrics.
However, Accelerate is about much more than metrics. The research explored what capabilities across culture, process, and technology, make engineering teams successful, and here are my favorite findings:
💰 Engineering excellence drives business success — The research proves that strong software delivery performance directly correlates with profitability, market share, and productivity. These aren't just tech initiatives: they're bottom-line contributors.
❤️ Good performance requires good culture — You can't implement new tools and expect results without a generative culture. Trust, psychological safety, and collaboration aren't nice-to-haves—they're prerequisites for improvements to stick.
⚙️ Speed and stability go hand-in-hand — Elite teams don't trade one for the other. The same practices that enable faster delivery (CI/CD, automated testing) also create more reliable systems with lower failure rates.
✨ Continuous deployment reduces burnout — When deployments are automated and frequent, they stop being terrifying events. CD adoption correlates with reduced deployment pain and better job satisfaction.
You can find our full review below:
2) 🏆 Successful teams do three things right
Speaking of successful engineering teams, we did our own research early this year to figure out how teams work and what practices lead more likely to successful outcomes.
We ran a thorough survey and published our findings after a few weeks.
Out of all the questions we asked, there are three we are particularly fond of:
Is engineering well-regarded among the leadership / non-tech stakeholders?
Are you happy about your team’s dev practices?
How often projects ship on time?
These are the elements that correlate the strongest with the highest number of positive behaviors. That is: the gradient of answers for these questions is most likely to be matched by a similar gradient in other behaviors 👇
Some examples (see the picture for more):
In teams where devs are very happy about dev practices, vs those where they are neutral, focus time is 30% more satisfactory.
In teams where engineering is not well regarded by non-technical stakeholders, vs those where it is, people need to wait for others 29% more time.
In teams that ship 75% of projects on time, vs those who ship only 30%, people spend 28% more time as it was planned.
So, the first two questions are strictly qualitative and collect the opinions of both technical and non-technical stakeholders. We believe these are extremely important: in fact, most quantitative practices (e.g. how often you ship, how much time is spent on KTLO, …) depend on the team’s context and do not decisively sort good teams from bad ones. Conversely, we would be hard-pressed to find low performing teams where all stakeholders—engineers, managers, and leadership—are happy.
The last question is about predictability. We found that shipping on time correlates strongly with most good behaviors we polled for. By most measures, predictable shipping is even more important than frequent shipping.
So, what kind of traits are exhibited by teams that ship on time and where stakeholders are happy? You can find the full report below 👇
3) 💣 We are destroying software
I keep thinking about the interview we did a few months ago with Salvatore Sanfilippo, creator of Redis and one of the most successful open source authors of all time.
During the interview, Salvatore delivered a strong critique of unnecessary complexity in modern software, particularly targeting large tech companies:
"Big entities like Google cannot design good things. They did a terrible job with HTTP, and with new protocols. For small gains, there are huge complexity gains that make the web less accessible, less comfortable."
He argues that the root causes of this complexity are:
🔬 Over-engineering — companies like Google are staffed with "PhD engineering types" who optimize for minimal performance gains (like 3-5% faster) while ignoring the massive complexity costs.
🧩 Organizational structure — the separation between frontend and backend developers creates artificial boundaries that lead to duplicated work, like in state management.
⚖️ Different priorities — large companies optimize for different problems than most developers face.
He also explained how web development became unnecessarily complex:
"Framework after framework the web became slower and more complicated. And it's the same web forms, buttons and listings... 20 years ago was the same. But it was a much simpler stack. It was faster with slower computers."
Salvatore sees this as a difficult cycle to break because developers need to learn these complex technologies to remain employable, even though they recognize the inefficiency.
Here is the full interview with Salvatore:
You can also find it on 🎧 Spotify and 📬 Substack
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
Great reading! I like how you remind us that Accelerate is culture, process, and tech, not just a scoreboard.