A Peep into DevOps Dysfunctions, Liat Ashkenazi, SVP Engineering and GM Israel, OwnBackup

In this special episode, in partnership with DevOpsDays Tel Aviv, we are excited to host Liat Ashkenazi, SVP Engineering at OwnBackup, who will give us a sneak peek into her Keynote talk at DevOpsDays Tel Aviv, and some tips for how to prioritize developer efficiency and experience, to prevent DevOps dysfunctions.

Episode Transcript תמליל הפרק

Hebrew, then English* בעברית ואז אנגלית:

(*Translated with Google Translate - so there may be some errors.

Please also bear in mind that Hebrew is a gendered language and therefore anything that is noted in a specific gender is intended as neutral and not gender-specific.)

 (opening music)

Welcome to the second season of Dev Interrupted, the Hebrew version of Dev Interrupted, LinearB's podcast for engineering managers. Where we will host leaders in the industry and talk with them about everything that interests engineering managers, those who work with them and those who might want to manage an engineering organization some day. This season we will place a special emphasis on developer experience. I'm Yishai Beeri, CTO at LinearB, let’s get started.

(transitional music)

Yishai: In this episode I am happy to host Liat Ashkenazi SVP Engineering and GM Israel, at OwnBackup, Hi Liat,

Liat: Hello.

Yishai: What a pleasure you came.

Liat: What fun I have too.

Yishai: So we're talking about the keynote you're giving in a few weeks at DevOpsDays Tel Aviv, a big and impressive event. And we'll give a little glimpse, a little taste of what you're talking about and also a little bit of how you prepared for it, but as usual I want to start by hearing about you, about your journey, where you started and how you got to where you are today.

Liat: The beginning of my journey, back in my high school days, even let's go back a little more, because that'll tell my story even better, I didn't think about computer science at all. I wasn't the kind of geek who messes with computers and tries to find all kinds of ways to hack, and at some point I said well, I I will be a lawyer, which was at a time when hi-tech was not yet that modern, modern is not a modern word either (laughs). I said I would be a lawyer, and even at a graduation party, it was elementary and high school then, there was no middle school, a graduation party in elementary I presented, there was such a presentation and I presented that I was going to be a lawyer, etc. And at some point the situation changed in high school, when I realized that I really, really liked math and was good at it and there was an option for matriculation in computer science, I won't say in which language it would indicate how old I am, and I said 'come on, let me try it'. It was something that really was esoteric at the time, it wasn't that everyone was doing it, and I really tried it and liked it, and then after the army I said well, what do I want to study? I was very confused because once again, I was not one of those people who are always in front of the computer, etc.

Yishai: Wasn't the army already pretty high-tech? 8200 unit?

Liat: No, there wasn't that then, there wasn't that. And I said well, I want something mathematical, I don't want to start reading legal cases and to that, I said I want to change and I said I will go to the computer science track at Tel Aviv University. Then there wasn't one class, I did computer science and economics, and from here my romance with the world of software began. After that I also continued, of course at the same time as work I also continued on to a master's degree in computer science. I liked it so much I did a thesis, and the day that I finished the thesis and gave a lecture to the professors at the university there about the thesis.––I went and bought a kit, once upon a time you bought kits for an MBA degree, so I also have a long romance with Tel Aviv University, I did 3 degrees there.

Yishai: You say work, while you have already started working in the profession?

Liat: Yes, I started working professionally as a developer, it was at first C, C++, then Java and I really loved, I loved this world of software.

Yishai: Where was the first place?

Liat: Avaya, yes, that was the first company and after that I joined Mercure, later became HP, excellent place. It was also my first management school, where I actually progressed to management and it was amazing because there was really a training system for managers in all levels and there was mentorship and I really learned. I learned what it means to manage a team, after that what it means to manage a group, what it means, how It's to establish teams not only locally to establish teams abroad and really it was my amazing school for management. It gave me that boost forward, and yes, after that I advanced to different management positions in different companies. It was very interesting, each company with its own challenges. I really, really love this role, both the technological hat and the culture hat, I really like the combination of things.

Yishai: How much do you, as an SVP Engineering, get to deal with the technical side? You said you love math,

Liat: Yes.

Yishai: Today everything is just people isn't it?

