IC to Leader and Back: Swinging on the Pendulum, Anna Bankirer AIDoc, Eitan Yanovsky, Optibus

Episode Transcript תמליל הפרק

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

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

Yishai:         Welcome to Season 2 of Dev Interrupted - the Hebrew Edition, LinearB's podcast which discusses everything that interests the daily work of engineering managers. This season we will host industry leaders and talk with them about everything that interests engineering managers, those who work with them, and those who one day would like to manage an engineering organization. This season we will place 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 Anna Bankirer, senior engineer in the CTO team at "AIdoc" Hi Anna.

Anna: Hey.

Yishai: What's new? And Eitan Yanovsky, co-founder and CTO at Optibus, Hi Eitan.

Eitan: Hello, welcome.

Yishai: How fun to have you here. As usual, I will start by asking, everyone to tell me about his or her path, how you got to this point, and then we will dive into our topic today, which talks about the transitions between management positions, senior positions, to individual contributor, etc. So Eitan, tell me about your path, how your career has been going until today.

Eitan: I studied mathematics, computer science, and at the end of my degree I started working at "Gigaspaces", where I met Anna. She liked me a little less when she first met me, but that changed over time. I actually arrived there as the first developer, it was a job after university. I also worked as a student but in a different place, and over time I actually advanced to become a team leader, I actually replaced Anna, Anna was my team leader, and she became an engineering manager,

Anna: You’re stealing my whole intro, please.

Yishai: Your intros are connected, that's fine.

Eitan: Yes, it's not by chance that we're both here. I was actually there for quite a long time, 7 years, and in the process, already with the university and already in the evenings and on weekends, I worked on the company that I actually founded called "Optibus", which is actually developing a platform for the management, planning and operation of public transportation, of mass transportation in fact, millions of people every day. A problem that started as an algorithmic challenge, that's how it also started in the university, mathematics, computer science, games with "Console Application" and algorithmics, but we saw that there is interest in the world and in Israel in particular to solve this problem of public transportation–which is very outdated and operates in a very inefficient way, we were surprised to discover. Without much outbound marketing, they came to us in Israel, heard about some magic project we were working on, and asked to use it, to help them with the tenders because Israel has become a much more privatized country in terms of public transportation. In fact, in 2014 my partner and I, who both studied mathematics and computer science together at university, exactly the same track––we decided it was time to leave our current positions, take a risk and really start a company. And we actually started the company in March 2014, we started with few people of course, we were less than 20 people in the first 3 years. At that time I was still mainly in the position of "hands-on product", buying milk that is not in the refrigerator, what is needed, and somehow after Round A, in 2017, when we actually brought in significant money and started to grow and grow from 20 to 40, then 60, 80 and 100 . The position of the CEO, I was the CTO and VP R&D at the same time, but very quickly I actually brought in, I said that it was necessary to bring in a VP R&D, as it is less my forte to manage the organization on a process and personal level of the people, of taking great care of the personal development or things like that. I come more from the technological perspective and the technological management, and how to make the organization work. And I felt that I needed help in this area. And in fact I officially took over the role of CTO, and today we are 400 people with an R&D / Product organization of over 100 people. This is very briefly.

Yishai: Wow, quite a journey. So Anna, come tell us about your path.

Anna: Hi, so it's nice to be here first of all and meet Eitan, we haven't met in a long time. So I started already before, well, it doesn't matter, the time in the army, where I started messing with programming seriously, before that it was more like a hobby, in school, Basic class, etc. I studied at Tel Aviv University, while working like that and the place I really worked with for a long time, close to 9 years in my opinion, is "GigaSpaces", together with Eitan. Contrary to what he says, I loved him from the beginning, and we really worked together for quite a few years, until he came and said that he wanted to try his luck in some small startup. Maybe he would succeed, maybe he wouldn't, and from there it’s already a company of 400 people. My background has always been more in the "backend" areas, distributed systems, databases, bot optimization, things like that, through management. Well, we'll talk about it later, but I kind of rolled in half by chance and really managed there, at first I developed, after that I managed a team and in the last position I was VP R&D of close to 30 people,

Yishai: Random, random, random, up to the VP R&D.

Anna: Yes (laughs) and then I was really debating what to do and where to go next, and more than 5 years ago I started at a startup. I was always drawn to the medical field. And exactly at that time, something like 5 years ago, it started to gain momentum in Israel, there were more and more Startups and there was a small and promising startup called "AIDoc" that really fascinated me, with talented and nice people, that I joined as a developer, I actually came back from a position that -, after many years I just managed and didn't touch the code, I went back to developing, and more in Python, God forbid,

Yishai: After years of Java.

