Status Go: Ep. 229 – Why Invest in your Dev Team | Ramiro Berrelleza

Episode Highlights

[00:00:00]: The Beginning is a Very Good Place to Start

[00:00:35]: Development Experience Automation

[00:01:51]: Ramiro Berrellaza’s Journey

[00:04:59]: Passionate About a Problem

[00:09:29]: Software Development Lifecycle Trends

[00:14:34]: Is it all about speed?

[00:17:46]: Standards and Developers – Oil and Water?

[00:23:58]: Where to Start on the Developer Experience Journey

[00:28:06]: Actions After Listening

[00:32:24]: Thank You, Contact Information, Closing

 

Episode Transcript

Ramiro Berrelleza [00:00:00]:

You need to start from a point of understanding, asking developers, hey, what are the problems that you have? It’s a very powerful tool. What is getting in the way?

Voice Over – Ben Miller [00:00:15]:

Technology is transforming how we think, how we lead, and how we win. From InterVision, this is Status Go, the show helping It leaders move beyond the status quo, to master their craft, and propel their IT vision.

Jeff Ton [00:00:35]:

If you are a tech-product company, you know your dev team; your engineering team is your lifeblood. If you are a tech-services company, you know how important development is to your clients. If you are a tech-enabled company, a company whose primary product or service is not technology, you are probably becoming more and more aware every day of how important technology is to your company’s success. No matter where you fall on that spectrum, the odds are that you have a team of software engineers writing some level of custom code for your organization. When was the last time you invested in their experience? When was the last time you focused on making their jobs faster, easier, and more efficient?

Welcome to Status Go. This is your host, Jeff Ton. On this episode, we’re going to sit down with Ramiro Berrelleza, founder and CEO of Okteto, a development experience automation platform. Ramiro is passionate about helping CTOs and CIOs drive innovation.

Welcome to Status Go, Ramiro.

Ramiro Berrelleza [00:01:48]:

Hi, Jeff. How are you?

Jeff Ton [00:01:51]:

I’m doing great. I have been excited about this conversation. My background a million years ago is I was a developer and, man, I wish someone would have invested in our experience back in the day, but we won’t get into that.

What I’d love to start with, if you don’t mind, could you share a little bit about your background, your career journey with our listeners?

Ramiro Berrelleza [00:02:14]:

Yeah, I’m happy to. Just like you, I’ve been an engineer for most of my career. Now, I’m the founder and CEO of Okteto. But before that, for 15 to 20 years, I was building software, everything from cloud services at big tech, at startups, developer tools, a little bit of everything. Which has been very interesting because, as you said in the intro, all of these companies who are building software, whether It’s service providers, consulting companies, software companies, software is their lifeblood. So, I’ve been immersed in that world for a very long time. As you can imagine, I have a lot of opinions on the topic, but I’m really excited to talk more about that and why I believe that developer experience automation is something that CTOs must take into consideration as they build modern software organizations.

Jeff Ton [00:03:11]:

Where did this passion for engineering…for software come from in your background?

Ramiro Berrelleza [00:03:22]:

I’ve been passionate about this pretty much my entire life. Early on, video games were kind of like the gateway to technology for me. I grew up in Mexico, then moved to the US right after school. So, in the early days was video games, all style PCs that really got me into first kind of just being marveled at what technology could do, this kind of new form. But then, as I grew up and I started to learn how they work, I was fascinated by the potential that this back then, new technology, the Internet, then the cloud, had for really transforming everything.

And I’ve been lucky enough to see that transition from a world where software was not mainstream, kind of like an analog world, so to speak, to now the world we live in today, where every organization lives on software. So, it’s been fascinating, and it only fits into this passion of, like, hey, software is transforming the world. More and more people are involved with software. So now let’s make it easier for everybody. Let’s make sure everybody is effective.

We talked about this on the prep call, but how important it is for all of these companies to be good at building software. So, it’s been kind of a self-fulfilling passion for a very long time. I was lucky enough to work in tech, very well-known companies like Microsoft Atlassian, now a startup. So, it’s been, it’s been a fun journey. It’s been full of satisfaction. And just seeing the impact that software has on people, that’s all it takes to kind of get you hooked. Yeah, that’s why I keep coming back for more.

