‘Implementing data-driven approach for building efficient dev teams’ with Luca Rossi, Founder at Refactoring 

Kshitij Mohan: Hello everyone. I’m Mohan your host back with another exciting episode of Beyond the Code by Typo. Today we just can’t hold our excitement because of our guest. He is one of the biggest names today in the engineering leadership ecosystem around the world. He had been a founder, a CTO, and today runs an engineering community of leaders with more than 50,000 plus members.

Here’s to the man himself. Hello, Luca Rossi. How are you? 

Luca Rossi: I’m great. Thank you so much for the kind intro, and thank you. Excited to be here. 

Kshitij Mohan: Thank you so much, Luca. You have earned it all, so thank you so much for giving your time to us. I would say 

Luca Rossi: Thank you. Thank you for having me again. 

Kshitij Mohan: Perfect. So we have heard, seen talk, you write a lot about building data-driven engineering teams, and I think this is what we would love to know more about.

But before we jump into your expertise in wisdom, we have a special section for you. Since you’ve been on the show, we had to do something different. So we have a fireside chat for you. It’s a quick series of questions that me, the viewers would all love to have you answer and know the real Luca. So, are you ready, Luca, to get started?

Luca Rossi: I am, yes. 

Kshitij Mohan: Perfect. 

So let’s get started. Question one, Luca, since you are from Rome, Italy, other than fine wine and football, what else do you love most about Italy? 

Luca Rossi: First of all, I confirm that I love wine and football. Like delicious. I love. So many things about Italy, and you know, when you’re from a country,  there are some things that you do not fully appreciate until maybe you get abroad or somewhere else. You take them for granted and then you see it’s not everywhere the same. So as for me, I really love how in Italy we focus a lot on good relationships with family and friends and well-being. I mean, well-being is pretty much defined by the relationship with those around you, with your loved ones.

It’s a great thing that I’ve not, I think, appreciated enough,  until I was older in age. 

Kshitij Mohan: Oh, that’s true to your heart, Luca. Definitely. Perfect. Question two, which role do you love more and why? Luca being the CTO or Luca today running this community? 

Luca Rossi: Yeah. Wow. That’s a very tough question.

I would say, I love both for different reasons. I mean, because there are definitely things that I miss from my time as a CTO. I mean, I miss the vibes and the energy of working with an actual engineering right product team, working together on some challenge, seeing how maybe junior and younger engineers grow into fantastic professionals or managers.

But I also love the way I can spend my time these days by doing research and writing and,  having great chats with people like you guys, and being able to run and to organize my time the way I prefer.  So it’s a tough call. I mean, right now I’m happy with the lifestyle of the lone writer, and I would not go back, but in the future.

Kshitij Mohan: Definately. Question three. When was the last time Luca, you played a video game, and which one was it? 

Luca Rossi: I’ve been playing a lot of video games for my, for my whole life and lately, the two things that I’ve been playing the most are chess, with some friends on chess.com and,  iRacing, which is sim racing, simulation driving.

I have a simulation set up in my place. 

Kshitij Mohan: Oh, seriously. 

So you have a game parlor, right at your home? 

Luca Rossi: Yes, I have. Yes, I have everything I complete online. I mean, the last few weeks, less than I would’ve liked because of a lot of stuff going on. But yes, that’s a big passion.

Kshitij Mohan: Oh, perfect. You turned out to be a gamer, we never knew. So, yeah. Perfect. Question four Luca. What’s the funniest mistake you think you made as an engineering leader or a manager? 

Luca Rossi: I’ve made so many that were not that funny at the time, but now make for funny stories. So I guess that’s the right way of seeing at them.

I think one very funny mistake speaking about it right now, not at that time, I used to run a travel startup where people could book and compare different modes of transport, like flights, trains, etc. At the beginning we just were Meta search engine so people could not actually buy the tickets. And we wanted to prototype this feature first to figure out if people liked it. And so we said, okay, let’s just put a buy button connected to Stripe and then we will go manually buying the tickets on the websites of the providers.  And it was great product wise,  it took zero time, but then it exploded in complexity.

We had to take shifts so the whole team, night team during the night booking these things manually. Yes. It’s, I mean, it was insane and we could handle it better, but it was also fun. So yeah. 

