CARL, tech capital, and microservices 💡
Monday Ideas — Edition #165
1) 🔌 The backend platform for AI
This week I am happy to promote Convex, which I am a big fan of!
Convex is an open-source database and backend platform where everything is expressed in Typescript: the DB schema, cron jobs, server functions, and more.
This makes it perfect for LLMs, which can configure and create everything through code.
Also, Convex is reactive: its libraries guarantee that your app always reflects changes to your frontend / backend code and database state in real time. Never think about state management, cache invalidation, or websockets ever again.
You can learn more below 👇
2) 📞 Use CARL in behavioral interviews
Since hiring managers are evaluating your past actions to predict your future impact, a great response to a “Tell me about a time…” question is one that:
Highlights actions — following the guidelines above, and
Provides the minimum amount of context — to understand those actions and their impact on the organization around you.
This is where popular story telling formats come in. If you’ve read anything about behavioral interviews, you’ve come across the STAR method as a solution — Situation, Task, Action, Result.
This isn’t a bad method, but it has at least two major drawbacks:
It leaves out any form of reflection on your experiences — which is a way for the interviewers to assess your scope—more senior people learn from their mistakes and extract wisdom to be reused on future projects.
Situation and Task are hard to separate — candidates get too caught up in differentiating between them, which are often convolved together in large projects, and they waste prep or story telling time trying to tease apart the two.
So, instead of STAR, I prefer CARL:
📋 Context — combining Situation and Task—the background of the story including what was happening, who was involved, and why it mattered.
⚡ Action — the concrete steps you took—what you did, how you did it, and why you chose that approach.
🏆 Result — the outcome of your actions—what changed, what impact you made on the business.
🪴 Learnings — the takeaways—what you and the organization learned and reflections on the choices you made.
In CARL, Actions are still the center piece but Context can expand or contract to provide the listener with the minimum amount of setup so they can understand the Actions and their motivations.
Learnings are added as a more natural end to the story—think Aesop’s fables. They provide you a platform for expressing your depth of wisdom, showing that you are self-aware and seeking to grow.
We wrote a full article on nailing behavioral interviews which you can find below 👇
3) 🔍 Spot opportunities for tech capital
Last month I wrote an article together with my friend Aviv, where we argue that we need to move conversations from tech debt to tech capital.
If tech debt is a liability, then tech capital is an asset—it’s what makes an engineering org more valuable over time.
Tech capital is about compounding value — the kind of improvements that create an exponential impact, and increase in value as the company grows.
In my experience, the three most common ways companies create tech capital are:
⚡ Engineering velocity – investing in developer experience (DX) to make shipping faster and more reliable.
🦸 Internal superpowers – giving non-tech teams like marketing, sales, or customer support better tools that remove bottlenecks.
🗃️ Data leverage – systems that generate better insights, rather than just storing data, and using unique datasets to increase the value the company has to offer.
But to achieve that, the team needs to start looking around and noticing opportunities.
Without proper priming, these things could be right under their noses, and no one would recognize them. Some example questions you can use as part of an “innovation dump” or a brainstorming activity include:
Where are engineers repeating manual tasks?
What non-engineering teams could be empowered?
What internal bottlenecks exist that slow down business impact?
Does the company have any new unique data, metrics, or expertise that might be leveraged?
Where are humans being used as glue between systems?
These questions open up our minds and help us be better aware of the sawdust that might be accumulating on our workshop floor and going wasted.
However, some of these aren’t trivial for many engineers to answer, because they require gaining some product mastery. In many companies, developers would just shrug if asked what’s holding Marketing or Customer Success back. That’s because their interface with them is limited to Jira tickets.
Instead, cultivate curiosity.
Rather than answering incoming requests on autopilot with “possible/not possible”, or answering with estimates, try to have more understanding of the underlying reasons. That helps unearth more potential areas of improvement.
You can find the full article below 👇
4) 🗿 Good microservices start with good monoliths
I happen to advise a few startups in the Italian ecosystem, and pretty often I see founders diving into complex microservice architectures from the very beginning.
I get it—they want to do things right—but I still think that, in most situations, this is a mistake.
Consider the Gall's Law:
A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.
Paraphrasing it, good microservices designs are invariably found to have evolved from good monolithic designs.
Conversely, if your monolith looks like spaghetti, moving to microservices will not magically fix it. Rather, it will turn it into distributed spaghetti, making problems worse.
I like this Shopify case study, which considers two main coordinates: modularity and deployment units.
Modularity — is the primary virtue you want to achieve. Most qualities brought by good microservices can also be achieved with a modular monolith. Modularity brings easier coordination, better fault isolation, and generally better maintainability.
Deployment units — as a rule of thumb, the more things you need to deploy, the more complex your system becomes. So, other things being equal, you want to keep this number low.
We published a full guide on the evergreen battle between monoliths and microservices, which is one of the most popular Refactoring articles ever 👇
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