Jeff Ton [00:04:59]:

Yeah, I love talking with you about this, Ramiro, because the passion comes through. Your face lights up when you talk about this. Now, I’ve never been, I guess, a founder of an enterprise. I have my own company, but I don’t know if that counts. I’m not really building something. I’m helping serve others. But what I’ve always heard is for that entrepreneurial spirit, that drive is there’s got to be a problem that you see that maybe you see a solution for in a different way from somebody else. But what is this problem that you’re attacking with Okteto? And why does that problem jump out to you and drive you passionately?

Ramiro Berrelleza [00:05:51]:

That’s a great question, and you’re right. I don’t know if I could be doing what I’m doing every day with the challenges that come from founding a company if it wasn’t because I really believe in this problem.

And the problem that we’re solving at Okteto at a very high level is we want to automate everything developers do so they can get to work, so they can work on their thing. This is a very personal problem because this is something I’ve experienced throughout my entire career. It’s always, you join a new team, and you’re excited, you want to do some cool stuff. You’re working on whatever hottest tech it is at the moment. But then you kind of face this moment where in order to get to work, there’s all these things you have to do, right?

It might be an open source project, and you have this README with, like, 100 steps, or maybe you’re in a company and you have to go and collect all these accounts and passwords and set up instructions. And this is whether you’re new to the project maybe you’re starting a new feature, or you change teams. I’ve seen this everywhere and it always kind of annoyed me because there was so much time that I was spending kind of doing these setups, right? Especially as we move to cloud-native applications, this new world of Containers serverless Kubernetes, where applications have a lot of like they’re now distributed, so they have a lot of moving pieces.

I was spending more and more time just kind of, like, setting things up, trying to figure out which database I’m running. And then really, for me, the proverbial straw that broke the camel’s back was my previous team. We were, like, having all these issues around quality because when we were running the system in our laptops, it was like, hey, it works on my computer, works on my machine. But then it didn’t work on production, and there’s this joke around, works on my machine. But this really has serious products fail because of this. Customers suffer because of this.

So, when I was thinking, hey, what I want to do next, after spending five years in Atlassian, I was like, very clear, hey, this problem is something that I’ve been trying to solve for a while internally. Team by, you know, when I was talking to my, now, co-founders, really good friends Pablo and Ramon, we all can agree, yes, there’s a huge problem. We’ve all had this problem at our companies, and we were like, hey, let’s take a stab at it. And because it’s such a personal challenge, it seemed easy to us be like, yeah, of course, we need to solve this, because it’s something that needs to be solved because everybody has it.

Maybe naively, at first, we thought, yeah, we’ll do it. But that’s been kind of like the motivation for a company. And as we come up with this idea of developer experience automation, it is firmly rooted in the challenges I’ve seen in the last 15 years. And pretty much every team I’ve worked at, some solve it, others just kind of like, let every developer do it. But overall, it’s a challenge that keeps coming and coming. And now, as the CEO of Okteto, when I go out and talk to our customers’ community prospects, we keep hearing from everybody that how this is such a huge problem, how engineering leadership grows concerned about, like, are my developers just spending way too much time on this? Are they being effective? Do they have the right tools to be successful? And that’s where I’m hoping Okteto will help them answer these questions well.

Jeff Ton [00:09:29]:

And we talked about productivity on the engineering team. And how do you measure productivity, and how do you know that you’re getting the most out of that team? You mentioned some of the trends that we’re seeing in development containerization and serverless and those kinds of things. What are some of those trends that are impacting the software development lifecycle that you see from your seat?

Ramiro Berrelleza [00:09:59]:

Yeah, there’s a few different things that I’m seeing. First is, you have this continuous trend of making production automatic replication manageable. Right? We have like, as you said, containers…Kubernetes, a big player in that space. Now we have the GitHub movement. There’s a few other things. There observability, feature flags, allows you to test changes in production. There’s this trend of like, hey, how do we manage the complexities of production? That is one. The other that is closer to my world today is around how do we measure the effectiveness of my engineering organization.

