Retrospectives, feedback, and anticipating tech debt 💡

Monday Ideas — Edition #112

💠 Sidebar • accelerate your career through peers

I have written many times in the past about the importance of having a trusted group of peers you can talk with regularly.

I have one now — four to five friends who I see as my personal Board of Directors — but I haven’t had it for a long time, and I can see the difference this made for my growth, and even just for my wellbeing.

For this reason, I am happy today to promote Sidebar, a product that intentionally helps with this.

Sidebar is a program that grows your career through the power of peers. It creates your top-tier peer group of 6-10 leaders, with whom you meet bi-weekly. Sessions focus on measurable outcomes, thanks to goal tracking, accountability, and messaging.

You can learn more about Sidebar below 👇

Back to this week’s ideas!

---

1) 🚥 Continue / Stop / Start

There are several frameworks for running good retrospectives and feedback sessions — but, over the years, I always find myself coming back to the Continue / Stop / Start.

This technique organizes action items into three categories:

1. 🔵 Continue — things that are working well and we want to continue doing. These should be addressed explicitly to 1) develop gratitude, and 2) make sure the team doesn’t regress on the good things.

2. 🔴 Stop — things we want to stop doing. Sometimes, problems are easier to be solved by subtraction than by addition, but we tend to be biased towards the latter. The stop stage counters this bias. Also, removing things creates the space to add new good things in the start stage 👇

3. 🟢 Start — things we want to start doing. It comes at the end because it is the hardest. Many times it is perfectly fine to just acknowledge what is working well and prune a few things that are not. A healthy way of adding things is to focus on one at a time, asking “what is the most impactful thing we can start doing that aligns with our expectations?”

Here is how Titouan Benoit, CTO, combines the various techniques to create a full workshop 👇

We do retro during offsite (each quarter) with the whole team so far. Here is the agenda:

• 5 min setup: prepare board, take drinks, ...

• 5 min check-in: round table, explain exercise, purpose, goals, ...

• 2x40 min retrospective exercises

• 20 min compile outcome: 3-4 points per topics [start, stop, continue]

First exercise is Liked, Learned, Lacked, Longed for. It will generate ideas everyone will put on the board and we will gather and reuse them to the second exercise Start, Stop, Continue.

Titouan also shared his own template for the workshop.

Also, here is the full article I wrote about running good retros 👇

Retrospectives 🔄

---

2) 💛 The Feedback Quadrant

Kim Scott has seen it all.

She led teams at Google, coached Twitter and Dropbox CEOs, managed a pediatric clinic in Kosovo, and started a diamond-cutting factory in Moscow.

She spent a lifetime managing the most diverse people and leading them to success. Later, she wrote about her learnings in the world’s most popular book about feedback: Radical Candor.

Kim breaks feedback into four quadrants. On the horizontal axis you have unclear to clear feedback, and on the vertical you have negative to positive one.

Now, whether positive or negative, the best feedback is always clear and specific. Otherwise, it sets up our reports for failure.

Softening negative feedback is human — we want to avoid adding even more pressure on our teammates. Such cruel empathy, though, doesn’t give them the tools to do things differently. It dampens their growth.

Unclear positive feedback is equally ineffective. Simply saying “you are doing a great job” doesn’t cut it, because it doesn’t bring any learning. In the worst cases, it feels artificial and a way to balance the bad one out.

I wrote a full article about giving feedback, which is one of the most popular Refactoring pieces ever 👇

How to Give Feedback 💛

---

3) ↩️ Anticipate tech debt rather than prevent it

I have found that one of the best ways to handle technical debt is by anticipating it, which is not necessarily the same as preventing it.

During the design phase, you can often anticipate that something will not scale over some limit, or that an abstraction will not fit if X happens in the future.

These limits are important to be discussed to make sure you are designing for the right scenario.

A limited design is good as long as you won’t touch those limits for a long time.

You can encourage this reasoning by addressing these parts in your design stage. You may include, for example:

1. ❌ Anti goals — goals and features you are intentionally not designing for.

2. 💣 Land mines — stuff that might be problematic for current design if it happens. E.g. traffic load, or future features.

3. 💸 Operational costs — how much it costs to maintain the feature, if there is any maintenance cost that you can anticipate.

In my experience, when all the cards are on the table, it is rare that you make truly terrible calls. Most mistakes are made because of unknown unknowns. Stuff that not only you didn't design for — you didn't even know it could happen.

I wrote many articles about tech debt over the years, the most thorough of which is this full guide from a few months ago 👇

The Definitive Guide to Technical Debt 🦠

---

And that’s it for today! If you are finding this newsletter valuable, consider doing any of these:

1) 🔒 Subscribe to the paid version — if you aren’t already, consider becoming a paid subscriber. 1500+ 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