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
🎒 Hiring & Onboarding

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

How to Build Anything with No Code

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

Subscribe now

p.s. are you a student or live in a country with a low purchasing power? Ask for a discount!

In the last few weeks I got in touch with Mahesh and the team behind Faros AI, which I am happy to promote in the newsletter!

Faros AI is an engineering operations platform that connects the dots between your engineering data sources – ticketing, source control, CI/CD, and more – giving visibility and insight into your processes.

With Faros AI, engineering leaders can analyze key operational metrics such as DORA, productivity, onboarding, and more, to eliminate guesswork and elevate business outcomes with data-driven decisions.

Learn more about Faros AI✨

Back to this week’s ideas!

1) 🎽 Don’t hide your inexperience with your reports

As a young founder, I have often had reports who were more experienced than me.

At the beginning I was uneasy with that, and I fell into the trap of thinking that I had to demonstrate my abilities all the time. I had to prove that I was as good as them at what they did — while I was clearly not (that’s why I had hired them!).

This attitude is not only ineffective, it is harmful for the relationship with your reports. They will sense that you are faking it, or trying too hard, and this will erode their trust.

Instead, build a honest relationship where you don't hide your inexperience with them.

You can tell them:

I am going to manage you, but I am excited to learn from you. What have you found that works?
I have the context of why the company works the way it does. I have the vision and you have the expertise to execute on it.

2) 🔨 Feature flags and code reviews

I am a big proponent of trunk-based development, which is a version control workflow where developers work in small batches and merge their work into the main trunk as often as possible — usually at least once a day.

For projects that cannot be completed within a day, code gets merged often anyway in a disabled state, behind feature flags.

Recently, a reader asked me how code reviews work in this context:

How can you review a small piece of a larger feature without having the full context of what’s going on?

That’s a good question!

A large feature can most often be split into parts that make sense in isolation (e.g. data model, UI, state mgmt, API, …) so you can review them properly. In case this is not possible, you can still pair with the author and go through the code together — this is the best kind of review if you ask me.

This is still not ideal, but what’s the alternative? In my experience, the larger the feature, the more shallow the review. People just can’t reliably review thousands of LOCs all at once. They don’t have the time and the energy.

Also, single big releases lead to a higher risk of conflicts and failures, than multiple small releases gated behind flags.

More on feature flags and workflows 👇

Refactoring

Feature Flags 🚩

Much of modern software engineering is about shipping fast and often. Studies like Accelerate and the State of DevOps demonstrate that teams that ship the most often are also the most likely to meet or exceed business goals. Highest performers are twice as likely to meet or exceed their organizational performance goals …

2 months ago · 13 likes · 2 comments · Luca Rossi

3) 🎒 The work with agencies is based on trust

Relationships with software agencies and partners are always based on trust.

Building trust reduces overhead and makes you go faster. This is natural and healthy because work relationships are first and foremost relationships.

You can't replace trust with more contract clauses.

When you find yourself putting more boundaries into a contract, ask yourself: am I doing this because of a real need, or because of lack of trust? If it is the latter, focus on building trust first, so you can reduce complexity later.

More on working with agencies 👇

Refactoring

How to Work with an Agency 💼

If you have been reading Refactoring for a while, you know I have mostly written about internal engineering teams. I also often had the chance to combine the work of such teams with that of vendors and agencies. These collaborations represent an opportunity to…

9 months ago · 6 likes · Luca Rossi

And that’s it for today — I wish you a great week! 🚀 If you liked the article, consider doing any of these:

1) ❤️ 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

2) ✉️ Subscribe to the newsletter — if you aren’t already, consider becoming a paid subscriber. That also gives you access to the community and the curated library.

Subscribe now

p.s. 30-days money-back guarantee, no questions asked!

Refactoring

Monday 3-2-1 – reports more experienced than…