Liat: Yes, it's a lot of people, but there are, there are technical aspects. Architectural decisions need to be made, I'm not in the code review stage, I'm not entering, not at the stage, not in the depth of code review, but I do make architectural decisions. Today for example there are three architects who report to me, me, we have to make decisions, and even a lot of decisions. And DevOps reports to me, and of course all the development managers that report to me, so I say that there is the technological integration here as well, not at the level of the low level, which I also miss, when I miss it I just write with my boy Python. so yes,

Yishai: Not for production.

Liat: Not for production, but I do, I also have the technical touches because I love it. Yes, but a lot of people management, mostly people.

Yishai: Ok, so that is quite a journey, starting with realizing that this is what you love, degrees, work and progress up the entire ladder, we will come back to your journey a bit later and I remind you that we are talking today in preparation for your keynote at DevOpsDays. So you, maybe tell us in a word, like the title of the keynote, what are you going to talk about? What topics?

Liat: I'm going to talk about, we called it Four Dysfunctions of DevOps Teams,

Yishai: only 4?

Liat: Only 4, but actually behind this is how devops actually supports development organizations and how important it is to the impact, on how important it is and how big of an impact it makes to the business in the end, ok? And this is expressed in development efficiency, how much engineering, with the help of devops, can reach a status that is very, very efficient, in terms of execution and also satisfied. I mean it is very, very important this ability of developers to run forward and without devops infrastructures it is impossible to do that.

(transitional music)

Yishai: So why did you choose this topic? You have a lot of experience, certainly very diverse, why specifically this area of ​​developer efficiency and how does devops support this and developer experience?

Liat: So I'll tell you a story. As a developer, let's go back 15 years or so. It frustrated me that I was wasting a lot of time on things that could have been automated or could have taken me 5 minutes instead of 2 hours. And it just hurt my productivity. And I wanted to write code, now I wanted to not only write code, I also wanted to talk to customers and I also wanted to test my code and I wanted everything but I didn't want to waste time on things like spinning up a machine, how long does it take to spin up a machine? 3 hours, okay? I have been waiting for 3 hours to have a machine. Or I'm running a build, the build is broken, okay, now go figure out why the build is broken, someone put something in there. Okay, I failed a test, now go figure out who put in what and all this adjacent work.

Yishai: It works for me.

Liat: Yes, it works exactly for me. And this whole environment just made me less effective in my role. And as I progressed in the management track, I realized that basically my job is to help my teams, to have them deliver frictionlessly, as much as possible. There is never the ideal, okay? And I'll say something else, I went through many companies, I didn't mention it, Avaya, after that Mercure which later became HP then CWT then Harmon then Imperva and now I'm at OwnBackup and each company is something different. The product is also different, completely, if it is on-prem or SaaS, the team structure is also completely different, also the stage, I mean where the company is in terms of maturity is completely different. I mean, you can't say okay, I want an efficient team, so I make a copy paste like this, copying from what I had before. No. You have to understand the company, you have to understand what is needed in engineering, so this topic of developer efficiency is a fascinating topic to me. This means taking engineering teams and bringing them to a good execution and that they will also be satisfied and not frustrated, okay? The way I felt at the time, I think it's a very, very interesting topic and that's why I chose to talk about it.

"You have to understand the company, you have to understand what is needed in engineering, so this topic of developer efficiency is a fascinating topic to me."

Yishai: And you say that in every company it looks different.

Liat: Completely different.

Yishai: I mean, it's not a school-learned solution, but there is a different structure, there are differing needs, but I want to start at the beginning, you come to a company or you are in the company, okay? There are all the things that are soft skills, but when developers say that they are stuck, there are all kinds of problems, but as you said, there is no perfect. How do I even know what my current status is? How do I measure it? How am I, do I have any way of knowing wait, where do we stand? Are we 7? Are we a 3? Are we 17?

Liat: Yes, there are ways. And in every company, you have to find the right ways according to the problems that exist at the time in the company or in the engineering teams that actually cause them to malfunction, okay? So just for example let's measure how long a build takes, let's measure how many tests we fail out of all the tests it was, false, yes?

Yishai: Flaky.

Liat: Flaky, exactly. It can be measured. Now let's analyze the metrics before we start improving so we can see our improvement. And let's see, are we good with the number Flaky? Maybe we only have two tests that fail each time, ok, no need to improve that, let's improve something else. So first of all it's observation, which means that when I enter an organization, I first look, understand, what's not good, what affects, what will significantly impact the life of a developer who wants to write code and deliver with peace of mind (laughs). So I say, I mean it's about the key experience, we'll even call it that. And this is where observation actually comes in first, it's impossible to run ahead and say I did this before, so come on, let's do it here too. No, you have to do some kind of observation and see, okay, what is true for, what is true now.

