Culture types, sim racing, and engineering metrics 💡

Monday Ideas — Edition #140

🔒 Codacy Security — security made simple for devs

Hey! This week I am happy to promote Codacy Security.

I have known the Codacy team for a long time and have even used the product myself, which makes this recommendation a total no-brainer.

Codacy makes your code more secure without slowing you down. Here are some of the tools it provides:

• Static Application Security Testing — catches issues like XSS or SQL injection.

• Supply Chain Security — keeps your dependencies in check.

• Secrets — finds hard-coded secrets in your code, like API keys or certificates.

• Infrastructure-as-Code — scans your config for misconfigurations.

• Dynamic Application Security Testing — helps with runtime vulnerabilities.

And more! You can learn more below 👇

Back to this week’s ideas!

---

1) 🎽 Companies do not conform to a single culture type

We often talk about company culture as a single, monolithic entity. Most companies, however, don't strictly conform to a single culture type.

In fact, as orgs grow beyond 30-40 people, teams naturally develop their own ways of working. For example, you might find that:

• The Platform team has a strong ownership culture — they are conservative with changes, require thorough docs, and have extensive on-call procedures.

• The Growth team moves fast and breaks things — they ship multiple times per day, do quick experiments, and optimize for learning velocity.

• The Mobile team is more waterfall-oriented — they plan releases weeks in advance, have longer QA cycles, and coordinate closely with design.

This raises an obvious question: should you enforce the same practices across all teams?

The three organizational cultures, by Ron Westrum

The answer is no.

This is just not possible at scale, for a variety of reasons: 1) different teams should legitimately work differently, for their own good, and 2) when you hire great people, you want to let them do things their own way, instead of imposing your way.

There is a balance to be found, though, because both alignment and diversity have value. To get the best of both, in my experience, here is what works:

1. 🎯 Focus on outcomes, not implementation — don't mandate specific processes like "all teams must do daily standups". Instead, set clear expectations about outcomes. Teams can then figure out the best way to achieve these outcomes.

2. 🌱 Share success stories — create avenues for good practices to spread. For example, when a team finds something that works particularly well, you may: have them present it at engineering all-hands; document it in the engineering handbook; make it easy for other teams to adopt in various ways. This creates natural convergence around good practices, without forcing them.

3. 🔄 Create feedback loops — set up mechanisms to detect when team cultures diverge too much, like: cross-team retrospectives; engineers rotating between teams to share practices, metrics that help highlight performance differences.

The goal is not complete uniformity — it's making sure the different approaches don't create friction.

Think of your company as a federation of high-performing teams, rather than a monolithic org with identical practices everywhere.

I wrote about modern engineering cultures in this deep dive 👇

Generative culture 🪴

---

2) 📣 Stick with your habits by committing publicly

When it comes to our habits, a good strategy to stick with them is making them easier to do. In many cases, an even better strategy is the dual one: making it hard not to do them.

For this, one of the things that works best for me is public commitment. When I want to do something challenging and I am not sure I will follow through, I just tell everyone.

I am an amateur sim racer and every once in a while I join a competitive league to push myself out of my comfort zone. In Q4 last year I qualified for the Italian GT4 championship, which for me was a big deal: bi-weekly races, streamed live on TV and Youtube, in a field packed with champions.

I knew there was a good chance I would eventually back out, because I needed a lot of prep: hours of training every week, plus the anxiety coming from the race itself, and my general unpreparedness about the whole thing. Also, there was a good chance I would do everything right and still arrive last 🏁

So I told everybody about it.

I told my wife, my parents, even friends who don’t give a s*it about sim racing: I gave them the link to the streaming, and I even posted on X! Eventually, the championship went fine (finished 20th out of 40th!) but most of all, I stuck to it and I was proud of myself in the end 🏆

It’s the start of the year, so if you want more advice about habits, you can find below my review + summary of Atomic Habits by James Clear, which is the best book I ever read about this topic 👇

Atomic Habits 📙

---

3) 📊 How to get started with engineering metrics

Last week we published our industry report on engineering maturity, and how teams use data to improve.

The response was absolutely amazing 🙏 and I received a ton of emails with follow up questions, the most common of which was: how do I just get started with engineering metrics? What is the MVP version of doing this?

Now, tracking metrics is a lot of work. That is true for any metrics, not just engineering ones. In fact, for each single KPI you decide to track, you have to:

• Monitor it on a regular basis — these are the basics, of course. You will look at a dashboard, reflect on the meaning of those numbers, and correlate them with the work that is going on.

• Discuss performance with your team — engineering metrics are best used in conversations with your team. The team has the most context about how work happens and can comment on things that went right or wrong. Failing to do this not only handicaps your understanding, it also creates skepticism within your team. Do not turn metrics in to a “manager’s thing”.

• Create initiatives to improve — conversations are pointless if you don’t carve out space for improving things. When issues are surfaced, you should design initiatives to address them.

This is a continuous cycle: you look at numbers, discuss them with people, figure out how to improve, measure things again, discuss, over and over again.

So, if you are just getting started, here is the minimum viable metrics program I recommend:

1) Start with wellbeing conversations ❤️

Talk to people: engineers, managers, but also PMs and other non-technical stakeholders who are particularly involved. Figure out what are the most frustrating problems to them, in the development process.

You can do it individually, but I also recommend to do it in team-wide retrospectives. You can have a retrospective focused on the developer experience, and separate one that focuses on the business angle. Write down the 2-3 top issues that people agree on.

2) Pick one metric 🤏

Start with one of the issues you found, and figure out how to measure it. You can probably find some KPI related to it. Here is a quick cheatsheet:

• Things moving too slow → Lead time or Cycle time

• Struggling with how to allocate your time → Investment balance

• Slow/unreliable release process → DORA metrics

• Building the wrong things → Feature adoption metrics

Make it an official initiative and create a dedicated retrospective about it, with some generous cadence (e.g. once every two weeks).

At the beginning, focus on improvement rather than setting a target. It is more important to build momentum rather than reaching specific goals.

3) Rotate 🔄

On a longer timeframe (e.g. quarterly) decide whether to continue your investment on that KPI or move your focus to another of the top issues. Keep having conversations to keep issues up to date and surface new ones.

In the long run, at any given time you will find yourself with some specific part of the dev process that requires more of your attention, and a long tail of KPIs you track with a minimum level of investment, to avoid regressions.

And let me know how it goes! You can find the full report from last week below 👇

The Path to Engineering Maturity 🗺️

---

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

1) 🔒 Subscribe to the full version — if you aren’t already, consider becoming a paid subscriber. 1700+ engineers and managers have joined already! Learn more about the benefits of the paid plan here.

2) 📣 Advertise with us — we are always looking for great products that we can recommend to our readers. If you are interested in reaching an audience of tech executives, decision-makers, and engineers, you may want to advertise with us 👇

If you have any comments or feedback, just respond to this email!

I wish you a great week! ☀️

Luca