Time, talent, and trade-offs

I prefer to always keep teams working on technical dev. I think it's super important that they pay off, because in the time they use to work on innovation, it's going to be very productive, rather than trying to fight technical dev doing innovation. Hi, my name is Trey Guinn, Field CTO with Cloudflare. Thank you so much for joining us. Today, we're going to have a conversation with Felipe Furlan, the CTO of Jimdo. They're a fantastic, innovative company, and we're going to have this conversation about time, talent, and trade -offs, thinking about where you put your energy. Is it going to be spent in maintaining your existing systems, where you're paying off technical debt, driving, you know, building new capabilities and innovation? What are the ways and the patterns that make an organization successful? Thank you so much for joining us today. Thank you for the invitation, really excited to talk to you. So I think, you know, first off, jumping right into this, one of the topics that comes up first is oftentimes around decision -making. And so if you think about decision-making, I've, you know, I myself have lived in a couple of different countries, and I've seen when I lived in the Netherlands, it was very consensus -driven. Everyone wanted to make decisions from the bottom up. And then other times, you have sort of tight, sort of top-down decision-making. What do you think makes organizations more successful, or in your experience, what drives the sort of, how do you think about where decisions should be made? So in the way that I see it working the best, we need to be super aligned to the company strategy. The role of the CTO is to understand the business strategy and set the technology strategy to make a fit from the business strategy. So usually decision comes top to bottom on the strategy. That's the path you want to follow. Bottom up how we get there. And then we make a lot of alignment meetings to get this through. I do not believe in consensus. I think it's a very difficult thing to achieve in the company that we have. But having these play key players deciding bottom up make the transition easier on implementing the strategy. I love your point here about having decision coming top down, but how you get to the solution bottom up. And do you have sort of key players and how do you think about the organizational structure of who's making those key decisions on how to deliver on that strategy? In our company, we have the executive team setting the strategy. So all the C levels, we are working very hard to understand where we need to go. The next level, the VPs, they're the ones setting up with the teams, how they can get through. And then they present us like, that's the project we're going to work. That's the initiative we need to develop. These are the things we need to get through. We sign off and then we work for the quarter. That makes a ton of sense. And then of course, the other question comes into how do you allocate people's time? There's often a big challenge of where do I invest in maintaining existing systems, maybe managing sort of paying down on technical debt versus building new capabilities and new functions and writing new code. How do you guys think about that balance? So it depends a lot on the moment the company is and also like how hard is to actually develop software. Three years ago, I set a strategy that every team should spend 60% of their time fixing our core products and 40% on innovation. And now we are slowly changing the pace. So we are being able to work more innovation than working on technical debt. But usually you need to understand like for each thing that you request, the product to be released, why they are taking so long? Which kind of complexity you have? And then you can balance the number to go through. I don't think there's a magical number. I prefer to always keep teams working on technical debt. I think it's super important that they pay off because then the time they use to work on innovation is gonna be very productive rather than trying to fight technical debt during innovation. Okay, so when we think about building new applications and driving innovation, oftentimes it's sort of a known thing with lean teams, this idea that the way you build a car isn't to build some wheels first and then attach an axle to it. Oftentimes you build a skateboard and then you build a bicycle and then build a car and you have to throw a bunch of the stuff away, but between sort of major versions. How do you guys think about this is, when do you start all over versus with a new code base versus when you build on existing code base and sort of keep paying off that technical debt? In our case, it's really depending on the company's strategical path. So I have an interesting case back in 2015. We started a business as a website builder and really focused on people who knows how to build website in a faster way. So you had to have the experience on building websites. You need to know about HTML, CSS, and all the core concepts about web. 2015 with Web 2.0, the new era started where we were delivering to you. So you don't need to understand deeply how to actually code something and I can provide you with a very nice website. When we made this transition, it was easier for us to actually isolate a team and they will have the core responsibility to rebuild Jimdo 2.0. So at that moment, when the business changed, the business model was different. I believe we should understand like, what actually can you do with your existing solution that will speed up your development and or it's a blocker in a way that you are working. And then when you answer this question, you understand that you should really start fresh. On the team perspective, I think you should always look to build something new. There are thousands of new libraries, thousands of new applications. The world is really evolving all the time. And as a team, you should take a look in our code base and make sure that they are up to date. That's why the 60% 40 or depending on the moment that you are is important. So pay your technical debt and make sure you're up to date. And so how do you think about that with your teams trying to keep them up to speed on what the newest technologies are? How much time do you want them to spend on experimenting with AI code development or the newest framework? And how often should they be bringing that into an existing code base? I would say that at least one day a week, they should be so focusing something that is new and trying out improvements to our existing code base. We do have a day that is really focused day where they can actually research and provide benefits to the business. As an engineer by heart, I think like if you are not researching outside of your working hours, you are just like not doing it right because you need to learn something that motivates you. And I know from every single CTO that I speak with, it's really cool to really understand how the world is evolving. With AI, it's really like AI is changing the game and how you can really code very fast. And if you have the guardrails in place, you're gonna win. So I really incentivize our people to research the tools, to use the tools, check ways of getting faster and it's really paying off. That's incredible. So you have these really curious engineers that are the best case, they're diving into the new technology, but I'm guessing at some point, they'll come to you and say, hey, I've got this grand idea. I want to take this part of the code base or this part of the platform and build it all new. And I need a big investment. I need a team. I need a certain amount of time. There's always that time when an engineering lead comes to the CTO and ask for a bunch of budget. In our innovation report, we actually found that the teams and organizations that are most successful are expecting large investments in modernization over time. When someone comes to you asking for a lot of budget and team, how do you think about what to fund and what not to fund? It's usually related to the company strategy again. So I know which kind of features and services I need to provide. So I really map it out. Like these are the places in my code base that I need to touch more faster. So I need to iterate faster. And at that moment, I actually give them the budget to innovate. So I really make a case, I understand the business case and investment case. They're accountable for getting this done. So it's not just asking for a budget. They need to make a case and provide clarity. And if it's related to the company strategy, we get sign off and we invest. And I also saw an increase on investment cases from improvements to AI. You need to get our foundation ready. So we are really investing massively to get this done. And when someone's making that case to you, let's say you have an engineering lead that's making that case, what are some of the key questions you ask them to make sure that they've built that case out fully? How this makes us faster, how this makes us less complex, and how does improve the product conversion? Three simple questions. Yeah, just all aligned to the company strategy. Always, always. Fantastic. So you've got some engineering leads, they've come to you and they've got this great proposal. And we've all seen this before, right? Where you've got a great business case, you know you're aligned to the company strategy, but then you kick off this investment and they don't always work out, right? Do you have any lessons learned when the return on investment wasn't what you expected? Absolutely. We had a very big failure in one of this investment projects that we did, mainly because we missed an opportunity in the company and our company strategy changed. So I had some half-baked investment projects that were up and running for more than two years, which was super painful to maintain. My recommendation is always break the work down in small chunks, like you said about the skateboard and the wheels and the car, because then if something goes wrong, at least you have things delivered completely and then you don't need to keep going. But if you make a very big release plan, then when you're in the middle of the work, it might have to stop. So for us, it was challenging. You raise a really interesting point about how important agility is because the market is changing constantly, which means your strategy is changing constantly. So if it takes you two years to deliver something, chances are what you're delivering, the problem you're trying to solve may have changed in that process. Thanks so much, Ferlan. This is a great conversation, super interesting to learn about what are the patterns that really innovative companies can use to drive agility and drive innovation inside their organizations. Please join us here for more conversations and follow both the podcast on Cloudflare TV for the Beyond the App Stack shows, as well as look out for Cloudflare's App Innovation Report, which will give you more of the stats that show across thousands of organizations what has made them successful versus others.