Yishai: So it's a combination of what? Measurements from systems but also ask the developers?

Liat: Also asking the developers, it's even a kind of interview like this, like having conversations like this with people even in the corridor, I mean, it doesn't have to be formal. And to hear also to measure, because many times there are feelings that they are not, now it is impossible to measure everything, okay? The question of the questions, how to measure the velocity of development. I have been asked this question so many times, it is very difficult, there is something about it, I could write a book about it. So not everything can be measured very, very precisely, but yes, you can measure how long the build takes, how long it takes the developer to spin up a machine, you can measure that, yes? He starts, he finishes, you can enter it, or you can see it in some kind of log or you can, I mean there are ways to measure. You have to try as much as possible to make decisions based on data, this is also something I'm going to talk about because it's also, it's not only what needs to be solved, it's also how we solve, data is also very, very helpful in making decisions in which direction to go.

Yishai: Yes, you talk to developers and you don't always get it, I mean sometimes the picture is where there are the most complaints, it may depend on who is complaining, depending on the character and not necessarily on

Liat: Exactly, I think it should be a combination of both, I mean not just data, not just talk, it's both. And here also comes a lot of experience, I mean there is also a dimension of experience here because I have already seen so many problems and so many cases so it helps me to understand the problems faster and focus on the areas that will probably cause a big improvement.

Yishai: Do you feel that this is a kind of professional specialization? I mean I can bring in VP Engineering to manage my department? Or I can bring a fixer to take a department or an organization that has delivery problems and fix it, which is a slightly different specialty, it's a bit,

Liat: Yeah, look, that's just one dimension of the job. And I don't think so, I mean I don't know if you can reach a situation where there is such a fixer, I think that simply part of his job to lead a large development group is to get to know it, but part of it is also to know how to keep the people and what to say to the people.

Yishai: Well, if there is a good developer experience then they will stay, right?

Liat: Not only that, how to mentor people, how to manage managers who are directors and have their independence and their opinion and you need to know how to empower the team, I mean there are so many dimensions here that I don't think that -, I mean I don't think that there is such a position that is only a fixer that comes has devops, and today I have an amazing team that knows how to suggest and propose the tools and they do see what is broken and they are of course part of, part of what I succeed in is, how I succeed is that I have the right people as well, it's not just like that . So I say there is this here, but I wouldn't call it fixer but,

Yishai: But this is another feature, another ability that a good VP Engineering should have,

Liat: They should have.

Yishai: But it's not standalone.

Liat: I don't think it's standalone, yes.

Yishai: Okay, and you talked about devops, so you are implying that at least in your case, and maybe this is your recommendation, devops sees itself as responsible for these questions of developer experience, of the flow, of not only how things get to production. Because many times devops thinks about okay, how do I bring it to production in a reliable way, how will it run there without problems, but not necessarily about how the life of the developer who wants to deliver and move on.

Liat: Right, so you touched on an important point here, it's also very important to think about the CI and not just the CD. Because the CI has a very, very significant influence on our ability to deliver and deliver well, with high quality. Because if we only think about the CD then where will we catch all the bugs? In production. And our delivery will be slower of course, yes? So it's an impact of velocity and quality. So yes, you really need to think about the CI as well and not just the CD, so devops yes, from its role, I will soon tell if we have time to touch on it what I did in OwnBackup, and in every company it is a little different, but yes, it is very It is very important to also look at the development process and not just the production.

Yishai: So an area that is starting a bit today, a buzzword that is starting to gain momentum is Platform Engineering, how do you see it connecting with the devops? Is it the same? Is it an extension?

Liat: Totally related, very connected, platform engineering connects exactly to the CI that I was talking about, how as a development organization do we make sure that we have the right infrastructures so that we can deliver smoothly, okay?

Yishai: Okay, so you put it in the box like that, in the CI drawer? But they sometimes talk here about things like how do I even know who is responsible for service, where is the documentation, who will do a review for me, these are things that are even before the CI, they really are, I write code and I need to find people to find knowledge, this is also part of -platform, no?