Anna: Yes. So instead of making fun of Python I went back to making fun of Java, so everything is fine, and that's it, since I've been there, I've also moved through many positions there. As I said in the last position I came back, I basically closed a circle and went back to engineering. I didn't tell you a bit about "AIDoc", but in the medical field, what we do is actually we analyze live different types of medical data, analyze and identify any anomalies, any findings that could be life-threatening or that require immediate treatment, and warn about it on various platforms. But basically make sure that the right person receives this notification. This means that not only will we find out, but they will actually receive an alert about it and take care of the person, whether it is examples of the products we are developing and the detection of brain hemorrhages, pulmonary embolism, neck fractures, aneurysms and more. There are plenty, we already have over 13 FDA approvals, I think we may have already passed that.

Yishai: When the basis is an analysis of imagery and,

Anna: So all kinds, we started from this world of imaging and slowly we are expanding to other types of data as well, also to textual things and medical tests and more and more indicators, to give some kind of solution that is more comprehensive.

Yishai: I hear here that you are in two industries that are highly regulated, both the world of medicine and the world of transportation. We will touch on that later. So Anna, I'm interested in asking you, you were VP R&D in a startup that grew a bit, then your next role was that of a developer. A little bit about this transition and why you chose to go back to engineering, not continue in management positions.

Anna: Yes, a good question and I really debated a lot, I also really took a break, it worked out for me with the maternity leave so that's how I extended it. Because I was really debating, okay, if I continue on this path of management or if I return to something more technical and professional. And the truth is that in the end what tipped the scales was the place I wanted to go to, because I realized that in the end I would enjoy both this type of role and this type of role, and simply in "AIDoc" I connected the most with the stage where the startup was at, which is like this at the very beginning and an opportunity to be part of building something from scratch, which is also something I rarely had the chance to do before this. And in the change of role itself, of course there was a period of this kind of planning to go back and write code, the product was also very different, after all I got more used to the field of "middleware" and here it is really an end product, it is also a new field, so there were many changes.

Yishai: Did you feel that there was, I don't know, around your recruitment process, did it present some sort of challenge or question mark? Like as a recruiter, why does someone who is a senior manager even return or want to return to coding? It can be a bonus, it can also be a momentary question mark, is it really the right decision? Will this recruitment work for me here?

Anna: So it's a good question, I felt it was more of an advantage, I mean it obviously came up in every interview and I was asked what and why and I had to explain,

Yishai: "Overqualified".

Anna: (Laughs) So it kept coming up, but I felt it was more of a plus, because it also gives more horizons, especially in a startup where you don't yet know exactly what role you will need and what people you will need, so there is actually more of an advantage with someone who can also manage in the future.

Yishai: Do you think they say maybe we can build on her as a manager in the future.

Anna: Yes Yes.

Yishai: Was there such pressure afterwards? Or did they try to

Anna: No, not really. There was quite a long period of time that I was in engineering, it was about two, three years, and then I also reached a limit with coding after a while longer, and I was looking for even more of a challenge and an opportunity arose within the company, so it worked out.

Yishai: So there, too, you advanced to management positions and then returned to development.

Anna: Right. After a few years I managed, I actually established a data engineering team that also grew into a group relatively quickly, in order to respond to all the data challenges that grew with the organization, and then we realized okay, this whole field of data and data infrastructure is not getting enough attention and is spread among all kinds of teams, so really I established a team that provides an answer to this. So then I also got a little more into the field of data engineering, which although I was always around it, I didn't really get into it deeply, so it was also interesting, and that's it, and after a while I wanted to come back again.

Yishai: Back to working with your hands.

Anna: Yes.

Yishai: Eitan, you went through the route, maybe a little more classic, of starting as a developer, developing, then continuing to go into entrepreneurship and management and you also put your finger on this point which is the truth quite common, that an entrepreneur, CTO, says I don't want to deal with the ongoing management of the development , I want to bring in someone who is his passion and move a little or go in a different direction. So first of all a question, are you still managing the development? I mean you, let's say VP Engineering reports to you? Or are you completely out of the loop?

Eitan: Yes, so the VP R&D reports to me, basically the development organization under me, a few more specific functions a bit like the CISO reports to me and a few other things.

Yishai: Okay, and tell me a little bit about this process, about the transition from you holding everything, managing everything, knowing more or less every line of code where it is and what it does and why, to the one where you bring in an expert.

Eitan: So first of all, in my nature I don't really disconnect or distance myself from what is happening in the field, in lines of code, I am still an individual contributor even in our situation. It's true that I don't take tasks from misprints or things like that, but I look for all kinds of things that are not in the critical path that will help our productivity in the organization or company, and actually try to get into things that no one else is really planning to do or even thought about.

