VP of Engineering? You need to skill up! Ronny Shapiro, Daniel Ben Tov, Yaron Cohen

In this special episode, Yishai Beeri, CTO at LinearB hosts three talented guests - Leap program alumni (remember our first episode with Adi Shacham-Shavit?!) In this episode, three VPs of Engineering share a bit about their journey, the importance of finding a support community for what is likely the loneliest job in tech, and the important to intentionally and consciously dedicate time to skilling up and strategy that tends to get lost i the day to day.

Episode Transcript תמליל הפרק

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

(opening music)

Welcome to the Hebrew version of Dev Interrupted, LinearB's successful podcast for engineering managers. Here we will talk about everything that hinders engineering managers. I'm Yishai Beeri, CTO at LinearB. We are happy to bring you the podcast in Hebrew. Here we will host leaders in the industry to talk about everything that interests engineering managers, those who work with them, and those who want to one day manage an engineering organization.

Yishai: In this episode I am happy to host three guests: Roni Shapira - VP Engineering at Duda, Hi Roni.

Roni: Hello, very nice.

Yishai: Hi, Daniel Bentov - VP Engineering at Hyro.

Daniel: Hello.

Yishai: And Yaron Cohen, Engineering Manager at Clinch.

Yaron: Hello.

Yishai: Hey, what's up? It's a lot of fun for me to host three guests at once, it's a special episode, and as always we'll start by hearing from each of you a little bit about their journey to date, literally in two minutes about their careers, how each one got to their place. Yaron, let's start with you.

Yaron: So I started programming at the age of 13 GW-BASIC on MS-DOS and I didn't actually touch computers until after the army, when a friend invited me to work at a company that worked on Magic at the time, I did it for two years and realized that if I want to be serious then I should go study. I studied Computer Science at the Tel Aviv-Jaffa Academic College and I continued from there to Netcraft for a short period of time, about a year, and was accepted to SAP. My first job in a large corporation, I was a developer for two years and I was offered an opportunity to manage a type of integration operation, a very large project. In the beginning something like 25 people, and at the peak 80 people in four locations around the world. I was actually the right hand of the VP who managed the project and I mainly dealt with problems like the work between the teams, how to set up a system for demos, how to see that everything is connected. I went on to another engineering position where, although I was offered a team leader position, the technological field did not interest me that much. I preferred to continue, to return to the sources for a little longer, I also felt that it was not the time yet and after 6 years I felt that I had exhausted SAP. By the way at that time there was a lot of talent within the same organization where I worked, among them Amir from Duda, the founder, the guys who founded AppsFlyer, the guys who founded Indigo and a few other companies. Then I left and I really wanted to do something of my own. I founded a startup with two friends, the startup wasn't so successful, I left after about a year when I realized that the business feasibility didn't work that well. I did a team leader position at a startup called Infolinks and from that actually came the opportunity to take a VP R&D position at "Angie", it was at the very beginning, there was no money yet, we worked for a few months for free until funding came. I was there for two years in this position. At Clinch I also joined at the beginning, we were 5 people in engineering, including the founder.

Yishai: Tell us in a minute what Clinch does.

Yaron: Clinch is a company that develops a platform that helps large advertisers manage the entire lifecycle from the creative to the connection with the sources where they buy the media, the traffic of the users. We have the leading tools in the world that were also ranked by Forrester and Gartner as the leading DCO platform for dynamic content optimization. This means that you take a campaign with advertisements with a very large amount of variations, up to millions of variations, let's say for clients like Walmart, who have 100 million products on the site, you pick up an advertising campaign with a million options and it optimizes this automatically, choosing for each visitor the content that is most relevant for them.

Yishai: Doesn't sound like a challenge on the engineering side at all.

Yaron: No, why not (laughs) a scale of billions of events per day of course, happy.

Yishai: What fun. Roni, tell us a little about yourself and your track.

Roni: Okay, so compared to Yaron, I entered the world of programming at a much, much later age, only at the age of 18. Actually, I did a course, a course as a military engineer in the army, a six-year pre-army course and then I was placed in the Air Force. I served a relatively long term in the IAF, almost 10 years. I was an officer there, I held several team leader positions, including civilian industries - Rafael and such. When I was released, a friend pulled me to a small startup he worked at called Duda and I arrived there as one of the first programmers. And 9 years later I'm still in the same company, we've grown a bit, we already have over 200 employees, I've held several positions at Duda - from engineering I moved to team leader, I was a team leader for quite a few years, the organization was still very flat and we started to grow and add more hierarchies and not everything was under the co-founder CTO. So I'm actually the first VP Engineering in the company, so that's how I grew from the bottom and I've been in the company for many years and there are always new challenges, so it's quite challenging.

Yishai: And in a word what Duda does.

Roni: So Duda is a platform for building websites, unlike more well-known platforms we are not B2B. Customers come to Duda to build their own website. Most of our customers are what we call web professionals or designers or agencies or SaaS companies that do all kinds of more complex integrations. In general, a customer with us is not one to one for their website, but it can be tens of thousands of websites of their customers, it is actually a B2B2C model. We have a fairly wide spectrum of clients - from freelancers or small agencies to very, very large clients that build automation with APIs and all kinds of more advanced processes.

Yishai: Wow, cool. Daniel, tell us about yourself.

Daniel: Well, you all went way back, I'll go back too. So I was also in the air force, then in defense industries, more in the worlds of aviation, and then I went to study Computer Science and Economics at Tel Aviv University. I immediately joined a startup, I was the second employee at a startup called SCREEMO, from there I continued to a startup called Bizzabo. I grew there with the company, until we reached almost 130 people. From a frontend developer to management worlds, then an offer came out of nowhere, from Atlassian, a small company in Australia. I moved to Australia with a 10 month old baby girl and my wife. We came back 5 months ago. I was there for 4 years, I managed a Jira team of about 80 people, basically all the most central pages you know in Jira. So I worked at crazy scale - from a startup in Israel to tens of millions of users, and from there I became Head of Engineering for their UI Platform, basically all the company's frontend systems for Trello, Confluence, Jira, and the internal startups that Atlassian is building, a crazy experience. We decided to return to Israel for personal reasons and on the way I spoke with the current CEO of Hyro and the partner who is actually my best friend from school. He was also with me at SCREEMO, also the first employee of the company with me at "SCREEMO". And basically I returned to what I like to do the most and that is to build, I joined Hyro 5 months ago. Hyro basically builds a virtual assistant in the worlds of conversational AI. We work mainly in the USA in two main areas - one is the whole world of healthcare, the second is the world of real estate. And in fact people use our system to make appointments, whether it's to the doctor, whether it's to see an apartment, and everything is automated. In the worlds of voice, you usually settle on call centers, what you know when you call Partner, or Hot or Maccabi, or Leumit and wait 40 minutes for a very basic operation. With us you will receive it immediately, 24/7. In fact, we allow the same agent to deal with the real problems that you need - like some real refund or if you have some complex problem or need a doctor urgently and immediately. So we deal a lot in the area of ​​deflection and resolution, for these worlds, we also do it on the sites themselves.

