Questions to rate your team, business impact on unhealthy code, and weekly readings 💡
Monday Ideas — Edition #208
Hey, Luca here! Welcome to a new edition of the 💡 Monday Ideas 💡 — ideas and readings to start the week on the right foot.
Every week I also write an article about how to ship good software fast, and interview a world-class tech leader on the podcast.
I also build and maintain Tolaria in the open, publishing my workflows and learnings here.
📋 Unblocked is the context layer for modern teams
This newsletter is brought to you by Unblocked!
Agents can generate code, but getting it right for your system, team conventions, and past decisions is the hard part. MCPs give agents access to information but not understanding – so you end up wasting time and tokens in correction loops.
For this reason, the teams pulling ahead use a context layer to give agents exactly what they need.
Unblocked is the context layer that turns code, docs, tickets, and conversations into actionable context, so engineers move faster and agents stay on track 👇
🔍 Rate your team on the pyramid of engineering
A couple of months ago I argued there is a new pyramid in software engineering, made up of the areas you should take care of to get your team to their best potential.
These areas are Developer Experience, AI, and Product Engineering, and need to be nurtured exactly in this order.
To understand how you are doing about each of these, here is a short self-assessment you can run on yourself. Rate how much you agree, from 1 to 5:
1) Developer Experience
1.1 — It is easy to do work as a developer on my team
1.2 — Engineers on my team get enough focus time
1.3 — My team ships fast and often
1.4 — I have a good strategy to improve the developer experience of my team
2) Artificial Intelligence
2.1 — Engineers on my team make good use of AI
2.2 — We have a shared understanding of how to use AI as a team
2.3 — I have a good strategy to improve the impact of AI on my team
3) Product Engineering
3.1 — I am happy with the level of autonomy the engineers on my team work with
3.2 — Engineers on my team know what our customers’ problems are
3.3 — Engineers on my team know if a feature is successful or not
3.4 — I have a good strategy to make the engineers on my team more autonomous over time
You can find the full article below:
🎙️ The business impact of code quality
One of the interviews I keep coming back to is the one I did last year with Adam Tornhill.
Adam is the founder of CodeScene and one of the sharpest thinkers on software quality: he combines behavioral data analysis with code metrics to identify the parts of a codebase that actually hurt you.
The conversation centered on a question most engineering leaders struggle with: how do you make the business case for refactoring?
Adam’s team tackled it head-on with the Code Red study — a large-scale analysis of the correlation between code health and real development performance.
Their findings confirmed what many engineers know by heart:
⚡ Development Speed — healthy code enables teams to develop features more than 2x as fast as unhealthy code.
📉 Predictability — unhealthy code creates massive variance in task completion times, making estimation extremely hard.
💸 Hidden Costs — some tasks in unhealthy code can take up to 10 times longer than expected.
“Doing a task in unhealthy code can actually take up to an order of magnitude longer — 9 times, 10 times longer. And that translates into a bunch of undesirable side effects for the business.”
One finding that stuck with me is also that who makes the change matters enormously. Developers unfamiliar with the codebase take twice as long to work in unhealthy code. This is a hidden onboarding cost that nobody ever budgets for, but that compounds every time a team grows or rotates.
Here is the full interview with Adam 👇
You can also find it on Spotify and Substack
📚 Weekly Readings
Finally, here are the best articles I have read this week:
🥇 Software Engineering May No Longer Be a Lifetime Career
6 min • by Sean Goedecke
Using AI to code means you don’t learn as much about coding itself, but refusing to use it puts you at a disadvantage today. So, is software engineering becoming more like professional sports? That is, a career with a finite window rather than a lifetime of compounding skill accumulation.
🥈 GitLab Act 2
19 min • by Bill Staples
GitLab’s CEO lays out their vision and plan for a major restructuring of the company around agentic AI and the future of software delivery. Interesting both as a product vision and as a case study in leading a public company through a platform shift.
🥉 Thin Harness, Fat Skills
6 min • by Garry Tan
By now we know that AI agents become far more productive by using purpose-built skills. It’s still unclear how all of this scales, but Garry’s mental model about growing skills instead of the general harness is solid, and I agree with him.
And that’s it for today! If you are finding this newsletter valuable, subscribe to the full version!
1700+ engineers and managers have joined already, and they receive our flagship weekly long-form articles about how to ship faster and work better together! Learn more about the benefits of the paid plan here.
See you next week!
Luca
A lot of teams already know their DX is bad, AI usage is random, and product context is thin. The hard part is that none of those problems naturally wins against roadmap pressure. So the assessment is only useful if it forces an explicit tradeoff: what are we willing to not ship this quarter so the team stops bleeding time next quarter?