Yishai: Is it more in the worlds of infrastructure and enablement or actually in the product?

Eitan: No, it's both in the product and infrastructure, both. For example, I wrote an open source that we use to type what happens in production, so that we can improve our recovery capabilities and regressions and things that are so infrastructural, we'll call it that. And actually then I'm still very much in the day to day, mainly in algorithmics, the area I'm in, actually that's where we started and where I feel I can contribute a lot, I'm actually kind of the product of algorithmics. But it's true, I don't manage the R&D, there are, I can't even tell you how many teams, there are probably about 15 teams, and how the hauling machine works and processes, but I'm ultimately very involved in what happens there. I generally think that this is something that is highly recommended for managers, it is to be able to understand very well what is happening there on a technical and technological level and it simply creates conversations and trust with people who have to perform the task, you can really talk to them about the details and to challenge them or they will explain to you why it doesn't work or all kinds of things. And less in the conversation about how long it will take you to do it, I think it will take less time or these kinds of conversations that can happen if there is a manager who is not so familiar with the details.

"This is something that is highly recommended for managers, to be able to understand very well what is happening on the technical and technological level - it simply creates conversations and trust."

Yishai: Yes, I think this trust is important, on the other hand if you, when there is a very senior manager who occasionally touches the code but is never in the sprint or critical path, it can also create noise, now there may be developers who will say well, I need Respond quickly and support these processes, even though they cause us some disruption. How do you do it without creating friction, or without creating voila, it's your pet project but it's not sure that it helps the team meet its goals.

Eitan: A thousand times yes, there were all kinds of stories like Eitan has now done something and we need to fix it, but half in jest and half in earnest. In practice, you have to work with the same methodologies and the same methods that everyone works, you don't just put things in, push to development. I have the same permissions and have to go through pull requests and reviews and everything is the same. I even downgraded all admin permissions or all kinds of things like that - that I don't even need in order to do my job, both in terms of security, well mainly in terms of security. But I simply don't need them, so you have to know how to respect the boundaries like everyone else and not bypass the normal processes, and also, not choose projects that really interfere. That is, if I do something that is on my side then it doesn't interfere with anyone in our day to day because So he starts refactoring the system's code or something like that.

Yishai: Anna, as someone who managed teams, managed a development organization and now you are again in the role of engineer, does this give you a better understanding of your managers? As if this background allows you to be a better engineer in the team? How do you rely on this experience? How does it change you?

Anna: Sure, I do think it helps, mainly I have much more empathy and patience towards managers. And if there are, let's say developers, many times there is some kind of decision that they may not understand or not exactly, or their priorities are changed and it really upsets them, I'm really not excited about it. And I also understand that there are constraints and as long as there is trust, I mean of course there must be, so I give much more credit to my managers, that doesn't mean that -,

"I do think it helps, mainly I have much more empathy and patience towards managers."

Yishai: You understand the challenges that are,

Anna: Yes, of course it's also, it doesn't mean I'm less critical, about my managers. But everything is in a good spirit and everything with the understanding that there are constraints and we don't live in a world that is utopian, and as long as we work for the same goal then it is also possible to be flexible in things that you may not agree with in every decision. So yes, a little less arrogant that I know everything, I mean it actually teaches a little modesty this transition between roles, that always from one place you don't see the other side sometimes, so it's true both ways, even the managers sometimes aren't attentive enough,

Yishai: Yes, they forgot what it's like to be a developer.

Anna: Yes, and vice versa, so I don't forget. So from that point of view I think it helps, you understand that every coin has another side.

Yishai: And when you think ahead then you say to yourself this is my sweet spot, I want to continue being an individual contributor or rather someday I want to return to senior management or do both?

Anna: I think that in the last job change I realized that it just won't be anymore, I won't have a linear career like I thought it would be. I mean, it's not that I'll only develop in a professional technical field or only be a senior manager, but it will probably be somewhere on the spectrum, on the continuum. And actually when the dime dropped for me was when I realized that it's also less important to me. I love, enjoy both such a position and, I mean both from a managerial position and from a technical position. And in the end what matters is how much I enjoy working, how much the place is a place where I believe in what it does, how much I enjoy working with the people, how significant a contribution and the impact I make is, so in the end that's what matters, in every role you can find this combination.

Yishai: But there is a very large range of skills and abilities here. VP Engineering needs to know how to manage people, in the end it's kind of stupid, there are many people skills that an engineer or individual contributor, especially the senior ones, is less required for it, and in many cases less likes it, I don't want to deal with managing people and thinking about their problems, I I prefer to think about the problems in the code, in the architecture, and if you only do one of them and you have the skills and passion for both, then the question is if you feel you are lacking? Today I want to help people grow, I also want to help them create careers? Or I'm willing to do it but it depends on what interests me.