Yishai: Deflection is a word that I'm sure we all like as consumers (laughs) what is the percentage of deflection...excellent, so today we want to talk about this role of VP Engineering, of someone who manages engineering in the company, to emphasize the issue of learning - How do I study, how do I do skill up to be good in this position? And I would love to hear from everyone about the first time they entered the position of VP Engineering and how it felt different from what they did before, some of you described a path that was startup only, some of you a path that included an enterprise like SAP and I think that Atlassian can also qualify as an enterprise . So Roni, let's start with you, you actually grew up within Duda and moved from role to role, how was it on your first day or first week as VP Engineering? How was it different from everything that came before?

Roni: So I think it's a relatively dramatic transition from a team leader, which is very, very localized/specific. You have a handful of programmers and usually some specific project or product, and you align yourself to the processes that exist in the company, to a transition to a position that is very broad and actually being responsible for the engineering, you actually have to change your whole mindset from thinking about how my team will function well and meet its goals. You now need to think horizontally. You think about processes, you think about how proposals with others will work, you think about things that are softer like culture and development of the company, all kinds of things that you hear from the outside world and you say okay, is this relevant for me? Also the fact that this is actually a role that did not exist before me, also made me realize that I need to build up the role a little and understand for myself a little bit what it means and requires, so in the first year it was different from the second year and the third year. You try to take it in all kinds of different directions, but I think that this transition from team leader to VP Engineering is really a revolution.

Yishai: When you took this step, you felt that it was clear to you and your manager? (I guess that would be the CTO.) What is needed, what does this position mean, or did you actually build it together without knowing this is the goal, that's how I describe the position, but you just go in and do it?

Roni: So we made a job description document like we always do, we worked on it for about two hours together and then it goes in a drawer and simply after that you are buried in the day to day. So there are the projects and the clients and the things that are important. In the end, you have to think a little–– sometimes you have to put more emphasis on the things beyond, because it's easy to get lost in what you did yesterday.

Yishai: Yaron, how was your first step as VP Engineering?

Yaron: So this is a very significant step, I think you understand two things: one, that the engineering umbrella you received before does not actually exist. When I moved, you enter a company, you have developers, but suddenly there are no devops, there is nothing, servers, nothing, you do everything yourself. So many times as VP Engineering you are also responsible for the infrastructure, you are responsible for the developers to work efficiently, which of course also exists in larger organizations. And the other part is learning to manage the founders, especially if it is also founders that it is their first time and they are still relatively young in age. Which is what was the case at Engie, so there were many aspects of how to manage it, how to say no. I mean not to say no, but to say maybe not now, maybe we will prioritize, yes but, how much will it cost you? Learning to present these things is very, very difficult, this is the biggest gap in my opinion.

Yishai: And Daniel? How did you get into the position of VP Engineering? How did it feel different?

Daniel: I think that in my last position in terms of responsibility and budget management and all these things, then at Atlassian I really started to experience this, what it is to manage an organization of 100 people, completely different areas and contexts and so on. But when you really come from an enterprise, you come with a shell, and when you suddenly come to be VP Engineering, I think this is also what Yaron was talking about, suddenly you have nothing, you have to build the shell. And wait, where do you invest? Because this, this and that are missing. And you need to start sorting things out and understand for a moment what makes more impact, how you don't become a bottleneck, how much you invest in your people, how you create your team and empower them so that you can also focus on strategy. And where do I look a year ahead–– 3 years ahead and 5 years ahead to where the company is going, and also your ability to influence this, because you can move things very quickly whether you work with your peers, whether the VP Sales or the VP Product or with the founders, so I think it's really a lot of balls you suddenly need to juggle, and you have to make the right decisions, this is mainly the big difference, I think.

Yishai: All three of you are graduates of Adi Shacham-Shavit and Miri Curiel's LEAP program. Adi by the way was our first guest on the podcast here at Dev Interrupted in Hebrew. Tell me what you felt you lacked or when you entered the position and really, as you said, it is different from previous positions. Where did you feel that you lacked something in, that you need to skill up or go to study or go to develop beyond the day-to-day dealing with what this position is and its innovations mean.

Yaron: I think that for me we were in a growth phase when we reached the size of 8 people, I already felt a bit of a need to create some kind of first management layer and create team leaders and I knew we were going to grow, I mean we reached some sort of product market fit. Not yet, I mean the company is already feeling the acceleration coming, feeling this pressure in the back seat and I felt the need to have on the one hand some sort of orderly route where I spend a few hours a week, to define the role, also define the vision, also define the goals of the department , the culture I want to produce within this thing, to find our uniqueness as a engineering body. One that will attract strong candidates to come work for us. And I was looking for a place where I would have the opportunity to share it with other people, in conjunction with the fact that I know Adi from the past, and I trusted her and I had already consulted her in the past on several matters. So everything together led to the fact that this is the right place, that's exactly when they started to publish it and I jumped on the bandwagon and I said “folks, I'm there”.

Yishai: So you took it as skilling up for Yaron as the VP Engineering, or rather how do I find time to define what it means to be, or to do engineering at Engie?

Yaron: I think both, it was no longer in Engie, it was in Clinch, and it was both. There was this opportunity of literally––the company is growing again, I have to create team leads again, and I want to define it in an orderly manner. I also don’t want to repeat the previous mistake of how to manage the founders, that is, how to manage the expectations of the position, how to manage the whole issue of recruiting personnel which often has a lot of budget challenges, you need to define ok, what abilities are important, how to prioritize, these are the things.

