Here's the truth. Hiring remote engineers doesn't have to be expensive and time-consuming. Our friends at Revello can help you find and hire top engineers based in Latin America in a matter of days. Just tell them what skills and experience you're looking for. They'll come through their network of over 400,000 pre-vetted engineers and give you a short list of curated candidates that meet your specific hiring requirements. You interview
and hire on your terms and only pay for as long as you keep the engineer. To learn more, visit revello.com forward slash ELC today and save $2,500 off your first hire. This company's involved. People change roles and the technology changes, the requirements change. We chose the product does it in method A. Let's ask, okay, why did we choose A in the first place? And once in a while someone from engineering came up and said, yeah,
I have a great idea. Let's do B. And I would always send them, okay, go back to the accommodation, go back to whatever you can find because if you thought this rule and you think that making these changes worth a while and there is stability in the making, let's go. Hello and welcome to the Engineering Leadership Podcast brought to you by ELC, the Engineering Leadership Community. I'm Jerry Lee, founder of ELC and I'm Patrick Gallagher
and we're your host. Our show shares the most critical perspectives habits and examples of great software engineering leaders to help evolve leadership in the tech industry. A major question that often plagues senior leaders, how do I balance where to go deep into technical problems and how do I maintain a higher level view of the business and
strategy? It's the age old, where do I go deep and where do I stay high level? Joining us today is Odette Kedem, CTO at Big Panda, who shares his experiences with us navigating this tension between technical depth and high level business strategy and in our conversation we talk about how to prioritize where your time is best spent going deep into the technology,
how to bring technical expertise and value to the executive team. High impact questions for you to ask during those executive conversations, we also get into bridging the gap between marketing and technology, aligning customer expectations with product capabilities and so much more. Let me introduce you to Odette. Odette Kedem is CTO at Big Panda and brings a wealth of experience in software from ground up development to managing engineering teams.
Odette is also the founder of Zerto, a cloud BCDR company. Enjoy our conversation with Odette Kedem. Odette, first off, I just want to say welcome. Thank you so much for joining us on the show. How's your afternoon going? How are things? Thanks for having me. Yeah, it's a good afternoon. I'm in the office, pretty much finishing by day in the office because it's starting to be afternoon here. That sounds like a good
day. Very good. We'll have a fun afternoon wind down to send you out of the office. We've got a lot of fun planned for this conversation because when I was thinking about this challenge, this is something that I think at a lot of different points, when an engineering leader starts to reach a certain level and starts to begin having a higher point of view on the business and the role of the engineering org within that business, it causes some tension.
I think that's where we're going to spend a lot of time talking about is this tension here. How do you navigate this tension? I think you have a really great perspective here and in a lot of the different roles that you've done, but even now with what you're doing at Big Panda. I think the first question for you when you're looking at this dilemma, what does it mean to you to balance going deep into the technology and keeping a high
level view? What does this mean to you? Why is this hard and why does it matter? When somebody asks me somebody off the street or somebody from this centrality of what I do and I answer, I'm a computer programmer. That's how I started, that's the passion, that's the background for everything. So I started off as a computer programmer. I know to do the right code, I write code, I love the code, I love dealing with the problems
around software development and code. But as we grow, as we progress in our careers, I progress, I started moving into management where you start dealing with more and more strategic topics and not just the code. But I did find that I always have to understand the roots, the basics, how things work, why they work, and to assist in the strategic
decisions. So for me, if I would just be sitting in an executive room, if you just take me to a company, a new company, and I'll be sitting in the executive room and I wouldn't know how the product works, I wouldn't know the problems, the strengths, what can be done,
where can we take it in the future. I'm not sure that my value that I would be able to provide that much value, I would just be like, so you have the chief revenue officer, he knows how that person knows how to sell better than me or the chief marketing officer. So the value I can bring to the executive table actually comes from my deep knowledge of
the product. And in order to get that, you also have to spend some of your time in the day to day, in the problems, in the bugs, support cases, in the stuff that maybe some people see as tiring or day to day for me, it's actually the cool stuff. I think this perspective that you brought out is, I'm a computer programmer and in order to be able to, you're going to start to be able to be pulled into more strategic concepts
and that you need to know the basics in order to be able to do that. And I love this question of thinking about what is the unique point of view or what is the value that you provide to these decision making conversations. I think it's really powerful. I think you've, there's a, there's a story you and I talked about that I think kind of covers this role or this tension for you. And I think it was like the first couple of weeks that you,
you came into the company. So Zorin, if you could tell us that story and how did that connect to this problem for you? Yeah, that's, that's actually a very good one. So coming into Big Bandar, Big Bandar has existed for a while before I came in. And then I came in as a CTO, some supposed to know a lot of things I'm supposed to be involved in strategic decisions. But to be honest,
it's not like a previous company is where I was in the founding team. So lucky for me, there was a situation where a team leader was missing for a team that was working on a very important project. I said, I have time, you know, I'm still in the learning stuff. I have, I have time, my first month in the company, I approached the director, manager of that larger organization, and I asked them, I asked the person, can I fill in for the team leader until you find,
until you find someone? You don't need to keep me there forever, but I'm going to solve a problem for you in the beginning. He thought I was joking, but then I put him again, said, I'm not joking,
come on, let me do it. I'll get out of it just as much as you do. And he did. And for me, this was the best decision I made coming into the company because I was dealing with a project, it was a project with dealing with AI, with new technologies, court to the business, innovative, working with the engineers, understanding the code, understanding the coding practices of
the company, and you know, being able to contribute something. When I go back to the executive room, and they do executive stuff, I already know a lot of things that I wouldn't have known otherwise. Ever since then, a team leader was recruited, was actually promoted, and she's doing a great job, and it passed everything to her, and I'm happy that I did. But for me, that was a great experience, and a great way to touch the code in one end, and leverage that knowledge into executive team.
I have a couple of process questions for you in assessing this, because I can see how excited that you get when you start to think about some of the biggest problems that are facing the business, but also some of the biggest technical problems that are facing the underlying products and features that you're building. So you're sharing some of the conditions that why this was a good opportunity for you to spend your time, even though you're just getting involved
in the company. So I was wondering if you could talk a little bit more about like, how do you choose where to go deep into the technology? And for you, like, what does it look like process-wise, so like to start to get deeper and more involved in those particular elements? I always like to go into the things that may not seem as exciting, but are important, and maybe are difficult. That may be what brought me to work on infrastructure.
It's very important. People may not see it as cool, even though it is. Within the company, I always like to look at these things. Let's look at these things, the things that are causing, maybe if they have issues, it would cause tension with customers. Maybe it's something where the company is trying to get into something, but we don't always have everything in place, all of the core competencies that we need to build. Anywhere that there is some
kind of struggle, and I would say, okay, let me help there. And I think that actually goes back to how I started. So coming out of the university, when I studied computer science and the cool thing, what everybody thought was the coolest, was building algorithms. If you're smart, if you have good grades in the university, that's what you're supposed to do. And that's actually what I took as
is a very first role, building a compression algorithm. But then I got approached by the first company, the first startup I worked in Kashiya, and they said, we need a device driver developer, and there are no devices, we need to build something that needs a device driver, no device driver's developers out there. I said, yeah, give me that challenge. It's not algorithm, it might not be as cool, but it's super important in the core of the product. And if it breaks, everything breaks,
and if it doesn't work well, everything doesn't work well. And that's how I started. I started this device driver developer, and I get promoted from there. And I'm taking this approach everywhere I go. DevOps are my best friends. I like the stuff that's working on the infrastructure guys. Anybody that's doing something that's important for the company. And maybe there's some kind of struggle, maybe there isn't. Like maybe they're doing great job, but it's interesting. Then
I'd be interesting to hear what they're doing. And if they need any help. What you mentioned about is it important, and are there people struggling here, and identifying that as a big opportunity to make an impact? I think it's really interesting. How do you choose the opposite of this? How do you choose what not to go deep on? Because obviously your time is really finite, and you're also doing a lot to build the organization, you're focusing on a lot
of different other elements. How do you say no to certain areas and choose where to focus? So first of all, I wouldn't say a complete note to anything, because as an executive leader, you're supposed to be able to at least touch a little bit of everything. Also from the human perspective, you don't want to tell someone what you're doing is not important. Everybody's
important. It's a team. If one piece breaks, everything breaks. So I like talking to everyone, but if there's no struggle, or if I can't contribute to anything, then I'm not going to push myself in. If the team is doing great, if they don't need anything, if you don't need my advice, great, good job. Keep up the good work. Yeah, maybe I'll let's drink some coffee, just tell me about
what to do. So I'll just know what it is. But maybe I don't need to dive into the code. But if there is an area where there is a bug, a support case, something breaks, and I see people struggling, and I see people getting a bit agitated. So yeah, maybe that's a good opportunity for me to jump in. Maybe I can contribute something, and then they'll be happy. It's not like I force myself in, because they'll be happy to hear. If I can provide them some added value, then they'll be happy
to have me there. And I'm getting back the value, because I get to understand, get a better understanding of product, of the inner of the product, and I get a better understanding of the strengths and weaknesses of the product. And that's pretty much the most important thing
that I can take back to the executive team. I'm just making a quick note, because I think that that last point that you shared is super interesting, is that even when you're talking about like everything people are working on has value, and then getting them involved, like helps you better understand the strengths and weaknesses, and then take that perspective back up to the executive team, I think is really powerful. Has there been an area where it was really difficult to hold back
from getting involved in like a deeper way? Like was there an area where like I really want to get involved, but I shouldn't. Like this is interesting, but maybe I don't have like the right contribution for this. Like was there was there ever an area where you were like where you had to really hold yourself back from from jumping in? Absolutely. And if maybe I can even think of some examples, but generally speaking, where I need to be careful jumping in is I need to make
sure people are getting enough space. Do you not taking away their capabilities if they can solve it on their own? And maybe they'll solve it a little bit different than how I would do it. Taking that step back is very important. I think I heard once that one of the key things is as a manager is letting people do things in a way which you think is not ideal. But as long as it's good enough, letting them do it on their own. That's the balance. And I wouldn't say I'm
perfect. Sometimes I can't help myself, but the offer that applies. In many cases, I really try to say this is an advice. This is your area, your judgment, especially when you're speaking to meat-level managers, like team leaders or group managers, have to give them the space. You have to let them grow. If you think they're making a huge mistake, yeah, tell them. But if you think they are doing something which is in a way that is different, then how you would do it? I want to
emphasize is what I'm giving you is an advice, but not directions. Like forget my role in the organization. This is just an advice you think you know better. And by the way, you know better because you're there every day. I'm there some of the days. I just started being more intentional with trying to do that at the beginning of a language. We're working with different collaborators to be like, you know, my role in this conversation is I'm providing a little bit of consulting, but I don't
own this. This is your space. This is your area of expertise. And the path forward is your decision to make. That is so powerful in giving more agency and ownership to your team. And trying to reduce like the impact that you can make or the influence that you, unintended consequences of your influence on a certain decision or path forward. So I really like that. If I didn't convince them, if they felt that my input was not valuable enough, they shouldn't take it. If I can't provide value,
then yeah, I shouldn't be in that room. Or maybe I should be there as a listener, not as a decision maker. As a US company, hiring remote engineers can be time consuming, expensive, and frustrating. You could hire freelancers, but you don't know how much they'll focus on your business. Out sourcing to dev shops, risks, control over who works on your projects, and expensive long-term contracts. Or you could look overseas, but working across lots of time zones can really slow things
down. Enter Revello. Your gateway to a talent network of over 400,000 pre-betted engineers in Latin America who are proficient in English, work in your time zone, and are dedicated exclusively to your business. Revello simplifies the hiring process, enables quick payroll in local currencies, and provides expert staffing support. There are no big up front contracts. You only pay for each month that you decide to keep your developers employed. With Revello, you're in complete control.
You get to decide who to hire, what to offer, and you get to decide how long to keep them on your team. To learn more, visit revello.com forward slash ELC today and save $2,500 off your first hire. One of the things that you brought up a couple of times is bringing value back to exec. And how knowing intimate details of how things work is a big part of the value that you can provide.
And so I was wondering if you could talk a little bit more about how do you bring value to the executive table and then what types of conversations does the depth of your technical expertise create with the executive team? How do you bring the value to the executive table and what types of conversations does that open up for the types of decisions that you all have to make
together? There are a few aspects to this. I think the main one is knowing the strengths and weaknesses because sometimes if you look at the rest of the executive table, they will find potential. They will say, in this area, there is very strong potential. We should go there. There's business potential, our competitors are not doing it, they're not there, they're not doing a good job. Let's do it. And yeah, engineering and product, they'll figure it out and build
us a good product. And for me, I have to provide that honest advice, guys, this is not in our core competency. If it's not in our core competency, if it's not where we can differentiate or it takes our product away from where it is or where it's strong at, then maybe we should revisit it.
Because I really believe that you should strengthen your strengths. You should invest where you're strong, it's a company, maybe it's a person that's a little bit different, but as a company, you should invest where you're strong rather than trying to fight an uphill
battle for your weak. Knowing the code, knowing where we have a lot of issues, knowing where we struggle to get the product to work right and in some places where we have an engine or a patent or an algorithm that nobody else has or an architecture, then in those cases, yeah, let's double down on it. Do you have a story or an example that captures that conversation? Because I can imagine there are probably different points of view or different
tension or perspectives. When you're talking about, here's our strengths from a technology perspective. Here's where I think we should invest. Is there a story or example that captures what that conversation might look like when you're talking about where to invest the time and the resources? If I go back to my Zerto days, Zerto had a very powerful
replication algorithm engine. We always had pool from customers and from the field, and it worked very well in certain environments like VMware and some cloud environments, but in others, we didn't have a solution and we always had the pool, let's expand to that, there's business there. But in some of the cases, we couldn't utilize this strong replication engine and we would have to build a tool that would be much more similar to competitive products
without taking advantage of that strong algorithmic engine. That's where I would always push back and say, I'm not going to say no, but I'm going to say, it's not going to be as powerful as a regular product and we need a good explanation on why it would be successful because it's going
to be harder for it to compete. It's going to be much more similar to the competitors. If we can do something that's closer to where we're strong and take advantage of this engine, then we could have a much better product, much more differentiated product and it would be easier for it to succeed even though that might not be the place where you had these few of opportunities
called you up. That conversation must be really, really difficult because I imagine some of those partners, they're really excited about the new business, the new opportunity and they're seeing those things come up and then you have to hold the tension of the capabilities or what might actually be the best place to spend our time. What have you found really work in that type of conversation with other folks? So first of all, you're absolutely right. These conversations
were there. There was a lot of tension. It wasn't easy. First of all, I'll start with the team. If you have a team that trusts each other and there's not a feeling where I'm trying to take over their job, then it's much easier for me to convince them. The other is to ask questions and to lead everyone to the same place rather than have a strict answer. We shouldn't go there. I'm not going
to say we shouldn't go there. I'm going to say if we go in, if you have two options, A and B, yeah, I know you got calls from partners on A and less calls on B, I know, but our technology would be much stronger on B. So like I'm telling me, I wish it do B. You guys don't know what you're talking about. If you're the God in this direction, it's not going to end well. I will say, yeah, it's not going to have this the same level of differentiation. Let's discuss how we can
differentiate there. I don't want to use winner lose, but I think we would go in direction A because they will find some other directions and sometimes they get these ideas from customers.
There was an example where they said, yeah, our core engine would not fit there and we would have like an inferior engine inferior to what we're used to, but it's as good as the competitors, but our product also has other capabilities like the ability to support a very large scale and our customers are our partners or our potential customers are complaining that they're having problems
managing its scale. And in that case, I said, yeah, okay, let's go. Make sense. But if they wouldn't have that then it would be easier for me to convince them to go into the other direction. The question that you're asking sounds so powerful because it's both like questions to help lead people to maybe a path in your opinion that might be the right path, but also to help get you more information to be like, oh, actually like what you're talking about is the right direction
and I guess concede your position to make the best decision for the business. And so I wanted to have a little bit more to the types of questions that you ask in this conversation because in my opinion, like I think questions are some of those powerful things that like any leader could be equipped with. When you're going to these executive conversations, like what are the questions that you ask? Like what does that look like? And maybe what questions have been most
valuable to you? I think I would just ask the honest questions trying to understand the full story. A good working team, any team, not just an executive team, is a team that works together rather than every person owning a piece. So if you look at an executive team, if the CRO only is the only one responsible for sales and the chief marketing officer is the only one responsible for marketing and they say, okay, this is my area. I would just inform everybody. Yes,
that wouldn't work very well. A good team is a team where everybody collaborates. Everybody also asks questions and collaborates on areas of expertise of others, but it's still obvious that the CRO is the expert in sales and chief marketing officer is the expert in marketing. So if they bring up an idea, if they bring up a direction they want to go, I would honestly ask the questions to really understand what's going through their mind. And yeah, maybe in some
cases I would say, yeah, but I would add my own information. Yeah, you know that, yeah, this is what our product can do well. We tried going in this direction maybe a few years ago and we hit some issues. Do you know that? Are you aware of that? So I would try to also provide some information, but starting off, just asking, trying to really honestly understand what's behind it. And by the way, sometimes, sometimes it wasn't, sought all the way through. And those
questions would expose that and we would jointly agree to go and take another look. Is there a moment or a specific example that comes to mind where these questions to better understand what's going through their mind? Like from your point of view, impacted the decision or the outcome in an interesting way? So we've had, in certain, we've had quite a few junctions similar to the one I
described before going into environments. And the example I gave before were these questions actually revealed to me that there is value, but there were cases where it revealed that there wasn't enough value because there was a similar case where the environment, the platform that we're supposed to support, or we were asked to support, we were asked by a vendor, which was like not a huge platform, it was owned by a specific vendor. And then I started asking what's the nature of
the relationship with that vendor? In turn, it wasn't very deep. It's not like we're beating or anything, but it wasn't very deep. And then if we would go and make a huge investment there, and the vendor doesn't have any commitment to us and also working with competitors, I think that exposed that it wouldn't be a very good place to spend our resources. And we decided not to do it. And today, even though I'm not there anymore, that vendor is still not
supported. Even though there is business there, and the vendors sometimes get calls up some of their business relations folks or business development folks and ask them, okay, maybe we can do something together. It's not like they're willing to commit or not willing to do a lot on their part. And these are questions that are not technical, but we got to call, okay, we got to call from the vendor and I was like, okay, you got to call and they said some nice stuff, but what are they
committing to? In these conversations, like, has there been a favorite question or a type of question that you found to be most impactful into these types of conversations? Please elaborate, please explain the full plan. Sometimes we all tend to fall in love with titles and say, yeah, this is a title. This is something we should do. Let's go for it. And then, okay, what do we understand?
The immediate answer you might get is, yeah, we don't have a full-blown plan. And this is where I wouldn't say that I'm not asking for full plan, but just more details, what's the thought process? Maybe a high-level plan or a very rough plan on how this can be a good idea for the business. If something wasn't fully thought through or if it has limitations, those would be exposed. And like I said, in one of the examples, I gave. Sometimes I would learn things that they didn't
even think about. I wanted to dive into a different topic. I think related to bridging this gap between some of the perspectives and strategic input from other executive leaders and bringing it back to engineering. And it's this element that you and I were talking about earlier about bridging the difference between marketing and technology and helping bridge the gap there, like helping
support both organizations. And so, how do you act as that bridge and what is that conversation or that tension look like to navigate the marketing versus how the technology actually works? I'm not sure I would call it tension. I'm really a firm believer that the closer the marketing is to tell the story of what the product really does, the better outcome it will provide.
Marketing material looks nice. It's not that it doesn't always look the same as the internal stuff in engineering, but as long as it tells the same story, it would be very valuable. And if it doesn't, then I would call it out. I would say, yeah, this mark, I'm not sure what this architecture really means. There's an element here, but it doesn't fit into any technical term or maybe into a value. It could be a value that we provide customers. And that one I would ask,
okay, how do we fit it in? And working together, I think if we end up, I don't think it should be a conflict. I think the marketing material should describe what the product does. I'm a firm believer in works as advertised. If your customers feel that your product does not fail them and provide it exactly the value that I advertised, these customers will bring a lot of other customers.
And everybody's going to benefit from it. I think for folks listening in, they probably didn't put like, oh, my responsibility as I become more of a strategic leader is to also possibly audit. I guess for maybe more depth tool oriented or like technical oriented companies, like my responsibilities, the audit, the marketing to make sure it works as advertised as it works or works as advertised. How much of a role does this play like within what you're doing now? And when do
you typically get pulled into these types of conversations? So in big kind of the executive team is very tight, very collaborative. Everybody reviews the market picture. It's not just me, everybody in the executive team including the CFO. Everybody has a saying the table and everybody is supposed to have a saying the table. And I really like that because it's really working as a team and not as a group of individuals who own of department owners. And I really like that in Big Panda.
And I did a bunch of it this week and it's not like they called me in to the conversation because I'm CTO. I was in the room because it was in the executive staff meeting. It was raised in the executive staff meeting. That makes sense. Do you have a story that comes to mind where this really impacted how the product was being marketed? So, or your input or like the engineering perspective helped shape the approach or like the impact of like really caring about this and
making sure this is a big part of the conversation helped change the outcome. Is there a story that comes to mind? If I go back to the Zerto days, it was important, you know, when you say a Zerto worked in the cloud. And then there's always a question, what is the cloud? Or at least that there was a question that I went in the early days. What does it really mean? And we had those dry grounds with clouds in them. And for me, it was always very important to like, let's make sure that
we emphasize what the cloud means for us. Is it the supporting for AWS or Azure or is it just a general networking environment? Like I said, better you align the customer expectations. Now we're just discussing architecture right now, but it's not just architecture. It's the messaging. If we align our customers expectation with what the product really does and we make sure and then go back to the engineering and make sure that it really does what we say it does. That it doesn't
fail the customer. There were going to be in a very good position. This is especially in enterprise infrastructure business. It's super important for the products to be there when the customer needs them. It's just as much working with engineering on the day to day, maybe very tiring, making sure that everybody is followed up on. And sometimes you would see me going after things if you understand why.
I write everything down. When I see that there's an incident, I put in notes, okay, people are working on it, people are going to resolve it and people are going to find the root cause and remediate it. But I'm going to go back to them in a week, in two weeks, in a month, and I'm going to say we implemented the lessons learned. Like I said, everything is around making sure that product works as advertised. What this makes me think of a little bit is some of the things going on in the sort of
AI world. And that a lot of products are sort of being labeled as AI. But this question that you throw out there, I think is so powerful of like, what does this actually mean for us? And is it aligned with customer expectations? I think with that one's the thing that a lot of folks are working on different AI features, products, and things like that. From that perspective, do you have any advice or perspectives for folks that are trying to play that role where they're launching
these amazing new features, but people are slapping just the AI label on it? Do you have any insight or advice for folks maybe navigating that that tension on how to maybe better align customer expectations of what the product is actually capable of? Yeah, so absolutely. And we're also going through it as we're building AI functionality. AI is our generative AI or LLAMs. That's super powerful technology. We're all lucky. We're all lucky to be working in technology in times where we have
this super powerful tool in our belt. My parents were also computer programmers. They didn't have this tool. And we have this tool. Our companies are lucky because they have the disability. But the end of the day, we need to generate value for customers. And we understand this is the value the customer is getting. Yeah, we use AI in the backend and it could be we use LLAMs, we use generative AI. Always scale more classic AI, whatever we use, it's interesting. It's cool. Customers care. They
want to know how their product works in the backend, but it can't end there. It has to be providing them real day-to-day value where they can do their job better. I would say don't focus just on the how, how is important, but how cannot be the technology cannot be the only thing you you provide. You need to provide value. Anchoring on the settlement of providing value, I think it's so powerful. And especially like in all of the different touch points that we've talked about,
going back to when do you go deep on the technology? It's like, well, when I can provide value. And so it kind of sounds like when you anchor on this element of where can I provide value? How is this adding value that helps to really prioritize areas that you're investing your time in or how to even begin communicating about different things? I wanted to go back to this theme that we've been talking about with where to go deep versus where to maybe spend more time at a higher strategic level.
And one of these areas is about changing past technical decisions and navigating when to do that, how to insert yourself into that process or what role should you play in that process. And so I was wondering if you can maybe share with us like how do you think about or approach changing a past technical decision? That's a very important thing because this company's involved. People change roles and the technology changes, the requirements change. You need to make changes in the product.
For me, I always like to take the balancing approach. In a lot of cases, people would say, okay, let's change it. We chose the product does it in method A and let's do it in method B. And I would always say, you know, it's not a conservative approach. Let's not touch it. I like touching things. I like even breaking things because then the day you end up with a better product. That's not the case. But let's ask the questions. Let's ask, okay, why did we choose A in the first place? Now,
maybe it was done by a person that's no longer even in the company. That's fine. But you really need to find that good explanation. You have to assume that that person was intelligent. They knew that what they were doing. So maybe there's something that they didn't know back at the time. Maybe
we learned new things from customers. Maybe technologies change. But something has to change. I would really be cautious making this decision with just assuming that a person a few years ago made a mistake. Now, sometimes that is the case. But you have to think about it once, twice, maybe even three times ask the questions. You know, even call that person. He's no longer in the company. Who cares? Call them up. Ask them. Why did you choose that? Maybe we can maybe they documented it. And
sometimes you would learn that the decision wasn't, it wasn't such a stupid decision. It was a good decision. One of the examples I have more in my desert today is that we need capability for parsing file systems. And there's really too pretty much high level technologies for doing it. And the product like early days decided to do it in one way. And once in a while, someone from engineering came up and said, yeah, I have a great idea. Let's do B. And I would always send them,
okay, go back to the documentation. Go back to whatever you can find because they're pros and cons to each approach. It's not like nobody thought of B, but maybe it's better. I would also take the other direction. It's not like, yeah, don't make any changes. Yeah, you're responsible for this code. Now, good. If you thought this rule and you think that making these changes worth our a while and there is can, you know, and the instability that may bring, let's go. Let's do it.
So going back to why did we choose this in the first place and examine like, was there a good explanation that existed? Maybe look at the documentation. But then I like this question of like, did things change? Or did we learn something new and going through an assessing just like the environment that you're operating in or like the context of the business or like the evolution of technology and like in that environment? Are there other questions or is that kind of, is that
your typical framework for this? And are you doing this in a conversation? Are you reflecting on your own? What does it look like in practice? In practice, it would be in a conversation. So it's mainly why was this approach selected in the first place? Why was the approach you're suggesting now not selected? Did they not think about it? Or did something change throughout the way? But it would be pretty much in a conversation. In many cases, it would be sending that person to like to their
homework and come back. If they come back and they have a good explanation, great. If they don't, great, let's make this change. Like I said, I'm with the approach that it's good to change code, it's good to renew things, not to be conservative, not to be afraid to touch it, make sure that everybody owns what they're responsible for, but you have to do it responsibly. Because what I'm really concerned about is changing and then changing back and so forth. So I would typically say you
explained to me why this is a good idea. Go back and explain what change, why wasn't it selected in the first place? Oh, Dad, we've got a couple minutes left on our time. We've got some rapid fire questions if you're ready to jump into those. Yeah. All right. First question, what are you reading or listening to right now? I'm reading a book. I think it's called frosting strangers. My Malcolm Gladwell. It's about the way people decide to believe someone or not is like,
how bad our intuition is. And it focuses on some big mistakes in history where everybody thought somebody was telling the truth because of the way they looked or the way they behaved, mostly the way they behaved. And also vice versa, everybody thought somebody was lying just because of the way they behaved. Just focusing on that our intuition isn't very good in this case. I love it. Next question, what tool or methodology has had a big impact on you?
Okay. So for me, it's like the two big revolutions. I don't know. I feel my love to provide to the first one that changed my life was cloud computing, cloud virtualization, VMware is a company that did great things in the past. I had a love hate relationship with that company. But you know, if they wouldn't have invented what they invented, I probably wouldn't have had zero to in the first place. So I have to hand it to them and to all the folks that built their cloud, the cloud
providers like Amazon and then Microsoft. And obviously I think that impact that the majority of my career. But I'm super excited about I think what's changing right now is AI is it's even bigger. It's much bigger. It's changing everything. It's not just changing our professional life. It's not changing our personal. The way we do it's not stuff in the personal life. My kids use it. Sometimes maybe to do school stuff. I don't know if that's the legitimate approach.
But it's changing everything. And it already has an impact on me as well. We're doing things today in Big Panda. We're doing things that no more companies couldn't imagine in the past. You needed like MIT professors to do and we can provide that value and as a computer programmer, the stuff that you have available in the tool. The tools you have available in your bell. It's amazing. Next question. What's a trend you're seeing or following that's interesting
or hasn't hit the mainstream yet? So I'm not sure it hasn't hit the mainstream. But I think it hasn't matured enough. For me, the AI assisted the programming. This is something that's the door. We are obviously two others. Like the co-pilot and everything. But it's still not there. And I think the potential is huge. And I'm following it. I think as a developer, I think that the software developers of the future are going to be completely different than what we are.
They're going to be like, everybody's going to be a manager. Nobody is going to be a programmer. They're going to have those AI bots working for them. We're just at the beginning, scratching the surface of what can be done there. I'm following this technology and I'm expecting it to change significantly right now, which is more suggestive. Last question, Oded. Is there a quote or mantra that you live by or a quote that's been resonating with you right now?
I think this is something that we resonate with you as well. It's not a sprinted simarton. And I really think about that. I run marathons myself, but I look at it and everything I do in life personally and professionally. Even though some stuff like finishing this quarter is important, it's going to be an X quarter. And you have to make sure that you're ready for an X quarter.
So always think about also about the long term. I really like that quote. I really like if you can have the patience and discipline to follow your plan, you can operate better and not get stressed out about short-term stuff. Obviously, we always try to do that. We're not 100% successful, but we try. Thank you. As somebody who's late stage marathon trading, I deeply resonate with that quote. Oded, thank you so much for your time and for the conversation. Everything from, you know,
how to go deep on technology or to maintain a high level strategic view. Bridging the gap between engineering and the executive team and how to best ask questions, as deeper questions to better understand them and even how to bring the engineering perspective to make better, more effective marketing. And so thanks for sharing all of your stories with us and perspectives. We really appreciate it. Thank you. It was really fun for me to know. If you enjoyed the episode, make sure that you click
subscribe if you're listening on Apple podcasts or follow if you're listening on Spotify. And if you love the show, we also have a ton of other ways to stay involved with the engineering leadership community. To stay up to date and learn more about all of our upcoming events, our peer groups and other programs that are going on head to sfelc.com. That's sfelc.com. See you next time on the engineering leadership podcast.