Anna: This of course means that I won't be, naturally, I won't be at any edge probably. I mean I won't be a VP R&D in a big company, and I won't be some kind of super uber-architect either, so I guess I've come to terms with that and it suits me, because I'm not either. I feel like I'm at these two extremes in terms of passion, and I actually thought that my sweet spot is right in between and I can bring a lot of value specifically in, I mean yes I can manage but let's say in a startup when it's at the beginning, which is not many people. In terms of responsibilities, these are things I like, like understanding the business and understanding how things work and developing people and building teams, things I like, but not on the scale of a huge company.

Yishai: You say you need to always have enough of both the technical aspects and the people,

Anna: True, and also that people will be willing to give me the opportunities to do it.

Yishai: Eitan, when you think about, it's like you took the step of letting the VP Engineering manage the day-to-day but you are still the organizational owner of the development. Do you sometimes think or long to be like Mitchell Hashimoto, to go back to being an IC who only does algorithms and code and does not deal with managing people or with ministerial responsibility for things. If after an IPO or after an exit or if they've grown enough, you can say voila, I'm not, the CTO can be a visionary, because he has zero responsibility, but a lot of power, a lot of time and a wide field to deal with technology.

Eitan: So no, because I think that even when I was a junior developer, let's call it in quotation marks, at GigaSpaces, I knew how to be very dominant and push and influence people, for example, who are sitting next to me about what I think should be done and push it upwards. So I've never been someone like that, give me a task, I'll sit aside and I'll do it, I also don't think you're any less of an entrepreneur if that's your comfort zone, you have to be lukewarm.

Yishai: I mean, it can be lukewarm, I have an idea, I want to start a project, but I do it with my hands and I am not responsible for the financial side, for the people, not even for the feasibility in the market, I am a technologist, a visionary.

Eitan: Look, one of the things that I think you develop, without a choice, as an entrepreneur, is attention deficit disorder that makes you able to do a lot of things at the same time.

Yishai: and enjoy it.

Eitan: Yes. Respond to fill things and in the process promote many things. Today, for that matter, it's hard for me to sit down and just concentrate for a few days on coding, sometimes I, let's say when I'm working on a project like this and I say I have to do it, I really lock myself times in the diary, but it's hard for me. Because people contact me with questions and I feel the desire to answer. It's not like I turn around and say stop harassing me. You want to make the organization successful, you know you unblock a lot of things, and if I don't answer the question, the person can spend two weeks now trying to figure it out on his own. For example, if I'm sick, then I still tend to answer questions because I know that it's just me, for the benefit of the organization, I'll give an answer here now - because if I don't answer this question then he will have to look for this solution alone and can now waste half a month, a month or maybe even more for him to find the answer. So you're just constantly doing a lot of context switching, so it's hard for me to go back, even when I left Gigaspaces and actually came back at the beginning of the establishment of the, quite a key, it's not like there's a lot of customers and a lot of business to deal with. At the beginning you are quite a developer and focused on it, I had a bit of a hard time because even at GigaSpaces, already when you are a team leader and all day long support calls and people I have to deal with and I managed two products, so you are already a little distant from being focused on solving some task now. But pretty quickly I got back to it but now I'm very, very far from it, people also ask me how you manage to answer our questions and do things. Simply because you have to do it. Your brain develops this ability to jump between many things, to give that drop of value everywhere, the minimum required to promote it.

Yishai: Then you will be a ping-pong champion. In returning serves.

Eitan: The truth is that I know how to play ping-pong since before, but yes. Although there are better than me in the office, unfortunately, but.

Yishai: Work on it

(transitional music)

Yishai: So, as we said, you both work in industries that on the one hand still have a lot to enjoy from technology and algorithms, on the other hand a lot of regulation, sometimes outdated industries, industries that find it difficult to take the newest things and most see the new technological solutions or there is a much more complex process of introducing the It's all the way. Where does it meet you, also on the side of an individual contributor engineer who works on code that eventually has to enter some kind of medical process or later a manager of a company that sells to an area that is a bit outdated and maybe also regulated in ways that we don't always recognize as a B2B SaaS startup. So Anna, tell me How does it meet you as a developer.