Kshitij Mohan: Perfect. And one last question for you. Why do you think people love your newsletter? 

Luca Rossi: I think there are many reasons. I think the major reason is that I try to keep it practical and dense. So articles are short because I tried to think in my own problems when I was a young CTO because being a CTO has been my very first job out of university, and I didn’t know how to do like anything. And I struggled, finding good content around how to run an engineering team, how to hire, how to organize a team. And so I tried to speak from experience and, and try to tell what I would’ve liked to read when I was younger.  And so try , to write about real stories, practical tips, not just fluffy theory, which there is a lot about management.
And so maybe people like this a lot. And also drawings. Of course. 

Kshitij Mohan: No. Perfect. I think real problems create real value propositions, so definitely.  Perfect. Luca, thank you. This was real fun. Thanks for being such a sport. Thank you. 

Luca Rossi:  Thank you. Thank you for the questions that were great. 

Kshitij Mohan: Perfect. So now moving to the real stuff, right?

What Luca Rossi writes and talks and has an expertise about. So I think the first thing that always comes is while building and scaling a dev team, how do the leaders, the managers, how do they go about leveraging these data points, these metrics that they have, but they still don’t have, right?

How they can efficiently put these into metrics to build a high-performing team. Would love to know your thoughts on that. 

Luca Rossi: Yeah, of course. It’s a broad topic and we could speak hours about this?  What I’ve seen talking with leaders is that there is so many information out there, there are so many KPIs they could track that people get easily overwhelmed and they don’t know,  how to begin with, you know?

And if they’ve just started, they want to start creating some metrics program or tracking something. What I tell everybody is just start having conversations with your team. It’s like collecting metrics manually, talk with the other engineers or their senior leaders and get their feedback about what they think is working, what they think is not working and then work backwards from there.

Trying to set some very basic one or two KPIs about things that your team think, it’s critical.  So that you can start tracking it for real and figuring out initiatives to get better.  Creating maybe a small process with periodic retrospectives to discuss the trend, how it’s going, but, Always start with conversations because engineers can even be a little bit scared by the idea of getting measured or getting their productivity tracked.

So trying to really make them understand that you’re on the same ship and you’re trying to,  improve things together. It’s very important, so start small and start with conversations I would say. 

Kshitij Mohan: No, definitely, and I think very important point that you touched, right? So,  whenever there is a talk about implementing this data-driven approach in an engineering team, right?

There generally comes a perspective from the developers. Hey, are we being micromanaged or is someone gonna look at me every day? How do you balance that stuff out? 

Luca Rossi: Yeah. That’s a great question. I think that the right approach is approaching this topic from a point of view of curiosity rather than judgment.

Let’s say. So you look at the data, you look at the issues, and try to figure out what’s happening there. Try to build awareness first around the situation, the numbers, rather than jump into I have to optimize this, I have to reach this target, I have to get twice as good or twice as fast at doing this. So using really the numbers, especially at the beginning as conversation starters about how things work in the team rather than judgemental stuff that makes people uneasy. Yeah!

Kshitij Mohan: No, it makes sense. Makes sense. Perfect. And I think just really connected to this aspect of, building the transparency, building the safety, which internal translates to building the right culture, right?

Scaling a team isn’t possible or isn’t sustainable when there is no right dev culture around it. So any specific experiences, thoughts, or processes that takes into building the right dev culture.. 

Luca Rossi: Yeah. That’s another great question and great topic because I think culture is what enables good performance, good productivity, right?

If you do not start, you know, with the right approach or the right principles it’s either useless that you track even track numbers or metrics. You have such organizations. I think there are many elements that enable good to great culture.  I can think of a couple that are really very important to me.

One is cooperation and collaboration in general between the various areas and departments. Because I see many teams wherein the engineering is considered like a piece of a pipeline, so things only move in one direction like you start to product requirements. Then there is design, then you have the implementation, then you release and it’s done. While in the real world, it doesn’t work like that. So,  it pays off to involve engineering in conversation from literally day one. I mean, I say engineering, but the same stands for designers, PMs. People in customer support. So, you’re likely gonna build better features by moving fast and iterating with all the stakeholders involved from day one because they can inform better decisions than just moving, you know in just one day. 

Kshitij Mohan: Just telling them what to do. Its just being a part of the entire decision-making process.