Yishai: Roni.

Roni: So I signed up for this program quite by accident. It's hard for me to say that I reached some point where I said wow, I lack skills, I will now look for things. I heard that there is such a program and I read the syllabus and said it sounds really interesting. And what caught me the most about it, is that you have no one to consult on a daily basis in your position. It's such a position that you function a lot on gut feelings, you can't necessarily consult with those above you, it's also not always healthy to consult with those below you, so you work according to what you feel is right and you don't have any kind of support group. So just from the syllabus you understand that there is probably some forum of people who are experiencing the same things that you are experiencing, that you can consult with them, that you can talk to them. That they will talk about challenges that you experience on a daily basis in the program - if it is work with the product, if it is technical debt (technical debt). If it's, I don't know, recruitment and retention, a million things going through your mind. And it was clear to me that I wasn't doing everything right. I signed up out of some kind of expectation that I would have some kind of forum to consult with, also to receive reinforcements regarding the things I am doing and of course also to discover the things that I don't know that I am not doing well.

"It's such a position that you function a lot on gut feelings, you can't necessarily consult with those above you, it's also not always healthy to consult with those below you, so you work according to what you feel is right and you don't have any kind of support group."

Yishai: So soon we will ask more about what you received and what things moved the needle for you. But, Daniel, how did you get to "Leap"? And in general the need or thought of skilling up?

Daniel: So I was still in Australia and a friend from Atlassian told me ‘listen, you're going to this new position, there's an amazing woman named Miri, she's doing some kind of program, you have to check it out’ - and that's how I came. And at the beginning I had a conversation with Adi, I think that for me it came very much from the place of trying to be humble and saying okay, you did a role in corporate, now you’re going to a completely different role. You don't know a lot of things, come learn. Also my understanding, from my experience, that at the end of this position is very, very lonely. And I think that, as the friends here said, the very fact that there are other people who experience the same difficulties and the same problems. And in the end you are always in such a position that you hear too many things, too many problems and you have to make things neither flow down nor flow up, and somehow keep it to yourself. And the fact that you have such a support group where you can unload and people that you can learn from––and wait, this thing can be solved with some two or three other solutions, gives you a lot of inner strength and power. And I think it also goes back to what you said at the beginning about this place of how you study, like where can I go to study, oh, there are other people who have experienced this thing at different stages, let's talk to them and of course people like Adi and Miri with so many years of experience , you get insights that are worth so much.

(transitional music)

Yeshi: Something that comes up here is the loneliness of the engineering manager, Ori, our CEO who was VP Engineering wrote a blog post about it that received quite a few echoes about why being VP Engineering is more difficult than being the CEO. More lonely. We have received countless responses to this post, people really connect to it, people in positions of engineering leadership are very connected to this sentiment of––wait a moment, I have no one to consult, I am alone, I do not have any group of peers in the company that I can talk to. And it sounds like you came up with a way to create a support group here, whether it's through the course or it doesn't matter, other groups, that allow you to talk about what hurts and maybe hear what the others have done. So when I think, and people in general also think about skilling up and training, the more we talk about more senior positions, the more we think about something less formal (for skilling up) - much less a course, or learned material, more self-study, if at all. Somehow we tend to think that juniors should to study and seniors study alone, study on the fly, precisely in such a position of VP Engineering to go to a course, even go to an Officer training course, or a Platoon leader course or I don't know what to compare it to, sounds like something less natural, obvious. So what made you actually go to a more organized framework and not say sure, I need to study, but let's read, let's consult on the forums.

Roni: I agree with you, I think that once you climb up, you look less for pure technical skills. There really is the end to that, and then you have to work maybe more on things that are more soft, and it's maybe a little harder to teach. But there are a lot of (all kinds) of workshops for managers, all kinds of organizational consultants, and we did some at Duda as well, and we did some in the army. I'm personally a bit tired of these things, of all kinds of "important vs. urgent" workshops and I don't know, "to work in the team" and all kinds of things like that there are––where some are better than others––but there really are a lot. I think what attracted me to this program is that it talks specifically about the challenges that interest engineering managers, and there really aren't any of these. So without even thinking too much I said it's something that really doesn't exist, and there will only be people who are like me and care about the same stuff as me, and it won't be some generic thing or the lowest common denominator of managers, so it was clear to me that it was worth giving it a chance.

Yishai: Daniel, what, how about you, apart from the recommendation you received, a decision to go for something formal, binding, with a schedule, instead of getting along per se?

Daniel: I think that like any position, no matter what field, when you start to climb up you have to fight the ego monster and not get to a place of okay, I don't need to study already and I already know this, as I'm already a senior and this addiction is terribly dangerous. You always have to learn and you can always learn and on the contrary, I think that precisely when you are busy and you seem to have no time all the time, the fact that you go to the framework will force you to do it. It's a lot like sports, right? If I train alone then after 3 weeks I will stop, but if I have a personal trainer or I sign up for some class, I will really go. And I think that once you find something that is also suitable and relevant then you have the opportunity to really get a lot out of it and in the worst case you didn't succeed . But, like, I think this structure is very healthy, certainly when you go to people who have experienced it and it's not something amorphic or with people who haven't done it themselves. In the end Miri and Adi went through it in the flesh, and I think that is the biggest advantage. And they also try to adjust the group to the size, you know, if there were people in this group who come from Enterprise or come from round D already and stuff like that, we’d have less in common. The fact that we all came from more or less similar places like this and that, so it was lots of mutual enrichment.

Yaron: To complete what was said here before me, a thousand percent––I agree with everything you said, I think that sometimes just being exposed to questions in general, opens up a world of things you didn't think about and this is very important. And also the timeframe and the specific framework of this course that in the end you come out with some sort of organized work plan of objectives, of goals and you set aside a fixed time for it once a week, which will always be overrun, when you want to do it independently it will almost always be overrun by the regular or by an urgent problem of this client or another client, which is very powerful.