Anna: Yes, so you did say that accurately, the field of medical is a field that is very much affected by regulation and restrictions and also considerable conservatism on the part of the customers. I actually feel that most of the challenges were relative at the beginning, today of course there are, but today we also know a lot more and already how the system works and where to put the emphasis and of course there are many processes already as part of the development, which is relatively already, at least for the developers, it is relatively I won't say seamless , but it is relatively much simpler, at first it was more challenging. The main directions of the regulation is, of course, the FDA, which has to approve everything we release and every algorithm, we can't just sell a new algorithm we developed, everything has to pass approvals of both effectiveness and safety at the FDA. And it was also a bit of a challenge in the beginning because it's something new, AI, to introduce an algorithm at all in the field of the FDA is something that was relatively new a few years ago. Also in the field of compliance and security, there are many things that need to be done, standards that need to be met because we are dealing with information that is very sensitive, medical information is one of the most sensitive if not felt that it exists. So this also of course affects the development processes. I mean if you are, you can't just do whatever you want and even in terms of architecture you need it to match the data for example. The data we work on is in a hospital, you can't take it out just like that, or sometimes at all. So this is something that is also needed, every data that goes out for example us, as if in terms of architecture for example, the data, the system is built from two parts, one part will always be on-prem and one part will be outside, for faster processing. So everything that goes from on-perm out of the hospital must go through heavy normalization and take out only the information that can be taken out and is required to run the algorithm on it. So let's say one thing. Also the whole issue of debugging and debugging, from the very beginning we did it in a relatively good way so that we could debug, because otherwise you often don't have access to the sources of the information, so this was also a serious part of the development process.

Yishai: You describe here components you built to enable working with a hospital, working on-prem to bring some of the data out but in a secure way, but where does it meet, I am now an engineer, I want to make a change in the code, raise a PR, where does it meet me these limitations? Okay, we've built an infrastructure, but now I'm making a small change, whether it's an algorithm, whether it's in the UI, whether it's in the notification, what do I need to do differently because we're in this complex set-up or because I have FDA in the background?

Anna: So developers relatively do not have too many restrictions, given the infrastructure, I think there are many restrictions specifically in the area of ​​algorithm development. Because really there, as I said, every development needs, that is, on a daily basis, it doesn't have that much of an impact, but in version releases, yes, when you want to bring something to production, you must have it after all the approvals are in place and it has been checked and approved.

Yishai: So in the stream of developers working we will call it normal, but they know that after the version is closed there is another long and external process, are the developers even involved in this process of FDA approvals?

Anna: So there are many times, especially in new and big features, then there are also design documents and a description of a system and tests that must be met for approval, so as if it is something that is required.

Yishai: You need a lot of documentation that developers love to do (sarcastically).

Anna: right, very much (laughing)

Yishai: How do you manage to make it part of the regular work and I didn't write, write, write, and in the end I go and write a document that is always from the last task.

Eitan: I tell you it's not like that.

Yishai: I don't know, I'm asking.

Anna: So some happens in the process, because it's just normal standard software development, even if you don't need to, even if you don't have to explain yourself. But many times there is also work focused on existing features specifically for the benefit of regulation.

Yishai: I realised. And in these worlds, where developers have to deal with challenges we will call external, of regulation, of working so that we can work with data, etc. And again, most developers do not come from these backgrounds or are not used to this process, here you found that your background from the management side actually helps you, helps the team you work with to deal with it?

Anna: I think that mainly what helps, and I don't know if it's something specific to management or not, is a sense of ownership. Because I think that in general, as the processes in the company are more complex and more multi-faceted in all kinds of fields, it requires much more ownership on the part of everyone, including the developer, including the product, not to be closed only in his own box because I developed, this is, or I developed the The algorithm is,

Yishai: It's QA's fault anyway.

Anna: (Laughs) That's it, so it's something that he really needs to understand that what you're doing is part of something bigger and to grow your head a little bit. So it also touches the field of regulation, also security, everything.

Yishai: I think we all want developers who grow heads all day.

Anna: But here it's like a must.

Yishai: You imply that in a world with regulation and processes that are not just code, best practices and deploy, you need extra ownership.

Anna: Yes, I really think, as if something is more complex, let's say regardless of formal regulation, you enter organizations that are very conservative, they are not used to fully trusting their suppliers, companies, what they are promised. Because they don't see this change as maybe in other areas that are happening, so they are very suspicious of innovation. So it's also something that requires building trust with such companies and organizations, it requires a lot of commitment from everyone. I mean, it's every developer you talk to, they have to be impressed by him and every support person and every product, all the time really give them both the service and the feeling that they can trust you, as if in the end it boils down to that.

Yishai: And what you just said affects, say, an approach to recruiting juniors? Or recruit juniors but don't expose them like you expose the rest of your developers? Because of this appearance?

Anna: I think it takes time, even in recent years I have worked fewer hours in front of clients in production, so it is more difficult for me to relate to it, but... in the beginning we would work quite directly, as if we were few, no matter how junior you were, you would get into things quite quickly, and that's a lot times more character. There are people who are super seniors, who do make a small head, and there are junior people who, let's say, it doesn't matter, who are very, just kidding, because there was a junior nickname that didn't suit the… , that were said here towards some people who no longer matched the title.

