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 • 📣 Advertise
1) 🔒 The startup guide to global compliance
This idea is brought to you by today’s sponsor, Vanta!
Growing across markets? This guide helps you cut through SOC 2, ISO 27001, GDPR, and more — so you only focus on what matters for your stage and scale.
Built for startups that need to move fast, not hire a full-time compliance team 👇
2) 🔗 Theory of Constraints
One of the most frequent themes I hear about AI is that it’s hard to use it a lot on something, without creating bottlenecks elsewhere.
Use it to write more code? More stress on code reviews. PMs create more prototypes? Engineers get more work to do. And so on.
This made me think about the Theory of Constraints (TOC) — a model that views any system as being limited by a very small number of constraints, and, more immediately, by its weakest link. The corollary of TOC is that, to improve the performance of a system, you should focus on bottlenecks, one at a time.
For example, you may measure the various steps of your release process and discover that the biggest bottleneck is the time the code spends idle waiting for review. Or you may trace your API calls and figure out that the largest chunk of response times come from the database.
TOC was introduced by Eliyahu M. Goldratt in his 1984 book titled The Goal. The author suggests a five-step process to improve a system’s performance:
🔍 Identify — the system’s constraints.
🎲 Decide — how to exploit the system’s constraints.
🔀 Subordinate — everything else to the above decision.
⬆️ Elevate — the system’s constraints.
🔄 Repeat — once a constraint is addressed, you should move to the next, in a continuous improvement cycle.
I wrote a full list of my favorite mental models in this article last year 👇
3) 📊 Leading vs lagging software metrics
This whole bottlenecking stuff also made me think about a chat I had with Abi Noda, CEO of DX, where we discussed the infamous “# of commits / day“ metric. We agreed it’s somewhat useful to measure, but that obviously becomes toxic when set as a target.
But… why? How can data give useful directional information, but become bad if we try to optimize for it?
The answer lies in the difference between leading and lagging indicators:
➡️ Lagging indicators — show results of past actions (outcomes)
⬅️ Leading indicators — predict future outcomes (inputs)
Lagging indicators change slowly, are easy to measure, but hard to influence directly. They validate long-term success, but you can’t use them to change direction.
A product example: revenues vs feature adoption. Revenue validates success, but you can’t just set a higher revenue target and wait. To improve revenue, you need something actionable like feature adoption speed—a leading metric.
The number of commits per day is lagging, as are DORA metrics and most quantitative engineering metrics. You can’t optimize for them directly because they’re downstream of the dev process. When you treat them as upstream metrics, you reverse causation.
So, what’s leading in developer productivity? As of today, the most convincing answer is developer experience. Good satisfaction across the usual suspects (focus time, no waiting, ease of release, …) predicts good speed and quality.
You can find more ideas about measuring dev productivity in this piece 👇
3) 🎙️ The Rise of Local-first Software
Earlier this year I interviewed Adam Wiggins, co-founder of Heroku. Adam also introduced the concept of “local-first software” in a 2018 essay, which has since grown into a movement.
He defines it as combining the best of two worlds:
“Local-first is kind of having your cake and eating it too. It’s getting the collaborative shareability that we associate with web and cloud apps like Google Docs... but also getting back data ownership and user agency.”
Here are the key qualities of local-first software:
🔐 Data ownership — users retain control and ownership of their data.
🌐 Offline-first — applications work seamlessly offline, enhancing user agency.
🤝 Collaboration — enables real-time collaboration similar to cloud-based apps.
🔀 Interoperability — data can be more easily ported between different services.
Adam draws inspiration from tools like Dropbox and Git, which offer elements of local-first philosophy. He believes this approach is increasingly relevant in an era where data ownership and AI capabilities are becoming more critical.
Here is the full interview with Adam:
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
The Goal is one of my favorites. The starting scene can be played today.
"We increased the performance with automation, so you increased your revenue? No... hm."
https://www.youtube.com/watch?v=t_oM9LvK0rU