Liat: Yes, for me it's the whole process of the SDLC, I mean I call it CI but it's possible, I mean everyone with their own terminology, for me it's from the first moment we have some kind of requirement to develop a feature, how do we make it go through smoothly or efficiently, until production. And it's not only efficient, it's also high quality, okay? So for me it's one to one, we need,

Yishai: Everything is under the devops people, at least organizationally it is their responsibility.

Liat: Or, but here it is also an issue, it depends on the organization. Not necessarily, I think that developers should have a lot of knowledge of devops today, and not only today, yes? But a developer shouldn't have to just have OK, I write code, someone else will check for me, someone else will take care of the infrastructure, someone else... no. I strongly believe that these capabilities are also needed within the development, but yes, the devops people, I do think that an organization needs devops people and once again, it depends on which organization and how we build it, also this, I'm going to talk about this in the session , at DevOpsDays, it really matters, it really matters where you put the devops people, how many devops people, what the developers are,

Yishai: Is it even a separate department or are they scattered in development.

Liat: What is the communication, exactly, what, how are we, how are the work processes from the devops people to the developers, from the developers, what do the devops do, once again, not one to one written, but that's how responsibility is in general, so it's an issue like that for me itself but I can tell you what I did in OwnBackup. What was in OwnBackup was that there was devops who were responsible for everything, also for the CI, also for the CD, also for the platform engineering, no matter what you call it, all the concepts were responsible for everything. Actually, they were in charge of production, okay? Because they were responsible for both the CD and the CI, so what actually happened? When they are in charge of the production what attracts most of their attention? the production,

Yishai: So they also did some kind of SRE?

Liat: Yes, and what is left for CI? Nothing, there is no time left, not because they are not good people, just because they have no time left because there is no way around it, there are fires burning, customers. Production is more important than anything and the CI is, it wasn't good, I mean it wasn't, as I said at the beginning the frustration of the, that I felt when I was developing, was the same with the developers at OwnBackup because really the build took a long time, things broke. The infrastructure of the CI was not good. So what I did was I recruited devops people to give their attention to CI because at the time that was what was required.

Yishai: And were they were earmarked for this? as if their time is wasted,

Liat: Hypocrites, total hypocrites, separate team there,

Yishai: who did not report to that team.

Liat: That he didn't report to that team, that they're in charge of CI, concentrating on CI, concentrating on raising automated environments for developers, concentrating on that. Now, once again I return to the coffee feast we talked about. Is this true for every organization? No. This was true for OwnBackup at the time I joined, and it is also true now, will it be true for OwnBackup in another year? Maybe not, maybe we'll make a change, I say but at that moment, I mean it was a place to give it the attention because OwnBackup is a company that grew very, very fast, fast growth, doubled itself every year, but the infrastructure was still like a startup Up of 10 people, okay? That we are a start-up today of 800 people, 150 people in development in my group. It is impossible to continue working in the same way. And so I had to give it the focus, I still think it should be given the focus, on the platform engineering, CI, whatever we call it, so that we really have the infrastructure, we put in the right infrastructure, and we really showed a very, very great success.

Yishai: How long does it take? Did you recruit a team and say voila, I see success?

Liat: Well, so first of all I recruited people I already knew were good because I knew them before. (laughing) And I really succeeded,

Yishai: Our network is part of our assets, isn't it?

Liat: So they brought value very, very quickly. And let's say let's take a given example, did we talk about data? So when I joined I started measuring how long the build takes, okay? Not me personally, but my people started measuring, and it took 3 hours. Today we are on half an hour,

Yishai: So every pull request, every change in the code I make, 3 hours to test it in an environment that is not local,

Liat: In an environment that is local, yes, no, that is not local but that the build is running and environment, yes,

Yishai: 3 hours, ok, a lot of coffee.

Liat: A lot of coffee and a lot of frustration, why? Because the build isn't stable either, okay? He had,

Yishai: It will fail after two and a half hours.

Liat: Exactly, exactly a minute before it ends. So yeah, so, and then there were around 50% failures and three hours of running time. And this is in addition to the fact that the environment of the tests was not automatically built from scratch, so there is another dimension here. And we reached half an hour of Bild with a flaky test that is close to zero. And no, it's important to say, we didn't just disable tests, that's when they're not flaky, no, we fixed them, and today, developers automatically set up a development environment very, very quickly, which used to take a lot of time and not only development environments, staging environments as well which is more complex and large environments. So we improve and I always strongly believe, my management philosophy is continuous improvement, you can't do everything at once, you improve in steps, you always have to think for a moment, what is the next improvement? As if the next improvement I might have thought of 3 months ago is different today, maybe I need to do something different so I need to constantly think about what I want to improve this time.