Eitan: Yes, it was my nickname, I just came to say that I am shocked here when people say the word junior all the time, it was my nickname there at GigaSpaces.

Anna: Yes, Eitan is shrinking, it no longer suited him at all. So I really believe it's much more related to character than seniority, but yes, it also requires diligence from people they develop and may not be used to talking to customers, so it is required because yes there is interaction and there is, yes.

Yishai: And in a sharp transition to you Ethan, a world of drivers, I don't know, from my lateral acquaintance with say "Egged" and transport companies here in Israel, it is a very outdated, very non-technological world. I imagine this is true in general for this sector, and there is also regulation. In the end, I don't know, the Ministry of Transportation or other regulatory bodies determine the lines, it's not entirely, let me optimize an algorithm and everyone will go where they need to. How does this affect the development worlds in management?

Eitan: The regulation itself I think is less relevant in our field, but the first part you said is the very relevant part, that it is actually an outdated world and we actually disrupted when we came up with a cloud native platform, there is nothing on-premise with us, everything is basically multi-tenant systems that serve the All the customers, which is already in some places to this day we receive such RFP's, you see the questionnaire and you see that it is a question for on-premise systems. And somewhere there is a bit of market education whose direction today is to understand that cloud native is the solution, but

Yishai: Do you compete in ERP systems for this segment?

Eitan: Not ERP, but outdated on-premise systems that are actually home grown or our legacy competitors that have existed for 40, 50 years with systems, and part of the market is still adjusted in its thinking because I need it here. But we manage to change it a lot and this is one of the edges we bring. But in addition we are a mission critical system, which basically means that if our system is down, 70 percent of the transport in England now can't function that well, so it puts you on,

Yishai: Is it at a level where the driver doesn't know where to go now? Which line does he take?

Eitan: Less what the driver specifically is now, but what operation for example I need to do today or tomorrow, what is the placement of all the tasks, what is everyone going to do, tracking the working hours, if we are talking about drivers. Our system starts from the planning of the lines as you say, to the actual operation in the field. Literally the operating system of a public transport company. So in the beginning, even when we were relatively few people, few customers, let's say we had fun breaking the system, every deployment we do a real deployment, we used to deploy even every week of the system. And the customers would know it's Sunday, and if they're in Europe Monday, okay, what problems are we going to have now. But as we grew to become really such a large percentage of transportation and you are in enterprises with tens of thousands of drivers and thousands of vehicles, we had to start developing more and more protections and mechanisms that basically make sure that when we deploy something we are not now going to break the system. So it also comes from procedures and some permissions that even in the beginning anyone could simply deploy, push, wherever they wanted. So you start changing it because sometimes people are motivated and they say yes, I'm done with it, okay, I'll call it Junior in quotes, let's run the database migration now, Tuesday, and drop the database because I'm choking it on 100 percent CPU and whole system down. So we started saying okay, let's make it a necessary process, reaches some group of people with super power users and they need to approve it and a lot of automation that protects us and let's say the recording infrastructure that I described was part of this effort to make sure that we deploy something after we've tested it About a lot of data from production.

Yishai: And that means you also scaled back the frequency of the deployment? I mean today we don't deploy all the time or every week?

Eitan: No, the truth is we didn't scale back, we still do, it's every two weeks, for several years now every two weeks we do a deployment. We do a daily deployment of hot fixes and things like that but we'll call it the cadence of the sprint every two weeks, so that's what we do in deployment. So simply we do a lot more automation of coverage of tests and processes and the roll out of flags that we also added that, not a single thing reaches production and gradually starts to grow and grow and see if we don't cause problems, so we added a lot of such mechanisms that the developers talk about it themselves, when they We are now putting in a pool request, so the ribo needs to see a moment, did you put a roll out faction here that protects it? No, why, what's the risk, if it's high, you should, if not, you should at least get approval from some two or three people who will look at it and they agree that you shouldn't. We actually put in processes that protect, but it's not from a place of regulation, from a place of simply the system needs to go up.

Yishai: I understand, you say it is a place of mission critical impact for many organizations. And within that do you still feel the effect that comes from the fact that the customers are not technological people, they are not used to consuming technology like this? In the end, they may decide to buy from the cloud and not from on-prem, but these are not customers who constantly live with technology and are used to consuming SaaS, this also has an effect, beyond the fact that you are mission critical and you cannot fall because otherwise all the

