*Hey, Luca here! Welcome to a new edition of the *
Today’s newsletter is brought to you by our friends at DX!
Last month, together with Justin Reock, Deputy CTO at DX, we published a thorough commentary on the Q2 Report on the state of AI impact in engineering.
In case you missed it, it includes a lot of interesting insights. For example:
PR throughout– increased 37% year-over-year, butPR size– nearly doubled in the same window
So more code is moving through the pipeline, but does that translate into more delivered value? It seems… not! You can find the full report below 👇
Final reminder thattoday at 17:00 CETwe are having ourmonthly live community mastermind. You can find more info, including how to join,[here].
Since I released Tolaria and Portent, a lot of people have asked me about team knowledge bases and how to organize them.
Most questions I receive are about how to organize content: folders, types, and so on, while very few are about the *lifecycle *of such content. When is new content created? By whom? When is it updated or moved? When is it finally archived?
A knowledge base without a proper lifecycle slowly becomes a junk drawer.
Everything is saved with good intentions, but if every item stays equally visible forever, the useful material eventually disappears inside the pile.
In Portent, and for myself, I use a simple three-step lifecycle: capture, organize, archive.
Save the link, write down the rough thoughts, or simply store the meeting notes.
This stage should just be fast, even at the expense of being a little messy, because the goal is to make information available before it disappears.
Now ask yourself two questions:
*What is this?*What should it help me do?
The first gives the note a type, or simply a destination. The second connects it to projects, responsibilities, topics, or useful pieces of context.
If a note cannot be attached to anything meaningful, it may not be worth keeping. So capture optimistically, organize pessimistically.
Completed projects, stale notes, and obsolete context can still be useful. They just should not compete with their current work every day. Archiving is how you keep them available without leaving them in your way.
So, the system works because each stage has one job: capture ensures speed, organize creates purpose and meaning, and archive protects attention.
I wrote more about this in the full piece on Portent 👇
Most often, we tell career stories as if every good outcome followed from a careful plan. In reality, many opportunities arrive through chance: a person may notice your work, remember something you shared, and reach out at exactly the right time.
You cannot control luck, but you can increase the surface area where it can find you.
And to increase such surface, the idea is simple: 1) do more of the work you care about, and** 2) tell more people about it**.
Doing the work builds expertise: you make things, solve problems, contribute to projects, and become better at something useful. But good work can only create opportunities if it doesn’t stay invisible.
Sharing the work is what creates the most connections: write about what you learned, contribute to a community, publish a small tool. Help people see what you know and what you care about.
This does not *guarantee *the lucky break, but it’s a way to make luck less passive: more doing × more telling == more luck.
My friend Umberto Nicoletti wrote more about this, and his career experiences behind it, in the full essay below 👇
Finally, here are the best articles I have read this week:
When intelligence is abundant, the advantage shifts to people who still want to think hard.
David calls them “mental marathoners”: people who use AI to stretch their abilities rather than avoid effort. I loved this framing. It also explains why the same tools can make one person sharper and another more passive.
Middle management teaches you to balance pressure and operate organizational process. Will argues that it can also pull you away from some of the skills executives need most: domain expertise and driving execution.
A good warning for anyone assuming that every step up the management ladder prepares you for the next one. It’s not always the case.
Senko makes a strong case against the “code was never the hard part” phrase that you see everywhere these days. I half-agree with him.
I mean, understanding users, deciding what to build, and translating that into requirements is hard. But writing good code is hard, too. The difficulty level depends a lot on the company you work for: there are companies in which coding is extremely hard, and others where it’s easier. But I don’t think this is a useful debate anyway, let’s just agree coding is hard in general.
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