In the last few years, been a lot of progress, especially in academia. With DORA Metrics, the DORA is one, Space is the other, which they both started as kind of papers, a lot of research, but now more and more companies are implementing it. And also, now there are more vendors who make it easy for you.

And for those who haven’t heard of this before, like DORA is this methodology where there are certain metrics that you start tracking, like how many deployments are you doing per day, how long it takes you to fix an issue, how fast are you merging code? And they’re being used as proxies for evaluating the effectiveness of your organization.

And then the third trend, which is the one that is close to me, is around developer experience. You have production, it’s automated, it’s working. Then, you’re measuring the productivity of your organization through DORA, and then you figure out, hey, I have some issues. Well, that’s where developer experience automation comes in, which is how can you create processes, whether they’re automated or just manual, to help your team go faster?

And this is where I was actually recording a podcast yesterday with the Open Source and Coffee podcast. And the host, Isaac, expressed this as teams need somebody to help them kind of remove the chances of them slowing down. And that’s what I think about developer experience is the emergence of platform teams, is the emergence of decentralized team that cares about standardization, about governance, about defining sandboxes. Because, that way…and I love the way Isaac put it…engineers then don’t have to waste time trying to figure out which database do I use? How do I get a copy of this service? It’s like it doesn’t matter. It’s all decided by the organization so that every engineering team can just go as fast as they can.

And that for me, is the essence of developer experience. So organizations, engineering leadership, they need to think of all these three things. Production has always been a concern. Developer productivity has always been a concern. But I’ve never seen it being as data-driven as it is now, which for me is a great process, progress. And now this world of developer experience is what’s kind of like I would call it up and coming, but it’s something that is now more formalized than before because we always had experience. The challenge was before it was left to every developer or every team to figure it out. And now we’re seeing this more like concentrated efforts with budgets, with goals, with mandates, from leadership to really invest and to be more intentional about the experience that you’re building.

Because and going back to the way you opened the show, all these companies realize that, hey, regardless of what you do, you might be an insurance company, you might be a bank, you might be a healthcare provider, you’re building software. And if you’re not good at building software, you’re making your job a lot harder. And that’s something that with Okteto, we talk to a lot of companies that I’m always surprised of the companies that we start talking to because they’re like, oh right, of course, they are developers. It might be one point we gave a demo to this national, not in the US. But like a state bank, and it was like, oh, interesting. They’re like, yeah, we build all this software internally to manage all our processes. I was like, oh, interesting, of course. Yeah, you have hundreds of developers, thousands of developers maybe, because even though you’re a bank, a central bank, you’re still a software company as well. And that is fascinating.

Jeff Ton [00:14:34]:

So yeah, they’re spending time and resources to build tools to help them build software when they should be building the software for the bank. Yeah, we talk a lot about customer experience, user experience. Is the developer experience all about speed? Or are there other nuances that enter into it in your mind that help the developer be more effective?

Ramiro Berrelleza [00:15:09]:

It’s definitely about speed, but I think that, and here’s where, as we mature as a practice, we understand more of this. It’s about speed in the right direction, right? Like going fast, but going backwards is not going to help your business. I think what’s very important, and when I talk about this with peers or in forums like this, is I always like to stress this, it’s about making sure that your team is working on the right things. It’s making sure that the time, the mental energy is spent in the right things, like cognitive load is something that now I think mature organizations are starting to understand more.

And the dangers of, like, if you’re thinking about a lot of things, you’re less effective of each of them because there’s only so much mental capacity, focus, attention that you have. So, a big factor of building a developer experience is making sure that through that, you’re enabling your organization to focus on what matters to the business. So that all the energy, all the creativity, all the flow goes into those tasks because that is what makes your business different. That is what innovation is going to make a difference. And that for me is very important.

Like velocity is important, rate of error, but definitely focus and morale. That’s something else. That as you build a better developer experience, having happier developers who feel more satisfied with their setup, who feel like, hey, the company is not getting in the way of me delivering value. And that’s something that companies don’t do it on purpose. But in several places I’ve worked in the past, you see where if you don’t have a good dev experience, developers are like, you know what, I don’t want to push this change because it’s such a hassle. I’ll just kind of leave it the way it is. It kind of works. It’s good enough compared to high-performing organizations where they’re always pushing the envelope.

