Mar 04 5 min read

Customer Interview: Santiago García, CTO and Co-Founder at La Haus

Customer Interview: Santiago García, CTO and Co-Founder at La Haus

Hillary
Nussbaum

In our new series, Code Climate is speaking with customers who use Velocity, our Engineering Intelligence platform. 

In this customer interview, we talked to Santiago García, CTO and Co-Founder at La Haus. Santiago shared how using Velocity metrics helped him gain visibility into La Haus’s engineering processes and drive improvements.

 

Hillary Nussbaum, Code Climate: Tell me a bit about La Haus and your role there. 

Santiago García, Co-founder & CTO, La Haus: We are transforming the real estate market in Latin America. It’s a very informal market, it’s a very broken market. So what we are trying to do is to build something that takes everything and puts it together, to transform the industry with technology, data, and good service. As CTO, I was also the first programmer at La Haus. And I had to move through all levels and phases of the company as we grew. 

What I’m doing now is, I’m managing the technology of the whole organization. This includes our tech vision, and how we are going to build a world-class engineering team in Latin America.

 

How big is the team now?

We have 40 engineers.

 

And at what point did you bring in Velocity and metrics? I imagine when you were a really small team, you didn’t need them yet. At what point did you start to feel like they would be useful?

One year after I started the company, I saw that I had to have accountability. But at that moment, I was not sure how to measure. I started exploring tools.

Then one year ago, when COVID started, we went remote. I have trust with my team and I don’t measure them by lines of code or hours in seats. But I felt we were slow. I didn’t know why. I didn’t know for sure. It was a feeling. You can’t make decisions with a feeling.  

So that was when I really decided to look for something.

 

When you did find Velocity, what was the first thing you did? 

I just started to look at how the teams were doing. I started to see a lot of metrics that were going down after we went remote. This was like the first finding for me, where I could see that we really were slowing down. 

I had done a lot of reading about Lean Software Development, I read Accelerate. I did a lot of research, and then I saw all of these metrics in the tool. So I understood what Cycle Time was and why it was important. I saw we were increasing, and then I had to communicate that to my team. 

Every week we have knowledge-sharing sessions. So, when I scheduled this session, I spoke about Velocity and Cycle Time — how you measure a process, not people. And how you improve a process. 

I said to the team, I’m going to start measuring the team just to measure the process and improve it. I’m not measuring individuals. So that was very, very transparent. And everyone was very open and happy and they were all asking me for their metrics and I said, “I’m not going to open these now, let me improve the process first, and then we can start exploring your metrics.” 

 

So, do you share metrics with everybody now, or not yet? Are you still in that working it out phase?

I share them within teams, but not between teams, because metrics change depending on the team’s priorities. 

The Team Lead shares the metrics with the engineers. We use the tools for 1 on 1s, and for personal improvement. We review each person’s dashboard with them, but we’re not going to fire someone because their Commits are too large, with too many lines of code. We don’t set a goal without a reason, otherwise everyone is going to optimize to reach that goal, and that goal isn’t the important thing. 

What we do, is we go through “Oh, it would be better if you deploy fewer lines of code. I’m not going to measure this, but when you deploy fewer lines of code in a Commit, it can move through the review process more quickly.” That’s good for the process, and it’s good for us.

 

So, which metrics do you look at? What’s most important to you as a CTO? Or does it depend on the team?

For me as a CTO, I have OKRs. So one objective is maximizing quality without losing velocity. And then we have key results there. One is Cycle Time. You are giving value to the business and you are giving value to the user when you deploy quickly. So we have a goal that is based on a benchmark you gave us, and it feels natural for us. It’s less than 24 hours. When you receive a story and you have everything well-defined, then you can, from your first Commit to the final merge or the deploy to production, keep things under 24 hours. 

And we use that metric like a health metric. You start noticing a lot of things when you don’t have that metric going well. We realized that some of our teams with high Cycle Time didn’t have well-defined user stories, and were struggling with unclear requirements. So we started improving user stories, and everything for that team has improved.

Do you ever bring metrics to the Chief Product Officer (CPO) and say, this is what’s happening and this is why we need to change course? When you had the issue with user stories and product requirements being unclear, would you actually bring them the metric and say, this is what’s happening and this is why we need your help?

Yes, it happened that time. First, when I saw we were going slower, I asked my team what was happening. And I saw there that the meeting processes, the ceremonies, how we had that configured, wasn’t working. So I met with our CPO, and I asked him to help me to build a whole design, development, and delivery process. 

And we created a new process, and after we created this new process, everything was starting to improve. And you could see the change from the first day we started using this process. The next day we were 20% better in the push metrics, impact metrics. And then after some time we were doubling the productivity we had before. 

 

That’s awesome. What would you say for you has been the most important success you’ve had with Velocity? 

It’s visibility. Visibility is very important because what you don’t measure you can’t improve. If you have visibility you can tell if your actions are working or not, and this helps you have a healthy process and to keep improving. For me, that’s actually delivering value, because you can improve your process and it makes you work faster at a higher quality, and that’s good for the business and it’s good for the customers. 

Do you have any data on your biggest improvement? I know you said that you doubled productivity. Was there anything else, like, can you speak to how much faster your Cycle Time was, or anything like that?

We had a Cycle Time of 72 hours and we went to 30 hours. So that’s around a 200% improvement. 

 

Would you recommend Velocity?

It’s very difficult to make decisions without knowing what is going to happen. And when you are not measuring something, you feel very insecure to make changes. With a tool you can go on and analyze and see, okay, this is why this is happening. And you can make better decisions. Even if you’re wrong and you make mistakes, you’ll have an easier time seeing what happened and how to fix it. That’s why you need metrics. 

To find out how metrics can help your team boost their productivity, reach out to our Velocity product specialists.


Actionable metrics for engineering leaders.

Try Velocity Free right_arrow_white

Start your 15-day free trial today.

See what Velocity reveals about your productivity and discover
opportunities to improve your processes, people and code.