Yishai: You raise an important point here and I think that one of the biggest obstacles for those who want to go to such a framework is how do I find the time for it? VP Engineering is a position that is constantly under fire and there is never time, so how did you manage, first of all internally, to convince yourself that you have time and it is possible to commit to a framework, maybe not very constraining but a framework nonetheless. And how did you stand up to it in the face of the current day to day, in the face of the P0s, in front of the crises that keep arising and now I have to go to the course or invest time in it.

Roni: It's easy, you pay everything in advance and then you have to (laughing)

Yishai: Okay, but you didn't really pay (laughs)

Roni: No, but I think it's that there is a framework and that you know that there are regular meetings and all the appointments are sent in advance in the calendar, and you are also told what is frontal and what is not frontal and once you have everything in the diary in advance, so it kind of forces you to line up like a soldier in the army, it is easy.

Yishai: Did any of you opt out of a meeting? Because he had a crisis and production fell and...

Roni: Daniel flaked several times, (laughs).

Daniel: (What a lie...) I even arrived in person…

Yishai: I was still in Australia...

Daniel: Yes, I arrived, they didn't recognize me at all in the company, if on Tuesday he doesn't come, well, maybe he closed 80% of the job, we don't know who this man is anyway, we haven't seen his face. I do think so but that-,

Yishai: Wait, you arrived on day one already with... already in the course.

Daniel: Yes, I arrived on day one of the course and it's like I don't even know what to say about the company, yes? I knew stories, anecdotes, but I do think, in general I see a lot of managers who fill up their schedules and they kind of fall in love with being busy and I think that in general it's an anti-pattern,

Yishai: Let me open the diary...

Daniel: And people like to seem important, right? Appearance seems a bit important sometimes. And I think that, I, what I like to say is that if you don't allocate 30 to 40 percent to yourself and that, I got, I have some mentors like that that I caught at Atlassian, people who have done crazy things, and I think one of the things that I've learned is that if I will not devote 30 to 40 percent of my time to strategy and things that are important to me to move in the organization, I will not achieve them my entire life. And if I manage to take it out of this pie, then I will manage to do these things, and if you get to a point where you can't allow yourself to do something like that. I think you have another problem, you shouldn't be in that place, that's my perception of how it really is to scale up, scale up yourself too.

"If I will not devote 30 to 40 percent of my time to strategy and things that are important to me to move in the organization, I will not achieve them my entire life."

Yaron: I completely agree, we must make time for what is important, but first of all,

Yishai: If I open your calendar now will I see black? Black, yellow, green, red? All the colors...

Yaron: Depends on which week.

Yishai: Next week...

Roni I very much agree with what Daniel said, in the end it doesn't matter what kind of framework you want, even if it's even going to the gym once or twice a week, and you can't get yourself into something that's important to you, it really doesn't matter what it is. Whether it's skilling up or going to be with the kids, if you can't find two hours a week to do anything, then there's probably something else, there's another problem that needs to be addressed.

Yishai: I agree, I have seen this about myself, but also for many people there is no problem, they set the two hours, put it recurring, it is locked, it is known, and then suddenly, at the last minute there is a conversation with a client. There is something that -, and it's the kind of thing that tends to endure, I mean it's the thing that will be run over. Because somehow there is some kind of perception of it that it is optional. Maybe when you go to the course then you can't opt out, but if it's strategy time and suddenly something urgent comes in, in many cases the urgent matter takes precedence.

Daniel: It's like bugs that are in starvation and then are never touched. There is this bug that you accumulate for like 7 years, right? So in the end you build some kind of system that manages this thing, right? Then you determine which time a month, which day bug fixes and then touch these things. I think it's the same thing. You, there is a certain place that you must sanctify it and lock it up and say no, now I'm not touching it, there's nothing to do, it's a period of time. But if I know that now it's for two or three months, they'll wait, someone will deal with it, otherwise how will you test yourself, in the end how do you know you're doing a good job? Disappear for a month, everything will continue to run as usual, if you really did it then they will get along in this client call without you, the world won't explode.

Yaron: Absolutely, beyond that I think it's necessary, in a body that is growing all the time, so of course you have to think ahead all the time, and the course is exactly this place, where you see what things are not working well or that in a moment they will be a bottleneck and if you don't take care of them now, actively , they won't happen. So this is where I identified some such things, this is where we built the first management layer and it also gave me the tools to make the next change which is a transition from teams to squads. And as if all this foundation was made for that. It is important to note that I did the course a little over a year ago, so some time has passed and we managed to go through two types of small re-orgs within the company. And it's amazing that all these skills were acquired or, I won't say 100 percent acquired, but I got a lot of tools from Leap to do these things. In order to reflect them better within the organization to the other executives, to marketing and sales and to everyone who needs to understand it. You get many tools to convince, many tools to convey the message in the right way and in general to understand how the other bodies within the organization look at the engineering. What do they expect to get from us, I think this...and this is also reflected in the fact that there are other people like you sitting at the table, so you also see it from different angles. I mean it's not just made from some kind of belief in Adi and Miri, but it really comes from the field.

(transitional music)

Yishai: So, Yaron, you've actually already put the spotlight on something like that that you took from the course, in this area of ​​re-organization and tools, let's call it. Or tools that help you manage the moves and this growth, Roni, what, maybe one thing you took, the most prominent thing that you have gained from this course.

Roni: So it's hard for me to say any one very, very specific thing that I took, I think that during the course we talk a lot about things that are somewhat clear to us - but we don't really talk about them. Like what your job is, what you have to lead, what kind of impact you have to make, work with product, technical debt, all kinds of things that are a bit obvious but not talked about enough. And these conversations give you a little insight into your place in the organization. And then you also understand that you need to talk about these things also within the organization with the team leads. I think one of the things I'll say, I tried to take away from the course is to talk a about these things with my team leads and not just deal with, I know, statuses or projects or what we should do next week or month. But how do we build an engineering organization here, especially things like this.

Yishai: And how was it received? How did the team leaders react to the new topic or to this expansion of the scope of what they are talking about?

Roni: I think they are happy about it because they also want to skill up and although there is a course for team leaders, I also think that "Leap" is doing it, but they haven't gone to it yet. So I try to at least mediate some of the content that caught my attention. I hope they enjoy it.

Yishai: Daniel, is there one thing that you also want to put the spotlight on?