Eitan: Yes, such customers themselves sometimes consist of dozens of people where you have a spectrum of all kinds of people, so there are the people who are more likely to call it adopters and embrace the technology, there are the more outdated, there are those who try to contain processes that are not suitable for you like I have to approve you Before you do the deployment, send me the things you are going to deploy, and I will approve it in the committee. Then you have to explain to them that it doesn't work like that, it's not your system, it's everyone's system, so you have to find the way of OK, so just let me know at least, so that I know there are going to be changes. I kind of approved you, but it's more so that I won't be surprised that something happened. But that's how I understand that it's not my system and it's not on-premise and there's no version that's been frozen here for a year now, so you have to find a way to live in both worlds and basically as time goes by it becomes our customer and explain to them and they see the difference between the two worlds. And today they only come to us more and more to say okay, let's give me both this and this and this instead of all kinds of legacy solutions they have because they understand the advantage of a modern system that is updated for them every week and not once every 5 years. Upgrade and it takes them a year to do it.

Yishai: And Anna, you're still in an area that doesn't deliver every two weeks to clients, there's no hospital situation.

Anna: Right.

Yishai: How do you do it, I'm talking about new features or a new capability, want to do something else that doesn't exist in the product today, if we look at the fact that I don't know, in the last 10, 15 years the whole world of the cloud, the whole world of deployment is basically free, it made it very easy for organizations to experiment on, let's make a new feature, put it in front of some customers, get feedback, improve it, polish it and then we'll be ready. How do you do these processes when your client is a hospital. How can you even begin to do such experimentation.

Anna: Yes, that's a good question, it really depends on the size of the changes, when it's major changes it's something that must be, really changes the user experience,

Yishai: It doesn't matter if something exists, a new feature, a capability that didn't exist yesterday.

Anna: You could, you have to confirm that too. I mean you really have to, if it's a really big feature, you have to, even at the level of how you present it, sometimes it's regulated. I mean, for example, we had many rounds of, did I say that we are looking for all kinds of findings, let's say brain bleeding, and then we alert. But how is this notification made? In all kinds of forms, but the most basic form is a visual form. I mean, you see the scan, let's say of a brain scan, and you need them to somehow show you where the bleeding is, because many times a CT scan is also a lot of pictures, right? So you can't say okay, you have bleeding, you also have to say where and even that is sometimes a problem, because there is a regulation on that too. Just for example, at first I think the first one was arrows, just put an arrow, okay? Here is the bleeding, look, so it is also something that is problematic in terms of regulation because sometimes it incites the doctor's attention to a certain place and he will not look at another place, at this level. So we had to change it to a hit map, or even in some cases not show it at all, let's say OK, this is the picture, you will find it, just to not create a situation where instead of bringing benefit, you will do harm, because the doctor will not look at the right area.

Yishai: So given such limitations, how do I do experimentation? I think I can present the bleeding in a way that will be useful to the doctors, but I can't even show them something preliminary because I have to go through committees, how do I do the,

Anna: So like any product characterization, of course we are in very, very close contact with the customers, we talk about how convenient and what the options are and also with the FDA of course what is possible and what is not possible. So these are things that are talked about, it's a simple part of the product's characterization, it seems to me that we feel it less because it's simply part of the process.

Yishai: But it happens before development, not on real data, like it's not that now show me 100 pictures a month with an arrow and I'll tell you if it's good or not. That is, that's how I would approach it if I didn't have the limitations. I would say let's start doing it for real, give me feedback, a client or two who are willing to work a little dirty,

Anna: True, it is very, very problematic.

Yishai: Wow, works great, let's do it for everyone. not working well? Come on tell me the arrow should be a map, the arrow is green, make me a hit map. Everything here is on paper, product designs that are as if before development?

Anna: No, you can do it, develop pilots and show them, but not in production, you can't reveal, you can work with people who are kind of early adopters and show them partial information, that's how it looks, even their information but not in production. So it's done, that's why the cycles are a bit longer, you can't completely change your product and what you do and the algorithm as much as you like, but yes, that's part of the point.

Yishai: Okay, so pilots, how about you? How do you manage to experiment and build new capabilities or significant improvements?

Eitan: I think there is a lot of similarity between the type of customers here, which is actually high touch, it's not like I'm now on Facebook with a million users and I want to do statistical tests that if I show him this ad, if there is a better conversion. But I know my users, they have an account manager and I can talk to them directly and expose them, so I guess what happens with you is that you really show people things before, get feedback but not from something that is statistical like that from people you don't know. And with us it is very similar.

Anna: Yes, exactly, it's something else, you're not addressing millions now, you're addressing very specific customers with very specific needs, so that's how to talk to specific people and not rely only on statistical tools.