But because they do have this experience that allows them to do that in a way that is safe, that is fast, that is without much friction. So those are aspects that I feel like leaders need to worry about. And morale, it’s a finicky thing. How do you know if people are effective or happy? But are things that leaders need to consider. And there’s now a lot of techniques asking like surveys are actually right now very popular and are surprisingly effective. Just asking developers, hey, what gets in the way of work?

Jeff Ton [00:17:46]:

Yeah. What’s slowing you down exactly? I love the concept of cognitive load because that points to quality, right? If you’ve got all this stuff going on and you’re not maybe paying attention to everything that you need to, errors creep in. In this day and age of cybersecurity threats, you want to make sure that your software is secure. So you want to focus on that as well.

Now, when I think of developers, and I can say this because I used to be one, we can be kind of a finicky bunch. We kind of like to do things the way we like to do things. How are you and your team working with your clients to, I’m going to say, impose standards on your development team by coming in and saying this is going to be the experience, this is going to be the toolset. How are you dealing with the potential of pushback?

Ramiro Berrelleza [00:18:54]:

That’s a really good one.

It’s actually something that we’ve been talking a lot internally because the other day in Slack, right, we’re talking about the word governance. Is this something that developers, how do they react to it? I agree with you. We’re all finicky bunch. And words like governance for some can bring back memories of this really bad kind of lockdown laptops and you don’t have root access to your device. You can’t install the IDE that you need or the patch that you need.

So, it’s funny because it does carry certain kind of checkered past. But however, I think that it’s true developers don’t like to kind of like this, but developers like to be effective, and they like when things are not getting in their way. So, one of the topics that we discuss a lot with our clients is this standardization, governance, and replicability are good things for the business. And that’s something that CTOs, have always understood. It’s nothing new.

Where it changes, I think, is the approach that you take. Because I feel like, as leadership shows to the developers, that this governance is not about kind of like senseless limitations, it’s about helping, always helping with the choices, helping with like, hey, I’m going to flatten the road ahead so you can go faster. So that’s where I think modern tooling overall and these kind of new tendencies around calling a developer experience, worrying about, I call this kind of like the developer ergonomics of is it easy to use, is it clear? I think that helps. Developers can accept that, hey, this is for my own benefit. This is not the old school you’re forced to do. This is more like, hey, here the other thing that I’m seeing a lot of companies are doing, which is great, is now we’re talking this kind of like centralized platform teams.

It DevOps their experience. It’s called in different ways in different places, but they’re starting to offer this as a service. It’s like developer experience as a service in the sense of like, hey, we’re building this, opt in. You can go your own way, and you have to build your own roads and cut down your own trees, or you can join us here. We’re going to do all these things for you, so you don’t have to worry about it.

And I think that’s something that I think more developers choose that way because I’ve seen this change so much over the past 10 to 15 years where nobody is really running CICD servers under their desk anymore because now leadership understands, hey, we need this. We’re going to invest on the emergence of best-of-class tools. For me, the fact that now organizations have budgets for tooling for developers shows a very important shift. Like, before, I worked for very large companies where it was unthinkable for a developer to be like, hey, can I get $1,000 a year for my IDE and this tooling for running tests or for a new device? A lot of these companies were like, no. Why do you need, no, you’re a developer. You have a computer standard issue. That’s it. So that has changed.

Jeff Ton [00:22:18]:

Sit and write code. Just sit and write code.

Ramiro Berrelleza [00:22:20]:

Exactly. And you figure it out.

And I think that creates this culture of defensiveness where you’re like, well, I’ll figure it out. And she doesn’t know what they’re doing, and we have to run our things rogue with my credit card and I have to find a way to expense it. I think that’s changing a lot.

So, definitely leadership needs to approach this from buy-in. Be empathetic of why are the needs of your team kind of explain why they’re being invested because it’s about, I really like the phrase, like, kind of removing the option for you to go slow. It’s like, hey, I don’t want you to spend the discussions of are we using AWS or Google cloud? It’s like, okay, the leadership decided, we made an analysis, and now we’re going to give you the tools. So it doesn’t matter to you.