Daniel: So a few months after I came in, I made a big organizational change, mainly the purpose for which they brought me. Which is how you scale and take one more leap forward to a machine that worked quite well but now needs to work much better, and I had a combination there, of how you make such a big change upon entering the position,

Yishai: Sometimes it's an advantage that now I'm entering and there's no history, I don't know anyone, I have credit as if to...

Daniel: Absolutely, it's also a balance, but because you don't want to come and directly change all the things you know nothing about, as if you could miss out on a huge amount if you...

Yishai: I came to destroy (laughs)

Daniel: Yes, so you don't want to do that, as if for the sake of visibility, to show my presence. And I think that at Leap, both the group and Adi and Miri really helped me to understand the timing, and when it’s right and when not and it really moved with the course while as an organization we were in motion. As if there was a time when I said, wait, I need to be more on the gas, wait, I need to let go, and in the end it really happened during the course. I think it was quite successful, once again, there is always room for improvement, but it really helped me decide how to do it, particularly in areas around the product and how to build the main teams and such.

Yishai: So you're really painting a picture where the course is not rigid, that is, there was actually some adaptation of the content or the discussion to your situation. Or simply the conversations with the peers.

Daniel: I think in a way, so there are side conversations, watercooler conversations sometimes, of course when we were not on Zoom. Some of the sessions were on Zoom, and some were not. My conversations with Adi and Miri during breaks, one as well as the other, or with the people, and many times we managed to connect all kinds of dots while in motion. Because when you make an organizational change, it touches many areas, it touches how you are building the product and how you build the teams and organizational structure, by squads or by area of ​​the product, by the technical area, so there are many touch points. And then you can always try and find the right fit, and how do I manage the founders around this thing too.

Yishai: Tell me about something that on the one hand you took from the course or from the peer group, some kind of insight, but that you were unable to fulfill it, to realize it in reality. I mean, there was some kind of gap or disconnect or some kind of obstacle from taking something that you really wanted to achieve or apply, and in the end in reality it didn't work out. Because I suppose there is always variation in how you succeed in promoting or introducing an insight that you have learned.

Daniel: I think one of the challenges we talked about a lot is really, or at least there was an entire session dedicated to it, the whole topic of technical debt. So we always talk about how to harness the business to the technological initiatives and why it is important, and how it will shorten engineering times, reduce bugs, all kinds of things like that. Then we talked about all kinds of frameworks that can help or allocate time, or hackathons for reducing tech debt. I think that in practice we can talk about many such frameworks and we know that in startup life it is always a struggle, always difficult. I think we are here too. It's talked about a lot but it's hard for me to say that we've cracked it and now I'm... this is exactly what -, everything I wanted.

Yishai: And business tells will say to you - take as much as you want, make it non-functional, block the date off, we are patient (laughs), easy, easy.

Daniel: Sure. I think that the point that I discovered in retrospect, that maybe we didn't address it enough in the course, is more about this world of sales, customers, customer success. There was a lot of focus on the technical. Lots of focus on the product, but I think it's actually some kind of whole tier in which you, as VP Engineering, are actually quite a significant part of it. How much do you pushback, how much you direct the product, how much you educate the other side. Which I was a little surprised by how much volume it takes up for me in my day to day, I think it could be possible to develop a lot more discourse on it.

Yishai: And really in a large organization, in an enterprise, there are some layers between the engineering managers and the stakeholders and others, such as success and sales and marketing.

Daniel: You are not really exposed, as if you really have as you say many layers along the way and you are exposed here and there but the whole system is already working and the position of all the teams is clear, and the synergy between them and that you are in a startup it’s not just about what you define, the definition changes on the fly. And at this stage you have to be a bit flexible, so I think it's a significant difference.

Yishai: So you're actually putting here some kind of proposal for what could be in the course, I don't know, Leap version 2, or Leap for advanced students course. I won't continue with the military analogies. So Roni, what would you take or define as content for an advanced course? A course for LEAPP graduates, LEAP 2.0?

Roni: It's hard for me to think of any specific session that I was missing, what Daniel said really sounds interesting, but I think that maybe something I would do is define in advance sessions that are blank slate, and are filled according to what is currently happening. I think that over the last 3 years, every time engineering managers had something really different, that really really bothered them. So if it is 2020 the whole transition of working from home and how to do it well. And how not to micromanage and how the communication should be. A year after that it's all the craziness of recruitments and retention and transitions and all these things. And 2022 is also terribly challenging, so I think that precisely what I might do is leave such blanks for issues that are burning for all of us.

Yishai: And if you're thinking about an actual continuation course, another year, two more years, another skilling up, what would you like to see there? Not necessarily as gaps in the existing course but as another floor, what do you think could be brought to the course for those who have already done it and have already scaled once, or maybe they don't need to.

Roni: I think the next stage is perhaps a stage of group leaders, that you manage group leaders, now this transition could be, depending on the success of the startup, yes? It could be two more years, it could be another seven, it could be never, so I'm like...

Yishai: How do you manage group leaders? Does that mean VP Engineering has manager managers under him?

Roni: Right, and how do you now teach them to do this thing and what does it say about you, what do you let go of, where do you spend your time and give them space, even there you don't want to micromanage,

Yaron: In general, perhaps the topic of managing managers, I mean also managing team leaders, you need to know and there may be all kinds of nuances here that you can take in and learn, and really this is my content personally was lacking in name, it is also something that I know I lack in general and I would be happy expand on it.

Yishai: You can say that this is the situation where we are really talking about VP, right? who is not only an engineering group manager, but actually a manager of managers or even managers of managers, and is much more concerned with building the force than in the running.

(transitional music)

Yishai: So the "Leap" program and similar programs have some kind of set duration, a little more intense than doing it alone, but it starts and after a few weeks or months it ends. How do you make something out of it that is lasting, an impact that is not only okay, now I'm in it and I'm on it, but two months after it ended I was already back to old routines. Where, how did you manage to make an impact that continues with you like after you've already finished the program?

Yaron: So I think, first of all there is a "Leap" group that meets once a month with a changing topic, unfortunately I have two really small children and this prevents me a bit...

Yishai: Fortunately, you have two small children (laughs)