Eitan: Yeah, so we just literally build the mock-ups or things like that and present. Of course we have no regulatory restrictions, we change the system without anyone forbidding us to do these things. But in terms of experiments, it's a lot of engagement with the customers and even with our internal helpers because we have all the customer success, they actually use the system, we ourselves do all kinds of POC with a new customer. We need to activate the system to show him the value, so we have many internal users who themselves give a lot of feedback, so it requires what is called to engage with the customer in a personal conversation and show them the things.

(transitional music)

Yishai: So to finish, I want to ask you about the hottest hype today, the world of AI, chatGPT, you both deal with algorithms, AI in learning, where do you see this hype starting to enter the fields you deal with? Anna, what do you think?

Anna: Wow, first of all chatGPT is cool. But I'm usually less enthusiastic about new technologies that come in, and in the end the technology itself isn't really new, the generative AI, but it really picked up speed in the last year, and really reached everyone, including people who touch the technical things much less. And I do think that it will come in, It's still hard for me to say, I'm not good at fortune telling, how exactly, but I do think that in the medical field it will take time in my opinion. Also because of the points we touched on earlier, because of the relative conservatism and caution to adopt new technologies. I think that everyone who enters will try to develop based products chatGPT or the like, will have to think carefully about what exactly the product is and what the offering is, and of course the FDA approvals as far as that is concerned, because this is also something that will be challenging. But I do think that it will come in and it may even come in from below, just as it also comes in for developers who are not waiting now For the approval of the CEO to use by asking chatGPT to produce documentation or write tests for their code, so I believe even doctors may already be using it a little when the patient is not looking, asking him what exactly should be recommended.

Eitan: I really hope not, after seeing the answers he gives to relevant questions. I really hope not.

Yishai: You will get a well worded answer, not sure if this is the treatment you want, but,

Anna: So I also think that it also depends on what type of data it is training on, and I do believe that it will improve and enter such fields as well and can be an amazing tool to complete. Of course not to replace, just like we don't pretend to replace the doctors either, but to be a tool and help and make sure they don't miss something, or something they didn't think about in the diagnosis, maybe in other areas, I think it would be cool to see the future of this.

Yishai: And in your world what do you think? The world of transportation, maybe a little less classic for that.

Anna: Exactly the opposite (laughing).

Eitan: First of all, I will apologize for the previous statement that our future overlord will hear it in 10 years, so that the chatGPT will not be angry with me, but I think it has good uses and it has some not so good uses at the moment I think they are good, and I learned it from trying to play with It. First of all, we work with AI, not generative AI, in the context of more than a learning machine and look at historical information and actually, for example, see all the movements of the buses in history and deduce from that how the program you are building now is going to behave. What will be meeting the schedules, and really optimizing the schedules so that they give the passenger a better service and take that into account. I think it can be very interesting and uses of things like support, there is actually today, let's say third-level support, which are people who are not necessarily company employees, usually they follow the sun model. They work with all kinds of scripts, they don't really know the world The content, and precisely to train such an AI model on all the data, history, all the knowledge archive I have, training materials and the like, I think he can probably do an even better job because he really at least delved in and learned.

Yishai: which is technical support for your customers.

Eitan: Yes, real support or even internal as well, we started to work with internal stack overflow and I think that if I start training him on our internal knowledge it can also give answers for example in Slack to people who ask.

Yishai: Let him read the beet and everything is already written there.

Eitan: Yes.

Yishai: What about worlds of, say, first line support for public transportation customers?

Eitan: Yes, it looks like the same model to me. Look, as long as you are in a content world that is really well defined, I guess it is relatively easy, even today there are many bots, even before chatGPT that are suitable when your world of questions is very closed. As soon as it starts to be broader and drawing conclusions and things that they require more, we will call it more than a certain type of training, it already works a little less, but it is only the beginning. I've already seen it say all sorts of nonsense very elegantly, so I do think he could be a good pounder because he can rattle off assertively when asked questions. The problem is that if the other party knows the answer then,

Yishai: So he starts fighting with him.

Eitan: starts to fight with him. But yeah, it's very impressive, and it looks like the future will be, I think it's going to change this world a lot that you have to provide answers that are, or produce content, summarize summaries of a lot of information. For example, one of the uses I've recently seen done at our place is that you write a review for an employee and you get feedback from 20 colleagues, so you can tell him to summarize for me the 5 best points from it, give an example, and that makes it amazing. It saves an insane amount of time to start doing it yourself, and you probably do it worse.

Yishai: Anna, Eitan, it was excellent, thank you very much for coming.

Eitan: Thank you.

Anna: Thank you very much for ordering.

(transitional music)

Go to devinterrupted.com to subscribe, you can also find all our episodes in English there. I remind you that we at LinearB are in rapid growth and are recruiting for a variety of positions in all fields. Visit 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:

• AIDoc
• Optibus
• Mitchell Hashimoto
• GigaSpaces