Bad strategy, AI meetings, and tech debt 💡

Monday Ideas — Edition #78

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:

Personal Knowledge Management • Part 1 🌱

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.

Good Strategy / Bad Strategy 📗

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:

1. ☁️ Fluff — true expertise is replaced by grandiose phrasing/vocabulary.

2. 👓 Not facing the problem — the specific challenges that the company faces are not defined or addressed.

3. 🔀 Mistaking goals for strategy — goals are set without including methods to achieve them. E.g. “our strategy is to grow 10% MoM”.

4. 🫖 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:

How to Use AI in an Engineering Team 🤖

---

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 👇

How to Manage Technical Debt 🦠

---

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