Yishai: So I want to challenge you for a moment, there is a success story here that you have greatly shortened the build process, I have no doubt that the developers are more than disappointed, but in the end you are serving the business, right? And you want the engineering to be aligned with what the business needs and for the CEO, in such a placeholder, someone who is not in engineering does not care about the continuation of the build, so how do you show that there is an improvement here that contributes to the business? As if it allows you to give more to the business?

Liat: So first of all, it was very easy to measure it. Because if you calculate, and by the way I have a slide like this - it's beautiful - that I showed to the CEO, then you touched on the point, because it's easy to calculate, you see 3 hours for a build versus half an hour for a build, you see 50% success versus 99% success, and then you Calculate how much does a developer cost per month? How much time did the developer spend in his month, how many dollars, translating to dollars is very, very simple, really, because,

Yishai: The wasted time is my ROI.

Liat: Totally, totally.

Yishai: And do you also have a way to show here, here the output has increased?

Liat: Obviously.

Yishai: So I diverted all those dollars to work,

Liat: No, look, it's output, it's,

Yishai: It is difficult.

Liat: As I said, it is very difficult to measure exactly exactly how many developers, what is the velocity of developers, simply, per day or week or month, yes? But yes you see idle time or waiting time of a developer or waste time or whatever you call it. And you can measure it approximately, you say well, listen, out of those 3 hours, the order, it's not that he didn't work for 3 hours, but let's say that he had idle and context switching for about an hour,

Yishai: They had a context switch, sure.

Liat: True, and from the fact that they waited for the machine, they waited or tried to spin up a machine for 3 hours because they spin them up manually and not automatically, how long did it take them, two hours, okay. So you are calculating some kind of calculation here, so wait, is it possible, and we do commits all the time, I mean this is a company that we constantly have frequent deployments. So is it possible that we saved an hour of developer time a day here? Let's calculate how much an hour of a developer costs per day?

Yishai: Much.

Liat: exactly.

Yishai: And there are many developers.

Liat: So it is possible to make such a calculation and when I showed it to people in the business, even to our CRO, I mean they understood what it was about, because once you translate it into dollars it is easy to understand.

Yishai: So for them it is an investment that has paid for itself and it is possible to perhaps put another investment in the same area, to continue investing in improvements in this area. So from a success story, I want you to choose for me a story of a change that didn't work out and it doesn't matter which company, but a change where you identified a problem and tried to change it and something there didn't work.

Liat: Yes. then we can

Yishai: Or everything works out.

Liat: There is no such thing as everything succeeding, whoever does makes mistakes (laughing)

Yishai: So let's hear.

Liat: Okay, I'll give an example of something that didn't work. Basically, those who come to make a change think about the change, think about its shortcomings, what its advantages are, and every change is also related to people. And that should be remembered and I forgot. it was in

Yishai: And all people love change very much.

Liat: exactly. And organizational structure also influences, very much influences the way of working and the ability to reach results that suit the organization at that moment. And I decided to make an organizational change in which I put more people into the teams, that there will be more heterogeneous teams and that the developers will also do things that are not just writing code. Say writing tests, devops, all that. And there was a very, very big opposition from the developers, it wasn't in OwnBackup, from the developers for this change, and I didn't take that into account.

Yishai: They didn't want to mess with things that were outside the box of the code?

Liat: No, they didn't want to. And as much as I tried to make them buy-in for it, maybe not enough, maybe I didn't try enough, maybe I should have tried more, it was very difficult to assimilate, this change because there was a very, very big resistance to change. It's not a resistance now, is it? A demonstration is a resistance of…

Yishai: Rebellion.

Liat: Not of rebellion, but simply not wanting,

Yishai: Not moving.

Liat: Like yes? It's not not shouting, it just doesn't move. And for me it was a failure because I was trying to bring about a change that actually the people were not yet so ripe for it. So, I mean, in this whole aspect of changes, you also have to take into account that there are people here (laughs).

Yishai: Walla.

Liat: And you need to think and give them more buy-in, or say okay, right now the organization is not ready for that, let's do something a little different, okay?

Yishai: Adapt the solution to the people.

