The kernel of strategy, evergreen notes, and when to hire engineers 💡

Monday Ideas — Edition #70

Hey, Luca here! Welcome to the Monday Ideas 💡

Every Monday I will send you an email like this with 3 short ideas about making great software, working with humans, and personal growth.

You will also receive a long-form, original article on Thursday, like the last one:

• How to Run Great 1:1s in 2023 🧑‍🤝‍🧑

To receive all the full articles and support Refactoring, consider subscribing if you haven’t already!

p.s. you can learn more about the benefits of the paid plan here.

---

🐺 QA Wolf (Sponsor)

Manually end-to-end testing? Here's why you should switch to automation:

1. Test all user flows in 3 minutes

2. Freedom to run your suite whenever you want

3. Increased confidence in releases and time to focus on other priorities

The list goes on…

So why wouldn't you? Time and resources. In-house teams typically take 2 years to reach high coverage. And you need at least a few automation engineers to build, run, and maintain a test suite. Not anymore.

QA Wolf offers a cost-effective approach to get 80% coverage in just 4 months. And, they include unlimited parallel runs on their testing infrastructure + 24-hour maintenance and triage.

---

1) 🔮 The Kernel of Good Strategy

Last month we read Good Strategy / Bad Strategy within our community book club. The book’s most important chapter is about finding the kernel of your strategy.

For the author, any good strategy is made of three pieces:

1. 🩺 Diagnosis

2. 🗺️ Guiding Policy

3. 🚀 Actions

Let’s see all three:

Diagnosis 🩺

Any strategy starts with a clear definition of the challenge that the company faces. In many cases, figuring out this is the hardest part of all.

Different people often have different views on what the problem is, and it may be hard to reconciliate those views to converge on a single diagnosis. Still, it is your duty as a leader to narrow down the scope and focus on what’s most important.

To make this more practical, I will make an example drawn from my startup experience. This is not to brag — for the sake of this piece I am cherry-picking something we did right, out of the many things we did wrong.

My startup, Wanderio, let people compare and book all modes of transport — flights, trains, buses, ferries — to get to a destination. People loved the product, but we always struggled to bring in good traffic and find effective acquisition channels. For many reasons:

1. Incumbents in the travel space (e.g. Expedia, Booking, Skyscanner) all have great brand awareness. Most people, when it comes to planning a trip, go straight to the services they know best.

2. Paid acquisition channels are mostly out of reach because of 1) the enormous spending by big players, and 2) low customers’ LTV because of equally low margins in the travel space.

3. SEO on major destinations is likewise dominated by incumbents.

4. Good retention and word of mouth are tough because people travel on average 2-3 times a year. Even if they had a good experience with us, many people would simply forget about Wanderio when it was time for their next trip, several months later.

So this was our unenviable diagnosis. Now, once you converge on a diagnosis, you should outline a guiding policy 👇

Guiding Policy 🗺️

A guiding policy is a clearly articulated approach to deal with the challenge identified by the diagnosis. It should draw upon the organization’s sources of power and focus your efforts toward objectives that meet the challenge.

In our case we figured out that, by covering secondary modes of transport like buses and trains, we were good at serving minor destinations that are not served by flights. In Italy, >50% of people live in areas that are not close to airports, so this looked like an opportunity. Also, most travel incumbents are flight-only, so they can’t really do SEO / ads on small destinations.

So, we would never be competitive on top-of-the-line searches like “how to go from Rome to Paris”, but we could be extremely good on thousands of minor, long tail searches, which were totally out of reach for our competitors.

So, it was time for action 👇

Actions 🚀

After you define your guiding policy, you should plan a set of actions that accomplish it.

In our case, we built an engine to generate thousands, and eventually millions of SEO pages about how to go from A to B, for every pair of cities above a certain size in Italy, our domestic market.

The strategy worked, and we eventually grew our organic traffic to ~2M sessions / month.

You can find the full summary and review of the book in this recent article 👇

Good Strategy / Bad Strategy 📗

---

2) 🌱 500 Evergreen notes

Three years ago I read How to Take Smart Notes, and it changed forever the way I think about knowledge. In particular, I loved the idea of creating a growing body of atomic, evergreen notes about my knowledge, from which to draw for just about anything.

So whenever I write a new article, I take its most important points and store them as individual notes on Notion:

I implemented my own — very lightweight — version of the Zettelkasten method, explained in the book.

Example of an Evergreen Note

As of today, I have amassed 500+ notes that I use in two main ways:

• 💡 Monday Ideas — for writing the free Monday emails — like this one! — I just take three ideas from my notes.

• 🐦 Social media — all my social media posts come from individual notes.

It seems like a nerdy thing, but it’s probably been the best investment I ever made for Refactoring.

I covered my whole process for writing and growing Refactoring in this recent piece 👇 it is one of my post popular ever!

How I Write and Grow Refactoring in 2023 ✏️

---

3) 💼 Signs you should hire more engineers

One of the things I struggled the most, as a CTO, was figuring out when it was the right time to hire more engineers.

What are the signs you need more of them? And when is it that you should hang on, instead? In my experience, you hire developers to improve some of these dimensions: quality, throughput, and health.

Let’s see all three 👇

Quality 🔍

You should hire for quality when you have a large skill gap on something, and that clearly hinders growth.

Whatever such skill is, before you hire you should know your way around it just enough to being able to:

• Build an initial iteration — it is rare that you can only bring value with top-quality execution.

• Learn what good looks like — to being able to evaluate the work done by future hires.

Throughput 📈

You hire for throughput when your growth is slowed down by pure bandwidth.

In my experience this is trickier to judge than quality, because your team may be slowed down by factors that do not get better with size.

Technical debt, bad prioritization, confusing organizational structure, are all systemic diseases that you will not solve by throwing more resources at them — you will arguably make them worse.

Counterintuitively, the best time to hire is when your team is in great shape and firing from all cylinders. That also helps with morale and retention. If that’s not the case right now, focus on fixing what doesn’t work first.

Health & growth ❤️

As your team gets larger, there are other, second-order factors you may consider in your hiring decisions:

1) Pairs and key dependencies — it is inevitable for a good while to have singletons, that is, people who are the only ones working on something — either a function (e.g. mobile dev) or a product area. Singletons are bad in the long run for two reasons:

• They are single points of failure — you are in trouble if they leave, and you are vulnerable to promotion/raise blackmail.

• Their growth gets limited — both technical skills and motivation benefit from working in pairs. Code quality does, too.

2) Mentorship & seniority levels — mixing seniority levels by hiring, for example, more interns and junior developers, creates healthy team dynamics and provides growth opportunities for more senior folks 👇

Mixing Seniority in Engineering Teams 👩‍👦

More hiring tips in this past article 👇

When Should You Hire? 🤔

---

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. You can 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