Luca Rossi: Absolutely. So that’s very important thing to get right, in my opinion. And another thing that is instead more about engineering itself is really focus on releasing, being able to release in production fast and often. Because I, I have to say, if we have to name just one thing to optimize that almost cures all the problems is to being able to release often in production very fast, like in a Minutes.  Because I mean, software doesn’t work like other engineering. It’s not like you’re building a bridge or a building.  It’s something where if you do a mistake, you can recover fast.

So in most situations  it pays off better to have a snappy release process. That also means a snappy recovery process if you do some small mistake than just putting more, guide rates, and cautious parts of the process that expand the release time to how was something that really reduced the productivity of everybody.

Kshitij Mohan: Right. No, I think this totally makes sense Luca! And as you touched about moving fast is what all dev teams aim to, aspire to actually, how can we drive things fast?  So, one important aspect then in this entire shipping process is code reviews. There are definitely certain teams who are moving away from this review process trying to implement a different approach to it, but most of us still follow it, right? So how do you think, what could be the right processes around acing these code review? 

Luca Rossi: I think it’s one of the most controversial parts of the engineering process. I agree they’re crucial to the well-being of the team, to the quality of the code. But yeah, it’s also infuriating to me that sometimes we found ourself sweating off the details of our release pipeline to remove 10 minutes out of the deployment process.

And then we just do nothing with the code sitting idle for 18 hours before getting a review,   it’s just nonsensical to me. So I get that we should work asynchronously,  but it’s not like we can wait 24 hours to review some code that has been done in like 30 minutes.  So I think there are various ways of approaching code reviews to try to make them a little bit snappier and more optimized.

One is for sure at the cultural level treated as a P1 activity or P0 activity that is when the review lands and you’re assigned as reviewer. You just have to do it.  You have to do it as the very next item in your in your list. And you can enforce this with notifications.

You can have ChatOps integrations for this, whatever. Then you should try to have small,  code reviews.  Pushing very small batches of code to simplify the job of the reviewer. And, and there’s long tail of more things that you can do. You can adopt more pair programming that actually allows you to avoid code reviews because code is automatically reviewed by your pair.

There are many things you can do, but I think one of the metrics in the KPIs that most teams can start with and it’s beneficial to look into is the  PR cycle time. It is often the case that you can optimize it a lot and it brings benefits across the board.

Kshitij Mohan: Perfect. These are real actionable tips Luca, that I think definitely teams could follow restricting sizes. Taking this up upon priority, limiting your review process.  This really helps. I think moving on to one last thing, Luca, that we have seen you talk a lot about evolve your thought process around this. And I think this is me and we, all of us are excited to know more about, is that you say, Hey, shift focus from 10 X engineers to 10 X teams.  This is a very interesting thought to hear, but we’d love to know more about what exactly that means for everyone in the ecosystem. 

Luca Rossi: Yeah. I think we are engineers, so we build systems and processes with software and I think we do the same with teams. And I’m really a believer that 90% of the performance or underperformance is systemic rather than individual. I mean, is the output of a system in place. And then, of course, individuals have an impact on that. But if you don’t begin with good systems, you’re not gonna get a good outcome just because of talented individuals.

And I think sometimes as an industry, we don’t focus enough on this. We do not realize this as much especially,  recently there is this kind of pushback with all the return to office hardcore culture in many big companies. There is this tendency to reward heroics, you know?

And, but the risk to me is that you know, when you reward hardcore and heroic performance, you risk rewarding, for example. The guy who puts out the fire rather than the guy who prevented the fire from spreading in the first place.  And the reality is that most of the,  greatest engineering work that I can think of in my experience is like boring, transparent work that isn’t easily seen.

Because that’s what good engineering is about, good engineering gets out of the way.  So, I think we should focus more on building great systems and great teams. Because that, at the end of the day, enable great engineers to arise. Yeah. 

Kshitij Mohan: Perfect. Lovely, lovely thought. Luca, thank you so much.

This was really fun. This was really interesting. We highly appreciate you giving us your time. Luca, thank you so much for being on the show. 

Luca Rossi: Thank you again for having me for the great questions and happy to come back any time like. 

Kshitij Mohan: Perfect. We’ll definitely catch you up again. Thank you, Luca.

Good day. Bye-bye.