Systems thinking, book summaries, and decision making 💡
Monday Ideas — Edition #117
💬 Unblocked – get the right answer, now
Most AI dev tools today focus on code generation.
In my experience, however, the most time-consuming part of development is not writing code, but getting the right context.
In part that’s because decisions are scattered across multiple tools (GitHub, Slack, Jira, Notion, etc), and the right person isn't always available, which leads to a lot of waiting and wasted time.
For this reason, I am happy this week to promote Unblocked, which connects to all your tools, surfaces this knowledge and gives engineers the answers they need to get their jobs done:
Back to this week’s ideas! 👇
1) 🧩 Approach problems with systems thinking
Last month I read An Elegant Puzzle, by Will Larson, in the book club.
It is the best book I have ever read about engineering management, and the reason comes down to one thing: systems thinking.
Systems thinking is a wildly overused term, but Will gives a very precise definition for it. Systems are combinations of stocks and flows:
🧱 Stocks — are accumulations of resources.
🔀 Flows — are streams that make stocks increase (inflows) or decrease (outflows).
This definition looks extremely simple and, in fact, through the use of diagrams, it turns systems into equally simple boxes and arrows.
Simple, though, doesn’t mean vague — on the contrary, stocks and flows are precise ideas that, applied well, can model infinitely sophisticated situations.
One of the examples provided is about DORA metrics. The four metrics are flows that impact their respective stocks, and together model the software delivery process as a clear, predictable system (see picture).
Now, thinking at your dev process as a system is still intuitive, or at least it should be, to managers and engineers who have been in the industry for more than a few years.
The main virtue of An Elegant Puzzle, though, is that it applies this line of thinking to everything.
It addresses otherwise nebulous themes like team organization, culture, hiring, or hypergrowth, by uncovering their inner logic and creating mini frameworks that always feel grounded and actionable.
This is extraordinarily useful. In Will’s own words 👇
Once you start thinking about systems, you’ll find it’s hard to stop. Pretty much any difficult problem is worth trying to represent as a system, and even without numbers plugged in I find them powerful thinking aids.
So, “An Elegant Puzzle” may look like an obscure title for an engineering management book, but it all makes sense when you understand Will’s approach to problems. Engineering management’s challenges are explained as a series of puzzles which you have to solve by creating systems for them.
You can find the full review below 👇
2) 📚 Start a book with its summary
For most of my career I have felt overwhelmed by the endless stack of “must-read” business books.
Then, something clicked, and last year I read 12 books (I don’t know you, but for me it’s a lot).
I wrote a full article about my approach and an important part of it is about making good use of summaries.
Instead of diving straight into a 300-page tome, I begin with a high-quality summary. I typically use Shortform for this because it has a nice workflow: I take highlights there, these are sent to Readwise, which in turn are sent to my Notion.
Here's why this looks like a good investment:
⏱️ Time efficiency — a good summary takes ~30 minutes, vs. 4-5 hours for a full book
🧠 Mental model — it creates a framework of the book in my mind, which ensures better retention if I want to read the full thing.
🎯 Assessment — I can quickly gauge if the book aligns with my current needs
So, after the summary, I am at a decision point. Do I read it in full?
For ~60% of the books, I actually stop there. And for many of them, I don’t even finish the summary — for many reasons: maybe they are not that good, or maybe I know a lot of the topic already, or maybe I am not that interested in the topic.
But the best books leave me intrigued, so I move on to the full thing.
Now you may be wondering — aren't summaries enough? For the best books, they are not. Here is why:
🧩 Context — full books offer rich examples and stories, which summaries usually miss. Summaries get the “frameworks” right but struggle with practical use.
🔄 Exposure — spending 4-5 hours with ideas is different from 30 mins. Extended time helps “install” ideas in your brain, run them in the background, and let you find… 👇
🔗 Connections — more exposure + more context == easier to link ideas to your own challenges.
All in all, my goal isn't to read every book cover-to-cover, but to extract the maximum value for my time investment. So I can afford to engage with more ideas, while deeply exploring only those that are the most relevant to me.
You can find the full article below 👇
3) 🎲 Design your decision making
How teams make decisions is an often overlooked part of how they work.
It doesn’t feel like something that should be designed, yet you can easily measure how well you are doing it by asking two questions:
⏱️ Efficiency — how long does it take to take a decision?
🥇 Quality — how often do you need to revisit or reverse decisions?
In my experience, there are three main things that enable good decision making:
Shared principles ⭐
You want people to make choices that are in line with your team’s culture.
Different people tasked with the same decisions should mostly come to the same conclusions, and that is only possible if they share the same set of values.
Good context 🔍
People can only make good decisions when they have full visibility into the elements that go into it.
As a manager, you should lead with context: provide all the necessary data to get to a decision, and empower your teammates to go for it.
Templates and procedures 📋
For specific and recurring situations you may write down procedures about how to perform them.
You may create a template for design docs, a set of criteria for buy vs build, a checklist for code reviews, and so on. Procedures easily turn into mini frameworks that speed up work and improve its quality.
We discussed decision making and other parts of your Engineering OS in this recent article I wrote with the guys at Plato 👇
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. 1500+ engineers and managers have joined already! Learn more about the benefits of the paid plan here.
2) 🍻 Read with your friends — Refactoring lives thanks to word of mouth. Share the article with your with someone who would like it, and get a free membership through the new referral program.
I wish you a great week! ☀️
Luca
Another nice post, thank you