Hey, Luca here! Welcome to the Monday 3-2-1 ✨

Every Monday I will send you an email like this with 3 short ideas about engineering management, technical strategy, and good hiring.

You will also receive the regular long-form one on Thursday, like the last one:

How to Delegate Effectively 🤝

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

Become a better tech leader today ✨

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

1) 🔀 Boundaries in skip-level 1:1s

If you are introducing skip levels for the first time, be prepared for people to be confused about them. Both your reports (managers), and reports of your reports.

In both cases, you want to tell them exactly why you are having those.

Especially to managers, you should clarify that you are not going to overstep your boundaries and take away ownership from them. Skip levels are 90% about feedback, while most of the action stays on the manager’s side.

So, as the one holding skip level 1:1s, how should you act on items that come up in conversation?

It may seem weird, but 80% of the time the best answer to anything you hear is "have you talked about this to your manager?"

What follows is most often useful, and you want to learn more about it before you take any action. A “yes” may imply the manager didn’t act on this (why?), while a “no” may hint at some communication/interpersonal problem.

The trickiest part of skip levels is being helpful—so that meetings feel valuable and the report keeps coming with good ideas/feedback—while not stepping onto the managers’ toes.

It is kind of an art, even more than with regular 1:1s.

More ideas about how to have good skip level 1:1s 👇

Refactoring

Skip Level 1:1s 🔀

2 months ago · 12 likes · Luca Rossi

2) 🪄 Use no-code tools

When I talk with startup founders, some of the most frequent advice I give is about using no-code / low-code tools to build the product faster and reduce its cost of ownership.

Likewise, a common answer I receive is: our product can’t be built with no-code.

A good 80% of the times, this is false.

No-code has come a long way to cement itself as a legitimate solution for building things, but most developers and tech leaders still don’t know how to build a lot of basic stuff with it.

I listed my 30 favorite no-code tools in this past Refactoring article 👇 — they are organized by what you can build with them and you will find plenty of resources to learn more.

Refactoring

How to Build Anything with No-Code 🪄

5 months ago · 7 likes · Luca Rossi

3) ✏️ The three sections of a design doc

A good design doc can be organized into three main sections:

🎯 Essentials — things you should always include, like goals and tech design.
📝 Disclaimers — things you include to create alignment and guide the conversation.
🕰️ Reminders — things that “let’s make sure we don’t forget them”. And boy they are many.

Let’s see them 👇

🎯 Essentials

You would probably remember to write these even without a template. On the flip side, you would probably remember only these.

Header — the basics: project name, date, owner, other contributors.
Context — links to other useful docs: product specs, UI/UX design, related design docs.
Goals — what this design should achieve.
Approach / Design — How you are going to implement the thing. Focus on materials that drive the conversation, rather than specs.

📝 Disclaimers

People will read the essentials and come up with questions and ideas.

This can be 10x more productive if you are able to anticipate such points. The best way to do this is to reason through inversion and cover not only what you want to build, but also what you don’t, and why.

Refactoring

The Power of Inversion 🔃

2 years ago · 20 likes · Luca Rossi

So here is what you may include:

Anti-goals — all the things you are not going to achieve in this iteration. This prevents the classic objections “I thought we would have this” after release.
Alternatives considered — if you are discarding alternative options, list them and explain your thought process.
Open questions — just like for alternatives, be transparent about points that are still open, and put them up front for discussion.

🕰️ Reminders

This is the “let’s make sure we don’t forget about it” space. Not all of sections will be relevant all the time, but it’s important to include them as placeholders. Again, checklist mentality.

Security / Privacy — are there security or privacy concerns about this project?
Observability — details about how you are going to instrument this system, with logging, alerts, and more.
Test plan — how are you going to test this?
Rollout — details about the release process. It might include plans for database migrations, feature flags, and similar activities.
Rollback — what will you do if things go wrong? Can you simply rollback the code?

More ideas on how to create good design docs 👇

Refactoring

Design Docs ✏️

7 months ago · 21 likes · 3 comments · Luca Rossi

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.

Get full access to Refactoring today ✨

2) ❤️ Share it — Refactoring lives thanks to word of mouth. Share the article with your team or with someone to whom it might be useful!

Share

I wish you a great week! ☀️

Luca

Refactoring

Monday 3-2-1 – no-code tools, skip-level…