That to me is when I see that, and I’ve seen it in some of our clients, it’s really cool how CTOs will decide, hey, we’re going to implement this strategy around their experience. And then you see developers groaning, why do we have to do this? And then three months later, you meet them, they’re so excited, oh my God, this is so great. My life’s so much easier now. I’m no longer fighting with XYZ. And once they realize that, they’re like, oh yeah, I guess there’s value in platforms, in standards, in sandboxes, in governance.

And that is on top of what the leadership or the organization needs around compliance, security, as you were saying earlier. So I think there’s a huge opportunity here for a win-win situation where everybody gets what they need, and together they help move the objectives of organizations forward.

Jeff Ton [00:23:58]:

Yeah, I think as you were talking, I could almost hear our listeners who are developers cheering, right? It’s about time. It’s about time.

But the CTOs, the CIOs that are out there, where should they start? When you go into a company that they’re probably doing agile development but they don’t have a lot of structure in place. They probably have Jira that they’re using and things like that. Where do you start, to invest in the developer experience?

Ramiro Berrelleza [00:24:34]:

My perspective here is that you need to start from a point of understanding. I think that’s where asking developers, hey, what is getting in the way? What are the problems that you have? Is a very powerful tool. It might sound like, kind of like, I don’t know, cheeky sometimes, but it’s really coming from the, hey, tell me the ten things that get in the way. Which problems?

Because it’s fascinating how and there’s a lot of research on this. When you compare organizations who do this very heavy data-driven analysis, like collecting all these things automatically, and then you compare them to organizations that going to perform the surveys and the results are the same.

So, what I recommend CTOs because sometimes CTOs join a company and they have a mission, right? They come with a mandate. They were recruited by the CEO to modernize the organization or solve some contractable problems. And sometimes they join, they’re like, okay, I’m going to redo everything, and this is what we did last time, so it’s going to work. Sometimes that works, but most of the time that kind of creates a lot of opposition from the engineering there.

So, I think definitely coming from a point of empathy, of understanding, hey, what are the problems that are blocking you because that’s where the world of developer experience automation can help a lot because there’s all these low-hanging fruits of things that nobody enjoys doing. Nobody enjoys having to manually deploy a service and a database, and all this orchestration, or very few people do. If you can automate that and then you remove like ten minutes from my workflow, right? Even if those ten minutes is enough for me to kind of go have coffee or chat with someone, those are ten minutes that I’m doing something much better than before.

So, definitely understanding where are your developers being blocked? Where are they seeing the friction? Because it might be non-obvious. We always try to optimize build times, deployed times, but maybe that’s not where they’re being stuck. Maybe we talk to companies where they’re blockers, where it’s very hard to do code reviews because the code is so complex, or it’s really hard to get started because I have to launch all this infrastructure, and it takes like 2 hours. 3 hours. Or in some cases, hey, merging to production is hard or merging to main is hard because the tests always fail at the end with flaky changes.

So, I think it’s very important to ask, and then definitely I’m a big fan of automation and bias. That’s what our company does. But for a reason. And it’s because I do believe that anything you can do that means developers don’t have to think about it, they don’t have to understand how the whole thing works end to end. That they can have these nice abstractions is worth doing. But assuming that is the problem, you definitely need to find those 80-20 where like, hey, solving two, three things is going to make it better for everybody. Because then you also gain buy-in.

And then when you want to make the more risky, controversial changes, your organization believes in you. And they’re like, oh yeah, they came, they fixed some things. Okay, we’re going to give them the benefit of the doubt. And then that’s where you kind of start to push the envelope and innovate on things that your team might not be super comfortable with.

Jeff Ton [00:28:06]:

I love this concept of going to your team and asking them, what are the blockers? Because you mentioned, no one likes to have to take the time out to do some of the repetitive tasks. The other thing, developers don’t like to release problem code into production. And if you can help them with their quality because your environment more closely mimics the production environment, I think that feeds back to the morale of the developer, right? That they’re not getting called out on some of those things.

