

Discover more from Refactoring
Hey, Luca here! Welcome to the Monday Ideas π‘
Every Monday I send you an email like this withΒ 3 short ideasΒ about making great software, working with humans, and personal growth.
Paid members also receive a long-form, original essay on Thursday, like the last one:
To receive all the full articles and support Refactoring, consider joining 1400+ engineers and get the paid membership!
p.s. learn more about theΒ benefits of the paid plan here.
π New Relic AI Monitoring (Sponsor)
New Relic AIM provides unprecedented visibility and insights to engineers and developers who are modernizing their tech stacks.

With AIM, engineering teams can monitor, alert, debug, and root-cause AI-powered applications.
New Relic is a sponsor of Refactoring π learn more here about how we run sponsorships transparently.
1) π ββοΈ What bad strategy looks like
A couple of months ago we reviewed Good Strategy / Bad Strategy, the famous book by Richard Rumelt, in the Refactoring Book Club.
One of the aspects of the book that stuck the most with me was how it educates your taste about good strategy by making you understand what bad strategy looks like.
Bad strategy has four characteristics:
βοΈ FluffΒ β true expertise is replaced by grandiose phrasing/vocabulary.
π Not facing the problemΒ β the specific challenges that the company faces are not defined or addressed.
π Mistaking goals for strategyΒ β goals are set without including methods to achieve them. E.g. βour strategy is to grow 10% MoMβ.
π«Β Boiling the oceanΒ β focus on too many objectives.
Why does this happen? Reasons are manyβas Rumelt explainsβbut personally I like to focus on one, which isΒ commitment.
I am an amateur chess player and in chess there is this notion ofΒ committalΒ andΒ non-commitalΒ moves.
Non-committal movesΒ β are about improving your position while retaining optionality on what to do next, like what attacking strategy you may want to pursue.
Committal movesΒ β are when you set a direction you cannot (easily) withdraw from.
Non-committal movesΒ keepΒ you in the game, but committal moves are how youΒ win.
You can draw parallels to this with almost any domain. Retaining optionality is important as long as you areΒ not sureΒ about what your strengths are, or how to leverage them. But then, success comes down to finding a way to narrow your options and make someΒ irreversibleΒ bet on what makes you special.
And thatβs where many companies get lost.
Leaders donβt want to choose among the various interests within their operations, each backed by stakeholders with legitimate theses, and end up with anΒ unfocusedΒ strategy.
To compensate for this, you may witness two different types ofΒ drifts, based on your company culture:
π₯ Positive thinkingΒ β focus on hustling, heroics culture, and the idea that you can win throughΒ intensity.
π BureaucracyΒ β focus on rules, template-style plans (e.g. vision β mission β values β strategy), and the idea that you can win throughΒ process.
But both styles are not a substitute for good strategy. You canβtΒ brute-forceΒ your way to success in the first case, just like you canβt expect your unique strategy to come out ofΒ fill-in-the-blanksΒ templates in the second.
2) π€ Using AI for meetings
These days I am trying to create a Custom GPT for Refactoring that leverages the 170+ articles I have written, to coach you with any challenge you may have. Results are still hit or miss, but I will keep working on it πͺ
There are many situations where AI frustrates me, but there are also legitimately good use cases for which I am using it all the time.
One of the best ones is to improve meetings. Today, AI tools allow you to:
Summarize stuff that has been discussed in a meeting
Extract action items
Create video chapters on the recording so you can go back to specific moments
If for regular videos this is a nice to have, for meetings it is a total game changer:
It aligns people about what to do next.
It creates decision records for future reference.
It creates a place where you can have good async conversations about the meeting subject.
All of this in turn allows for fewer people to join meetings, because they have a good way to catch up afterwards.
My favorite tools for this are TL;DV and Otter. Key features are similar β crucially, for some people, Otter also supports Microsoft Teams, while TL;DV only Meet and Zoom β and both have generous free tiers you can try.
They are both very good β I have a slight preference for TL;DV, which also can export meeting notes to Notion automatically. π
I wrote about more AI use cases in this previous article:
3) βοΈ Tech debt vs product maturity
In startups and fast growing products you may hear about taking on debt intentionally, as the result of prioritizing speed and growth over engineering quality.
Regardless of whether this would make for a good strategy, debt is most oftenΒ inevitableΒ rather than intentional. Fast growth, in fact,Β naturallyΒ leads to debt, because when the product changes at a fast rate, your engineering abstractions get invalidated equally fast.
Such volatility, though, changes with the maturity of your product. For the sake of simplicity, letβs consider three stages:
π£Β 0 to 1Β β you start building a product from scratch, with a set of initial assumptions.
πΒ Product Market FitΒ β you figure out what works, double down on it, and scrap the rest.
πΒ ScaleΒ β you grow your business predictably and harden your tech.
The earlier you are on this scale, the more your product needs to move fast, and the moreΒ leverageΒ you get by accruing debt.
The later you are on the scale, the more debt becomes a drag thatΒ preventsΒ your product from growing. Your scale is such that you get the most leverage byΒ repayingΒ debt.

For early stage startups it might be inevitable and even healthy to accumulate debt early on. At the same time, though, you should create processes to help repay debt from the very beginning.
I wrote a full guide about managing technical debt, which is one of the most popular articles ever on Refactoring π
And thatβs it for today! If you are finding this newsletter valuable, consider doing any of these:
1) βοΈ Subscribe to the newsletterΒ β if you arenβt already, consider becoming a paid subscriber. 1400+ 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
Bad strategy, AI meetings, and tech debt π‘
Hey Luca, can you talk about how to go about setting team strategy for 2024?