Liat: Adapt the solution to the people. I adapted the solution to the organization, I adapted it less to the people, and have learned from mistakes.

(transitional music)

Yishai: So we talked about successes, we talked a little about how we fail. Tell me something you thought about this topic of engineering efficiency, of developer experience, something you believed in 5 years ago and stopped believing in today.

Liat: I didn't think it was interesting to the business. And I couldn't believe how interesting it was for the business. And we talked about how the CEO, there is absolutely an interest of the business in this matter because the business today understands more, and I'm not talking only about the business in OwnBackup, I think that the business in OwnBackup is amazing, because there really is an understanding of the matter, but not only in OwnBackup, they are beginning to understand how much this actually ultimately affects the company's ability to deliver what it needs to its customers and to the field. So today there is much more understanding of how important development infrastructures are, compared to the past when it was less, there was less of this understanding. And What surprised me, I mean, as much as I am in my current position, it really surprised me that there is an understanding of the business to,

Yishai: Has your understanding changed? Or is business in general really moving a little more to look at these questions, to be interested in it, to understand that it is significant?

Liat: Look, I think it's both. My ability today to talk about the business and explain things is also better, there's nothing to be done, it comes with experience. But I think that also, as time goes by, we realize how important automation is, how important it is tech-, like if we talk about AI then it's like this, I'll get into that too, I mean there's more of a deep understanding of business, yes, it's important how you do the the things And not only come on, come on, come on, come on, come on, come on, okay? I mean there is a need, and there is also more understanding, of how important it is to bring in a development manager who knows how to do these things, to bring development organizations to excellence. Which is something I really like to do, how important it is to bring in such a development manager and not just a development manager who knows how to do a code review. I mean you understand, I think there is more understanding in business, once again, in the industry in general, which is important.

Yishai: that it's a profession, that it's important,

Liat: That it is important, that automation is an important thing, that it is important to invest in it. There was less of this understanding in the past. Come on, write code, do manual tests, whatever the process is, deliver it quickly, and I think that-,

Yishai: And this understanding you see translates into more openness to the good, you need to make non-functional investments,

Liat: Right.

Yishai: We have to wait a moment with deliveries because I'm building something here that will later produce a higher velocity, but do we need to take a hit sooner?

Liat: Completely. I really feel that there is more and more understanding of the business, how to invest in a more correct architecture, invest in infrastructure, really. It's noticeable and it's something that surprised me because 5 years ago it was a little different.

Yishai: Do you think this is something, some kind of process that Israeli companies have gone through? or you see,

Liat: No, I don't think it's specifically about Israeli companies. I think that in general in the software world there is a deeper understanding of development processes. Up to the level of CEOs, they understand that automation is needed for things, they understand that in order to run regressions, you can't run regressions manually because then you put the whole development on running regressions, as if just for example, okay? It's an understanding that more and more this is how software enters the business world And not only in development managers.

Yishai: It's interesting from our side, at LinearB we really see a significant shift in how companies, managements think about this world of efficiency. looking for tooling, it is starting to be something that has a budget, that has attention from the CEO level and below. So we experience it a little more as the maturity of the market we are in, but I very much agree with you that once upon a time the CEO mainly looked at the numbers of sales and it was important for him to understand the mechanics inside. Now it is important for the CEO to understand the mechanics of the development process as well. Because in the end this is the biggest result of the company and most companies are software companies, so if you don't understand this, you will be left behind.

Liat: exactly. And you need a development manager who also knew how to explain it to him well, really, because it's very difficult to understand in a field you don't know that much about.

Yishai: And it's different languages, the translation from,

Liat: So you need to know how to translate.

(transitional music)

Yishai: So if we go back to your talk, which is coming soon at devopsdays, and we talked about successes, we talked about failures, we talked a little about changes in the perception of developments. Give us one more interesting point, like a sneak peek into something you're going to talk about, that we may not have thought about until today or that may be a little surprising to those who are not in this field every day.

Liat: I think the surprise is how to think about all the parameters together. I mean, sometimes we only look at the good, the pipeline is broken, let's fix it. Sometimes you only look well, let's recruit more people here and there. I think that the combination of the more holistic or more high level view is something that I will touch on in the lecture of which people I need to recruit, where do I put the people, what is the structure, how is the communication, what is the communication between the development and devops people, how do I identify, how Do I make data driven decisions? How do I identify what I need, how do I actually build my CI? Or whatever we call it correctly, I mean the combination between these things, I think that's what brings the more overall success, and not one point success.