Well, Romero, we are just about out of time, and as I warned you here on Status Go, we love to leave our listeners with a specific call to action. So, our listeners are technology leaders. They may be in a tech-enabled company, they may be in a tech-product company, a tech-service company, but they want to drive change. So, what are one or two things that our listeners should go do tomorrow? Because they listened to our conversation today.

Ramiro Berrelleza [00:29:19]:

Two things. So, the first one is, and I know I’ve said this several times, but I want to repeat it, is ask your developers, create a small survey. There’s a lot of resources on the web, and if you have any questions, please reach out to me. I’ll share my information with Jeff. But five questions or even one question, what is getting in the way? And let them be very explicit. You’re going to be surprised. You can ask them, hey, is it easy to release code? Is it easy to build a new feature like some kind of questions where you leave some leeway so that they can express do that.

And then number two is to look at those results. And of them, pick the one that’s like the biggest driver of change you can imagine, or kind of find something balanced with big change, kind of low effort. And automate it. Like figure out how there’s a lot of tools in the market, there’s a lot of companies in the market kind of helping with this. But find a way to automate whether it is release to production, whether it is running tests after a pull request, spinning up a dev environment, any of these things. Pick one and automate it because saving time and kind of like removing all these to differentiating tasks from your day-to-day is going to pay off. It’s going to pay off immensely year over year.

So surveys ask them, hey developers, what pains you? And number two is, hey, find one thing to automate so you can get it off your developers. They don’t have to think about it anymore and they’ll gain back that focus and mental space to do things that really matter for your business.

Jeff Ton [00:30:57]:

Get that quick win, get that under your belt.

Ramiro Berrelleza [00:30:59]:

Yes, those quick wins are…it’s something that I think that and I bet a lot of things also this quick wins is something that people, I think, underestimate a lot. But these small things are like paper cuts. Are there is such a thing as a dead by 1000 paper cuts?

Jeff Ton [00:31:15]:

Paper cuts, yes.

Ramiro Berrelleza [00:31:16]:

If you fix them, if you fix them, people just run faster and happier. Developers are more productive developers that you’re more trusting, they take more risks, and they innovate because they’re not going to innovate. As you said, nobody likes to release faulty code. It’s the worst feeling in the world where you break production or where you introduce a bug, and if it happens too much because of lack of tooling or too much friction, then developers will just stop pushing and be like only going for the safe changes.

Jeff Ton [00:31:47]:

That’s right.

Ramiro Berrelleza [00:31:47]:

And that’s how your competition wins. So, yes, keep that in mind. As for all. Those who are listening, especially CTOs, these are very important things, and these are things that should not be underestimated. There’s enough horror history stories in the world of organizations that because of paperwork cuts and bad morale, lose to their competition. I’ve been on teams like that. I’ve been on high-performing teams, and the difference is amazing. And it takes a lot of effort, but it’s easy to just, you know, start small wins, gain momentum, gain trust, and you’ll deliver amazing results.

Jeff Ton [00:32:24]:

Ramiro, thank you so much for spending time with us today. As I said at the beginning, as a former developer, I love the passion. I’ve always been passionate about the developer experience. I didn’t know what to call it back in the day, but now I’ve got words to call it. So, I really appreciate you being on our show.

Ramiro Berrelleza [00:32:46]:

Thanks for your time, Jeff. I enjoyed the conversation a lot. I hope your audience gets something out of it, but thank you for having me and looking forward with chatting with everybody. You can find me online. If you have any questions, feel free to reach out ramiro@okteto.com. And if you need help with your developer experience, just shoot us an email at podcast@okteto.com, and we’re happy to chat about all your dev experience, questions, needs, challenges, automation, or not.

Jeff Ton [00:33:16]:

Absolutely, and thank you for that. We will be sure to include those email addresses and those links in our Show Notes.

So, if you do have a question that you’d like to ask, visit Intervision.com/status- go. The Show Notes will have those links and contact information. This is Jeff Ton for Romero Berrelleza, thank you very much for listening.

Voice Over – Ben Miller [00:33:44]:

You’ve been listening to the Status Go podcast. You can subscribe on iTunes or get more information at intervision.com. If you’d like to contribute to the conversation, find InterVision on Facebook, LinkedIn or Twitter. Thank you.