Normal people, infra decisions, and input vs output metrics 💡
Monday Ideas — Edition #173
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 👇
Quick heads up! This Wednesday I am running a webinar with Adam Tornhill about code quality, AI, and technical debt. Check it out if you want!
1) 🤼 Build team systems with normal people in mind
Earlier this year Charity Majors wrote this incredible guest post on Refactoring where she discussed the 10x engineer meme, and what great engineering orgs look like instead.
There is one idea from the article that particularly stuck with me: when it comes to hiring talent, we should absolutely focus on identifying the ways people are exceptional; but when it comes to building sociotechnical systems for software delivery, we should focus on all the ways people are normal.
Normal people have cognitive biases — confirmation bias, recency bias, hindsight bias. We work hard, we care, and we do our best; but we also forget things, get impatient, and zone out. We develop habits and ways of doing things, and resist changing them.
We are embodied beings who can get overwhelmed and fatigued. If an alert wakes us up at 3 am, we are much more likely to make mistakes while responding to that alert than if we tried to do the same thing at 3pm. Our emotional state can affect the quality of our work. Our relationships impact our ability to get shit done.
So, when your systems are designed to be used by normal engineers, all that excess brilliance they have can get poured into the product itself, instead of wasting it on navigating the system itself.
You can find the full article below 👇
2) 🚚 Infra decisions are business decisions
There is a lot of talk today about cloud repatriation and bringing some infra parts back in-house.
On-prem tooling today is leaps and bounds better than how it was e.g. 10 years ago, but this is still a complex proposition that should be evaluated from multiple angles.
Infrastructure decisions are first and foremost business decisions: they must align with your company's financial and strategic goals. So, if you are looking into this, here is my personal cheat sheet:
Total Cost of Ownership (TCO) 💰
Consider TCO, which goes beyond monthly bills:
Cloud costs — OpEx model with compute, storage, managed services, and (often surprising) data egress fees.
Self-hosted costs — CapEx for hardware plus OpEx for power, space, and critically, specialized engineering staff.
FinOps — cloud providers offer better cost visibility and allocation tools out of the box.
Velocity & Time-to-Market ⚡
Cloud — enables faster starts and experimentation, crucial for startups and high-growth environments.
Self-hosted — can achieve high velocity once the platform is built, but requires significant upfront investment for any nontrivial setup.
Strategic Considerations 🧭
Buy vs build — if infrastructure provides true competitive advantage, build; otherwise focus resources elsewhere.
Risk management — cloud offers high availability and security that's expensive to replicate; self-hosting gives control but full responsibility.
Margins — low-margin, high-volume businesses benefit more from self-hosting. Conversely, many SaaS companies find infra costs negligible (few % points of MRR).
Lock-in — real risk comes from proprietary services and egress costs, not provider disappearance, which is extremely unlikely.
We wrote a full, thorough guide about the cloud vs on-premise debate earlier this year:
3) 🔍 Output vs input metrics
Before summer I had a great chat with Abi Noda, CEO of DX, on the Refactoring podcast.
The idea that I loved the most from the interview was the distinction that Abi makes between output metrics (diagnostic) and input metrics (controllable):
➡️ Output metrics — (like DORA metrics) show results but can't be directly controlled.
⬅️ Input metrics — are what teams can actually influence day-to-day.
Abi uses a health analogy to explain this concept:
"Common diagnostic metrics for health are things like blood glucose, cholesterol levels, weight, blood pressure. They are diagnostic metrics. If you want to improve your blood glucose, you can't just suck glucose out of your blood - you have to control your inputs like protein intake or sugar consumption."
Understanding this is crucial because many orgs mistakenly try to optimize output metrics directly, which leads to number distortion rather than actual improvement. The focus should be on identifying and improving the inputs that drive better outputs.
Abi explains that DX (his company) focuses on developer experience as a controllable input that drives productivity, believing that removing friction in both technical and social aspects of development (upstream) ultimately leads to better performance metrics (downstream).
Here is the full interview with Abi:
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