Yaron: Fortunately I have two small children and unfortunately this does not leave me much time to join these meetings because it is always at a slightly problematic time. But in general beyond that, I mean this is the place where you can meet and discuss and bring up issues that are on the agenda, as Roni said. Here all kinds of things that happen and change over time. Every year with its problems. Personally, I try to be a member of the VP R&D WhatsApp groups or the forum as well as in other places Many relatively soft topics come up, from time to time people also ask technical questions such as what did you do in this context, what product did you use, but the most interesting conversations are about the soft topics - yes work from home, no work from home, how many days from home, how does it affect on the engineering.

Yishai: In the end it's all people.

Daniel: Yes, I only found out that I met Yaron here at the entrance, we don't know each other before that, so I found out that I haven't really adjusted yet because I'm not in any WhatsApp groups like that. So I don't hear these things, so Yaron said he would add me, so maybe now I will be one of the folks who can learn as well.

Roni: I think the community of this program is probably no less strong than the content itself - the fact that you have someone to talk to and consult with and check what the struggles are in the other places and how people solved things even six months later, is in my opinion one of the strongest things.

Yishai: So it continues? You manage to create a dialogue, I mean there are the meetings and there is also an unmediated dialogue between the graduates, you say I can pick up the phone or consult or hear from someone about a challenge, is this something that happens?

Roni: So Daniel and I are in the same building, so we got to say hello a few times in the hallway. We also have a Slack group like this for all the graduates and WhatsApp groups, so there are all kinds of media that you can talk to, but yes.

Yishai: If it were me, I would ask you whether you did, did you go to the track, for such training as "LEAP" at the right time or too late, too early, how am I as someone who is thinking of going to the position of VP Engineering or is already in such a position, what is the right time? When should you go?

Yaron: I feel that at any time, you can always learn, you can always develop. And startups, even startups that are in a frozen state perhaps, are sure to be full of challenges. But growing startups is full of challenges and also everything moves very fast, so there is always the next challenge, there is always the next bottleneck that suddenly arises, there are always the problems of the hour and I think it will help at any time. Specifically in this group I was mostly people, I mean from startups in different stages, and the different stages are relatively close in size, I mean there were no engineering managers here from companies of a thousand people, it was let's say up to a few hundred at most, and at a minimum it's even managers of 10 People, I mean in my group there were people who were in an earlier stage than me, in my stage and one or two stages after me.

Yishai: So you're saying it's not too early for anyone who...

Daniel: I think you did say that though, didn't you? Like I wouldn't have come under 10 [employees under me], say, because it seems to be a bit lacking in essence to me, and also maybe you wouldn't connect to all the challenges because maybe half of them you haven’t gotten to yet at all. And I wouldn't have come to that if I wasn't in the position of the VP yet, like someone who wants to be a VP, but right now is the head of a group, I wouldn't go either. I don't think I would have gone yet because you didn't have those interfaces of founders and you didn't have the interfaces with the VP Product, like there are a lot of things that weren't relevant to you in the course.

Yishai: This is not a training course or preparation for, but I am already in the position, I can now help a little.

Daniel: My feeling, once again, I'm a little biased because that's what I did, but I think that in my personal feeling in your first role it will give you a lot, because you are still malleable, you aren’t set in your ways yet. It will give you perhaps the most in my opinion. But I agree that even if you didn't do it in the beginning you will do it after a year or two, you will still gain a lot, but you will come to be in the position and have a minimum of 10 people.

Roni: I would say I would be happy to do this route a little earlier, I did it say 3 years in the role, I don't know if I would want to do it in the first month or two, I would like to learn a little myself what this role is and come with my challenges from home, but I think that between six months and a year later it could have been really successful.

Yishai: And if I were to ask the, or we will ask today or while you were right inside this course, the people around you, say the head of teams who work with you or the CEO, the CTO, people who work around you, about the course, what do you think they would tell me? As something that was reflected through your work or the way you talked about it, what changed in Yaron as an engineering manager, from their point of view.

Yaron: I think that mainly the job definition, in my case it is also a bit special because I have a founder who is a CTO and he was not a programmer. Kind of was never a programmer, he was a pilot, studied electrical engineering and started and simply coded for several years at home some product and customers already arrived and he already had two employees. Then I joined and this relationship of who does what was a bit unstable, but maybe as if following the course two or three things happened. One of the most important of them is that we got the job definition of what the VP R&D does and what the CTO does, and it further solidified over time. It didn't just stop at the end of the course or in the middle of the course, but it helped solidify it. The clear areas of responsibility, what is his responsibility, what is my responsibility. Regarding the other people, I think that I presented to the CEO the plan that we built at the end of the course, both of the job definition and the goals of the R&D body, and it really helped to refine how we look at [our strategy] and what they expect, that is, to get his feedback on how I see things helped me relax.

Yishai: Roni, what, if I were to ask you, the CEO, the CTO, the heads of your teams, what would they tell me about this course?

Roni: So I think that mainly the team leaders may have noticed this, because I really tried a little to bring content that I felt was very good to be talked about at all. Even if I have it sitting somewhere in the back of my mind, then all kinds of really more soft things for our team leaders forum. I don't know if other people in the organization really noticed this, I ended up in this position after already several years in it. So I don't think that in 3 months it made me a completely different person within the organization, but I believe that the heads of teams, we also talked about it. It's not that I suddenly brought content out of nowhere, they knew that I was going through this program and I told them that I would probably bring all kinds of things, so it pretty much directly affected them.

(transitional music)

Yishai: Daniel?

Daniel: First of all, maybe we have a very interesting breakdown here about the CEO's description that we should talk about later. But I think that for me, once again, it was easy because they didn't know me, so I ended up like that with the course. I think my simple use of this thing is that it helped me structure my thoughts and bring all my scattered ideas into some kind of structure. And then let's say I also presented some of the content for our product and it helped me direct them more towards what I intend. I also used it in Org, I also used it later to come to the CEO with a two-year vision ahead. And then everything suddenly came structured, okay, it's much more chewable for me, I really understand where you're going, I like the direction, but once again, there was no reference of before and after then like.

Yaron: Maybe the before and after is less important, more the fact that you have something in writing, you can check six months later, a year later, wait, I set goals for myself, where is it at, where reality has changed and where I stand in relation to the goals.