Yishai: You say it's not some swag and we ended up in one place,

Liat: exactly.

Yishai: There is a process and you have to look from above.

Liat: You have to look at things holistically and make a decision first of all at a high level and then break it down into details, once again, I don't think everything should be done, it is possible or should or should be done at once, but yes to look at the totality of things. And yes, I think this is something I will talk about that will be interesting.

(transitional music)

Yishai: Towards the end of the question that cannot be avoided, AI, LLMs, GenerativeAI, how do you think it affects, if you see it already affecting or how it will affect in the coming years these questions of developer experience, how I delve, efficiency of teams.

Liat: As we already understood before, I like to make the developer's life easy and efficient. And so I am very excited about what is going to happen and what is already starting to happen around this world of AI automation, I think it will bring us to a much better place. Because the developer, the development people, in general, the developer, the QA, the devops will deal with innovation and everything else will be done automatically by itself. The things that don't need to be done manually or automatically but that need to be planned in advance. I think it will bring us to a better situation, more efficient, truer to us and we will really have the things we are left with, which requires a lot of thinking around them, not everything is possible.

Yishai: So do you see a future where the developers mainly give instructions to the machines that write the code and connect the things and test?

Liat: Completely. Not long ago we had the hackathon, we did the hackathon at OwnBackup, it was a week or two ago and they brought amazing ideas there. This also means how to make the lives of the developers better, also how to make the lives of our customers better through all kinds of tools that through the UI access all kinds of AI options that help them to navigate. So I really think that, I am very excited about this field.

Yishai: What does this mean for the Juniors World Governor? If now the developer only or mainly needs to do the activation of the tools, but not to write most of the lines of code, then what, does this change the career path of a developer? Or what does it mean to be a junior developer who is not polished enough yet?

Liat: So a junior developer still has to design a feature how we want to do it, the junior developer designs a smaller feature than someone who designs a larger feature or a whole system, yes? And there will still be room here to think about innovations, how do we insert code here that is a little more complicated. I mean, not everything is black work we call it, right? There are many things that juniors can do even without much experience, that's fine, we still have small features, we still have things that need thought behind them and yes, and configuring the tools to do it for us, okay? And if it's even just for configuring a tool in such a way that it will pick up an environment for us or run a certain set of tests for us according to exactly where we touched, in my opinion it will make our lives easier and more efficient.

Yishai: Excellent, so in conclusion, one piece of advice if you want to give a manager, a development manager who wants to start touching this world of how to improve the process, the productivity, the joy of the developers. Surely we all feel that something is broken, something is stuttering, how to start, how to take the first step for those who have not touched it in an orderly manner.

Liat: The first step is really observation. That means looking, collecting data, interviewing, kind of interviewing people, the developers themselves. And that's the first piece of advice. Don't run, say wait, I've done this before, come on come on, let's do it here too. This is not true, as I said from the failure story I told to also see what people are ready for, what kind of change people are ready for, so really this whole thing is observation, this is the first step.

Yishai: So look and have some patience.

Liat: A little patience, to look, and after doing some kind of analysis, once again, it shouldn't take months, yes? But some kind of observation, to collect data and then make the decision what is the first step? It's impossible to do everything, this is true in general for improvement, it's not only related to devops, in general, in all the changes I've made, think for a moment, what's the first step? After that, what's the next step, okay? Don't go and build a plan for the year ahead, we are agile, the world changes all the time, okay? What is the first thing I want, what is the second thing I want to do and move forward from here.

Yishai: Excellent. Liat, thank you very much for coming.

Liat: you are welcome. I had fun.

Yishai: As above, we are waiting for your keynote at devopsdays Israel and maybe we will also chat a bit afterwards. So good luck.

Liat: Thank you.

Yishai: See you soon.

Liat: Thanks.

(transitional music)

Visit devInterrupted.com to subscribe, you can also find all our episodes in English there. I remind you that we at LinearB are growing rapidly, recruiting for a variety of positions in all fields. Come to linearb.io/careers to find your next challenge. I'm Yishai Beeri, we'll hear from you in the next episode.

(closing music)

Links to the nifty tools and resources mentioned in the episode:

• DevOpsDays Tel Aviv
• OwnBackup
• Avaya
• CWT
• HP