Daniel: Absolutely, and I think it's also, there was no VP, I guess you were in similar situations, there was no VP Engineering before me. There was a CTO but he was not a classic VP Engineering, and you came with all kinds of statements, okay, so you came with statements, so now we can challenge what you said. And when you come with a validation, wait, it wasn't just me who said, look, there is a whole course here that we paid money for, and other people say the same thing, I didn't invent anything here. Guys, that's how it works, okay? All of a sudden it gives you some kind of joker card for a discussion that you can really use, and if they really annoy you, you call Adi and say, I need you to come and tell them... (laughing)

Yishai: You are illustrating something quite common here, certainly in Israel, certainly in startups. The CTO, one of the founders in most cases, sometimes decides that they need to recruit a VP Engineering and sometimes needs to split himself, and do two different things and release the tasks, or produce this function of VP Engineering. And maybe this is part of the special challenge that a course like "Leap" can help solve because until yesterday it was not defined, it was part of what the CTO did from all directions. And at a certain point he suddenly is like wait, okay, I don't need to bother with this, I need to bring in an expert or create an expert. So where did you come across this challenge of a CTO not releasing, no names, yes? (laughing) Speaking theoretically, but this challenge, it always comes from good intentions, but it creates a special difficulty, it's not another VP Engineering who comes to a company that is already used to it and these areas are already separated and now he takes up the position as a professional. Someone should be released here from this half of the role that was never defined.

Yaron: I'm interested in hearing Roni.

Roni: It's interesting, I feel that when I took the position I entered some kind of void that already existed. I mean my CTO is a very technical person, he also still writes code but he is very, very focused on the product and the customers and where the product should go and strategy and things like correct engineering processes, working with programmers, mentoring, code reviews, all kinds of things like that. These are things that he has already given more all kinds of initiatives by programmers, team leaders, architects to lead. And when I took the position, it was clear to me that I needed to normalize this whole issue of engineering processes, and this is something that he was quite happy to give up in the first place. It's not like we had any power struggles, he pretty much said in advance, take these things from me, and that's how it was.

Yaron: I think that founders are often exactly as you described, this is also the case with my founder who is a CTO, very customer oriented, very technically oriented, he still writes code and he occasionally comes back from a weekend where something terrible bothered him and there is a new feature in the product , take it now, make it a product and not a POC...

Yishai: It's called throwing it over the fence (laughing) there's a pull request, come on, take it away (laughing)

Yaron: Worse...

Roni: It didn't come as a priority, it didn't come out of nowhere, it landed on your head...

Ronnie, I want it in production next week.

Yishai: This is called CTO prioritization. No, it's already in production, now also make sure it doesn't break.

Roni: It is defined - behind a feature flag. …

Daniel: Yes. I think what's interesting is that this thing, in the course you see it, how informal it is. Some VP Engineering report to the CEO, some VP Engineering report to the CTO, some are peers, they are parallel. And each such structure creates other problems, and certainly if the CTO is a founder or not a founder, and it was really interesting to see that the very situation tells you that you need to solve the problem from a completely different angle, because wait, how, what is the relationship between you, and who is responsible for what...

Yishai: And how product integrates, this also has a structure from all directions.

Daniel: Yes, wait, and me and the product have to report to the same person, so we both report to the CTO? We both report to the CEO? We don't report to the same person, what does that mean? So wait, who works with the product? CTO or me? Both of us? that no one has yet really formalized it. By the way, Adi and Miri do have an opinion that they talked about with us in the course, so it's a special situation.

Yishai: I think you see a lot of technical funders who, on the one hand, are very creative, think a lot about customers, they are less interested in the process, which is probably natural because otherwise they wouldn't be running around starting companies all day. And this break of a moment, I want to release but still be the owner of the entire engineering process, then the VP Engineering reports to the CTO, I am still responsible for the delivery. I'm responsible for the entire product, and then maybe VP Engineering and VP Product report to the CTO. Or sometimes you have a CEO who himself is technical and he himself understands, and then he wants much more to keep it with him and not get it from several levels but okay, the delivery are important enough for me that the guys report directly to me and the CTO does something a little different. This variation is seen all the time and I agree with you that each variation has its own challenges.

Yaron: It seems to me that what emerges in common here is that usually they are not interested in messing with the engineering processes, I mean for them a testing environment is something that is nice to have, it is not necessary...

Yishai: No, it's very important...

Yishai: ...and I'm not interested in the details, leave me out of the details (laughs).

Daniel: Yes, even at the end, you know, VP Engineering is apparently a glamorous position. He is not that glamorous. A lot of your day is dealing with human problems, you have to love it. And if you don't have empathy in a basic way, let's say someone tells me I want to be a team leader, the first question I ask him is why? And if I tell him, say, people come and complain to you or want to talk about their growth and things like that, how does that make you feel? Some people start exploding in the chair, I tell him then it's not for you. Do you want to move forward? There is an IC axis (individual contributor) you can make excellent progress. But if that's what tickles your fancy, this is not the place for you. And I think that many times as VP Engineering quite a bit of your concern is with people, and many CTOs say it doesn't interest me that much, I want to build something, I want to create, so I bring someone to deal with my problems.

Yaron: I will add to your Plus One (laughing), this is the power building, most of the time we deal with the power building, we deal with how to bring in the most talented engineers and how to give a good engineering experience so that the children (builds) are not taken a million years and that the testing environment will work and that everything will talk and that everyone will be on the same page, where is the company going anyway, what do we want from the engineering body, where do we want to go, how do we improve, what metrics? I mean, this is the main part of the job and if you don't enjoy it, because I have someone in the company who is very interested in the technical aspects, the architecture, but dealing with things that are softer, mercifully. It's like a waste of time or boring, so no, you have to like it.

Yishai: So Yaron, you are talking about the subject of the experience, of the engineers or I don't know, developer experience. What, what things do you have, or why do you emphasize developer experience, how do you make sure that your engineers have a good experience?

Yaron: We are finally launching a project that we have been working on for a very long time, Yishai: Why project? For local work or for...

Yaron: It's also for local work, it's also for some kind of dev data center that allows many elements of the production environment to be replicated. Specifically, our production systems consist of many types of services, many connections between the various systems. It's a complete mess and setting up such a thing locally is very inefficient. So it's really a challenge, we put a lot of thought and a lot of time into it and I really hope that all the time we've invested will prove itself.

Yishai: Roni, what do you have in this world of internal developer experience?

Roni: The truth is that this is a very difficult problem that is also connected somewhere even to an organizational structure, let's say with us we work in this way of squads so each squad has a product area that it is responsible for. So in other places I know that there is, say, a platform team that is responsible for promoting the whole issue of developer experience, infrastructure. So I always felt we were a little too small for that. There was no real justification to come and build a whole team so we have architects who are a little bit promoting it. We have tech leads that we try to give them time to promote these things as well, but when you have teams whose focus is products and they have a product manager on the team then you should always try to get buy-in from the product manager. How can technical people within the team also promote things that are infrastructural, and the bigger the organization is and there are more services and we also have a monolith, then it is something that requires more and more investment, so it is something that really needs to be managed, it is not something that will simply happen from personal initiatives of programmers.

Yishai: Do you manage to get a good signal of what even hurts? On this side of developer experience?

Roni: We invest in it, we do both surveys and forums and a roundtable of the programmers and architects. We create such a technical backlog of things we want to work on, which are not at all related to the product, not related to the customers. And we do, one of the things we do is once a quarter we take all the programmers for 3 days and work only on this technical backlog. And let the programmers do something different from their everyday life. It's hard for me to say that it solves all the dev experience problems we have in the company, but it's better than nothing. And yes, it requires management, it is not something that will happen by itself.

Daniel: Fortunately, I went through an amazing school on steroids, I managed the Jira Frontend Platform, the repository that Jira moved from JQuery backbone to React, at the peak we reached 800 developers who worked on this repository, with 3.5 million lines of code. A monster. And my team is responsible for this thing to be in the air and work well, etc. And I went through an amazing school there, I think the things I took with me and I apply them here at Hiero is that first of all, before I arrived there was already a team called dev velocity. Although we are twenty or so people in engineering, there was a dedicated team. The things I brought with me first of all to measure, one of the things you as a manager want to show people who are not engineering is data. Do you know how much time a developer wastes waiting for a build? Or is he waiting for production deployment? Once I can produce it in number, it is very easy for me to produce work. Do you want to save two hours a week? Or 20 hours a week? Here, on paper, let me just work on it, so it's a lot easier. Two, this whole world of terms, performance, reliability, observability, how do I measure these things? How do I reflect them? How do I invest in systems? Let's say one of the first things we did was to bring Datadog.

Let's say and jump two levels, in this place of introduction let's say. So I took the rotation that was on-call, someone who was like that was called a sheriff. I told them ok, from now on you don't work half the time in your team and whenever you are called, at that time you do that sheriff. We will work hard, improve it so that it will be easy and you will get everything to chew through Datadog and such, and monitoring. And the rest of the time you do dev velocity. You are together with this team, so that information goes back in. And this is something I did at "Atlasian" and created such a rotation that was a great success and then people are less afraid and the knowledge starts to flow. Because once you are exposed to these devops people, who know amazing things, then it really creates such a synergy and circulation of data in the flow that flows, and you have to work on it. By the way, one of the interesting things is to do OKR in engineering around dev experience.

Yishai: Yes, it's not easy, but this, the question is who owns it.

Daniel: engineering, but you have to measure, you have to come and say how do I measure? define success metrics, build, wait, maybe I need to change architecture, maybe I need a second to split things here, change my pipeline, there might be some impact on the product, but it is possible to make a huge impact there and I think a lot of people don't know how to approach for that at all.

Yishai: It's an interesting innovation that in the team, even with, I don't know, 20 people in engineering, you already say that I have room to assign people to dev velocity, which is their job description.

Daniel: Yes, because it's easy for me to show it in terms of money, how much time I waste if I don't invest in it, and it's easy, so I also very quickly speak in terms of the platform team, because otherwise I show how inefficient and time-wasting we are, so as long as I Being able to show ROI is all good, that's why I say engineering also needs to talk in terms of money.

Yishai: So it's both the fact that I'm investing in it and, but how do you justify it being a dedicated team and not dispersed, let's say okay, each team will invest some time in dev velocity where it hurts.

Daniel: So I, you know, it's like a lot of people are, maybe I'll say something that's a bit extreme here, but there are a lot of programmers...

Yishai: No one listens to this, you can speak freely...

Daniel: Yes, fine, anyway it's just the three of us, the four of us...many people say they are full stack, but they did half a year back end and two years front end, they don't know either this something or that something or they know one thing well , but a real full stack that can really do end to end needs at least 4-5 years in each area, devops is a specialty, it's not something you do on the road, some people really know the ropes, yes? They were born inside AWS and married to Azure and this knowledge is unique. It's not just that these people are hard to get hold of. Now you do want their knowledge to flow out, but it has to come with some kind of intention. And so you don't want to make big mistakes, because this is also the whole world of compliance, security, reliability, based on performance, based around their world that drives everything, on the other hand, you want to transfer this knowledge out, so I Think you do want a dedicated team, on the other hand don't put them in an aquarium and say it's theirs, nobody knows anything, works. It's also bad.

Yaron: As soon as you keep engineering teams away from production, it's a recipe for trouble.

Daniel: Exactly, so I think it's really, really important.

Yishai: Well, towards the end, I would like to hear from each of you one tip or one piece of advice or one thought for a starting VP Engineering or someone who is thinking of entering this position or someone who is in this position and feels that they are missing something. Yaron, one point.

Yaron: A support group.

Roni: Which is exactly what I wanted to say. I think taking people you can consult with is critical, you will experience many things that people before you have already experienced and encountered, and even if you don't have all the answers, the very fact that you speak them out loud and there will be someone on the other side who can hear it, is priceless.

Yaron: So I completely agree, I'll just add, I said it before but don't live in the current all the time, if you're in the current all the time, it will be difficult for you to make an impact as VP Engineering, you're a firefighter who puts out fires and you want to make a significant impact? You must disconnect at certain moments from the partner.

Yishai: The station commander (laughing)

Yaron: Yes.

Yishai: Yaron, Roni and Daniel, thank you very much.

Yaron: Thank you.

(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 we 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:

• LEAP
• Duda
• Clinch
• Hyro
• Engie
• Atlassian (Jira, Trello, Confluence)
• SAP