Is the VP of Engineering Just a Glorified Project Manager?, Adi Shacham-Shavit

In our first Hebrew episode of Dev Interrupted, Yishai Beeri, CTO at LinearB hosts Adi Shacham-Shavit.  She will talk about the different trends, technologies, culture, and tools that changed the face of the industry over the course of the past 20 years, where she served as an engineering leader at some of the hottest Israeli companies from Liveperson to AppsFlyer, Lemonade and today is SVP of Engineering at Transmit Security and co-founder of Leap--the program to help engineering leaders in scale-ups handle the challenges of rapid growth.

Episode Transcript תמליל הפרק

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

(Opening music)

Yishai: Welcome to the Israeli version of Dev Interrupted, LinearB’s hit podcast for engineering managers. On our show we will talk about everything that “interrupts” engineering managers from their flow. I'm Yishai Beeri, CTO at LinearB.

(Music)

Yishai: With the announcement of our big Round B, we are excited to bring you this newly minted podcast in Hebrew. On the show we will host industry leaders who will talk about everything that disrupts engineering managers, along with those who work with them, and those who want to one day manage an engineering organization themselves. In the first episode, I am happy to host Adi Shacham-Shavit, one of the most seasoned leaders in the industry,  co-founder of "LEAP", a program for training the next generation of engineering leaders, and the SVP Engineering at Transmit Security. And now we'll dive into the full interview.

(Music)

Yishai: I would be happy if you could tell me a little about your journey, how you started, how your career unfolded and where you are today.

Adi: First off, I'm very excited to be the show’s first guest, I've been in the industry for many years, having held all kinds of engineering roles––I came to LivePerson, where at the time it was a small company of 60 people and held quite a few roles, until I left when there were 900 people, and after that I made a very dramatic switch and moved To Appsflyer as the tenth person in the company. I came to set up and manage the entire engineering team, but basically we were four people in the whole team, for the three and a half years I was in the company the team grew to 70 people, the system grew from 200,000,000 events per day to 20 billion, we learned how to provide more and more value from the same data we collected and the company grew very much and developed. This was also my first VP Engineering role, we will go back to this after that and I will tell a little more why I even went to do it, I went back to engineering management at Lemonade.  I arrived at Lemonade at a more advanced stage after their Round B. There I took both the role of VP Engineering as well as the role of acting CISO for Data, Privacy, and Regulation, entering the European market and more.  After that I went on to lead the engineering as EVP Engineering at a start-up called Clear that builds settlement and reconciliation systems between large enterprise organizations through the creation of a private blockchain network between them. A year and a half ago I set up a forum of senior engineering managers in an organization called "Baot", and a year ago I set up together with Miri Couriel who is my partner, a program for the engineering of engineering managers in start-ups in the scale-up phase called "LEAP" and four months ago I joined Transmit Security.

Yishai: Wow! And at Transmit you’re the SVP R&D

Adi: That's right

Yishai: So we'll be back to ask you, as someone who has been involved in developing and managing teams, why you have repeatedly returned to roles of VP Engineering, and the establishment of engineering organizations from scratch. I think there are some interesting questions there, but first I want to hear a little more about LEAP, tell me a little about the program, what are you doing there, what did you learn?

Adi: Sure, we already had two cohorts and now we are in the middle of the third cohort. In each cohort there are between 12-14 VPs of Engineering from start-ups usually at a stage when the start-up suddenly succeeds and starts to grow rapidly, and then you suddenly have to not just manage the engineering properly but also to understand how to help the company grow and evolve and how to work differently with the Founders and the rest of the management team. I think it was born right from the heart, from the place of ... Honestly, I wish someone would help me save some of the things I learned the hard way, and helped me skip over some of the bumps I fell into, and provided some structure and order in the methodology and thinking about these things because there is a lot of complexity in actually doing it right.

Yishai: If you are talking about difficulties or failures you have experienced and if having a LEAP in your time would have helped you, would you like to tell us about one of these?

Adi: Wow there were many.

Yishai: We love glorious failure stories.

Adi: (laughs) I think it took me a while to understand that as an engineering manager in a start-up you not only manage the engineering, but you are also part of the company management and you have to communicate the needs of the engineering teams to the founders and other management stakeholders, and how to understand what the business needs from the engineering organization, and bring  this to the forefront of the engineering team’s strategy, and make the right decisions. I think it was not a specific failure, and there was a time it took me to figure it out, as well as to figure out what was the right course of action and how to execute it well and correctly.

Yishai: And is that something that can be taught? The understanding, this feeling that I not only produce features but I need to be more connected to the management––is this something you manage to convey in LEAP?

Adi: I think that ... First, I hope so. That might be a better question for the graduates. I think actually establishing what the VP R&D role in a startup actually is,  and providing the right framing maybe already in this session it very very opens the mind to people to understand what they need to do, because a lot of times you work in a startup and founders don't know how to tell you ‘that's what I need from you”, they need a lot of things from the engineering team  and the engineering  manager and they do not know how to state it clearly. I need this and I need you to give me that, and I need you to talk to me this way, because they have many other things they need to take them forward. The fact that you start to become aware of the fact that there is actually a business part within your role, and one part is understanding the business, and the other half is understanding how it translates into technology, I think this is one of the things that perhaps drives the greatest change of thinking.

Yishai: So it sounds like not only engineering managers need to learn this framing and understand it, but also those who employ them, and who work alongside them. What shifts have you witnessed from the many years you spent in such roles? Any change in how the managers, the founders, or how the stakeholders who sit at the same table perceive this role and know how to conduct themselves in front of it? Maybe they need a course too?

Adi: Yes (laughs), the truth that a lot of times people in the course tell us maybe next time I will bring X that works with me in this and that position to the course next time, or the next course. I think there is some kind of dissonance between the perception that ... engineering managers are ultimately programmers, engineers, and we always have a certain way of communicating and a certain way of phrasing things, and a certain way of looking at the world through the eyes of an engineer who is very structured in thinking and it is very ... for example we will not talk about something that happens if we are not sure know exactly how it works, when it happens and when it comes into play, and this is a big dissonance between people who are entrepreneurs or people who are in places of say marketing and sales who often run forward and fly ahead with their ideas, and when we say no to them or not yet it turns them off and it is tough for them.   And when we say to engineering managers there are words that are more correct to communicate in this or that context, or you have to come up with a variety of solutions instead of just saying no, but to say this can be done instead and can be put into this project and done in this way.

I think maybe if I wanted to say one thing to someone who works with engineering managers: When an engineering manager tells you no it's not because they want to turn you down, it's maybe because they can’t think how they doe this task in addition to all the other sixty things they’re juggling and if you tell them, hang on a sec, maybe you can do it and prioritize something else instead it can open up their thinking and help them be creative in the solution they come up with.

"When an engineering manager tells you no it's not because they want to turn you down."

(Music)

Yishai: So let's talk a little bit about technology. If we look at the changes in  the role of the manager and today's engineering day has changed in the last 20 years, I have no doubt that technology and the changes we are all familiar with, beyond cloud and others, come into play here. Can you put your finger on what are the main ways that technology has impacted and changed the engineering management role or enabled changes?

Adi: So I might as well now talk a bit about my experience over my many years in the industry. Someone once told me that the VP R&D is nothing more than a glorified project manager whose whole job is to make sure projects get in and out on time and the versions are released properly and bugless for customers. And today I look at it and say like there is nothing that is worse than still only knowing how to do Project Management as a Engineering Manager, if so - then you are not doing your job well enough. I think if I reflect a moment about technology and the changes the entire DevOps movement has taken us to, it also allows us to manage engineering in a very very different way and be very close to the business and be very close to delivery, and not do what I'm sure you also once did. Complete in advance a very fancy Gantt and what will delivered from engineering in what month, and then by the first week of January it is no longer aligned with reality but still in the tenth week of the year someone will come back to you with a slide and tell me but you wrote in the Gantt that you would deliver this feature, what about it? You can’t explain to them ...

"Someone once told me that the VP R&D is nothing more than a glorified project manager."

Yishai: It hangs on the wall.

Adi: It's hanging on the wall, exactly (laughs).

Yishai: So what in technology has changed all this? The shortening times of the Build and Deploy process that allow us to be much quicker to learn from the market? From customers or users?

Adi: So I think it's really a combination of the CI / CD that seems to be no less than a revolution to me in this world for how we work and how we manage engineering. It allows us to actually move from this demanding need for planning a version half a year in advance down to the last details and what will be included and what will not. We’ll test it for months and go through design cycles of debugging and QA, and if there is anyone who is young and is not familiar with this, I am happy for them.  And CI/CD allows us to actually concentrate on understanding what the right value is at all and not how I push as much content as possible into this half year.

I think the second thing is the democratization of System and Network into the engineering, of monitoring systems that are today much more accessible to developers with observability - that they basically allow developers to also understand what happens to my system in production, and what is really being used, and where the traffic suddenly went up, and not have to guess where the next Bottleneck will be, or guess how many users I will have at the moment, but truly understand what's happening to my systems.  This was also the second game changer for me. I personally saw this, saw it and experienced it myself, saw what happens to developers when they do not touch production and they are not familiar with the production, and the systems they know how to produce and on the other hand when you bring them closer to production systems, how much better the engineering and product put out is.

Yishai: So basically if I take what you say, whoever is still developing in the worlds of on-prem or very related to hardware, that has long validation cycles is left behind, a candidate who will come to join LEAP but is in a world that has no CICD and is removed from production almost by definition, are they a lost cause?

Adi: God forbid, so for hardware it's a little hard for me to relate because I did not do it myself, but on-prem even today I have a system that is deployed on-prem, and I also managed to produce a blockchain system that is partially on-prem ... but some customers it was installed On-prem and at some other places, beyond what I have done in my distant past in recent years and probably among LEAP  participants are from all walks of life including those who come from a combination of hardware and software. I think it does not bother you to better understand what happens in business and why we do things a certain way and how can it be done more correctly, and also understand how you are from the world of the on-prem, ok it will not be a CD because customers sitting in the on-prem you do not touch them in production and make them a CD, but you can produce excellent observability in these places, which helps us understand what is happening and how to debug it and how to get there for a deep understanding of the system.

Yishai: Also that there is actually a multitude of production environments? Even points where on-perm is the edge - where there are almost an infinite number of production environments.

Adi: True, absolutely, completely.

(Music)

Yishai: So the next topic I want to talk to you about is data, we talked about the challenges of engineering managers and how an engineering manager in the modern world should hope that they has access to CI/CD and and observability, and hopefully maybe one production system, but where does data come into the picture here? How does data help me as an engineering manager do a better job?

Adi: So let's start from the flipside okay? Many times I hear founders or CEOs say to their engineering managers 'engineering is not delivering', or 'we used to do things much faster', or 'I can not work on these cycles this way and we have to do it differently', now If I'm a engineering manager and my founder told me this and there is no data ... I can guess all sorts of things but I basically can not come up with a solution for this statement. Many times these statements come when a startup suddenly goes through a significant phase of scale and what worked for them when they had a team of ten people does not work when they have a team of thirty or fifty. You know start-ups today move to very rapid and large scale and to really understand where I have a problem I have to use data, and data it is not some story points in Jira. This is not a metric I like to tell  people to measure. I think it's a metric that is terribly easy to measure but that does not mean it's the metric we want to measure. Honestly, we talked about it. The "Holy Grail" it's figuring out how I deliver true value to clients, or how to raise the value delivered to customers. If I have data I can understand then this data will help me increase velocity and understand where I have bottlenecks in the engineering process and understand which part may work well, but there is not enough capacity, and which maybe don’t work so well, and where to put some sort of order and process where there used to be two people who did everything together from end to end, and today there are several teams where each team works on a different system. So this will help produce some sort of process for correct collaboration and if I have no data I can only guess and maybe it’s related and maybe not.

Yishai: I heard here even before data as a tool to solve problems, data as a defense. If the founder comes to me with a claim that may be true and maybe not. First of all I have data to say 'it's not exactly what you think', 'it's not exactly what you say', 'there I have data that shows that we are delivery at the right speed or at least not as bad as you would conclude ', but after the first line of defense you say use the data to open up problems, to find the ... So you mentioned here what worth measuring and what not to measure, do you have a story or case where you got burned by a wrong metric or an organization that measured the wrong things?

Adi: There I think except ... there are two metrics I do not like, one is story points in Jira, because it is very easy to measure it and it is very easy to look and say - hang on in the sprint there should be 20 story points and today you did only 18 so your team is deteriorating maybe, but maybe we did the 18 hard ones and not the 20 easy ones, and it's very easy to falsely feel as if we’re getting better  and feel really good with ourselves and actually not improve anything. Another metric that I really don’t like is the percentage of unit test coverage on the system. I think this is another metric of something that makes me feel awfully good but not sure I checked the right and important things and it ... yes I was burned by it but I once worked in an organization that measured it and came to tell us with questions like why is the percentage of test coverage not above such a threshold, and below such a percentage. And eventually no one has conducted the real conversation of the quality of our tests, if we are producing the right tests at all, or if we really measure the risk through them. But just in quantity, how many tests I have run, and it created in me a kind of distaste I think to this metric, maybe not rightly so.

Yishai: It sounds like the things that are easy to measure are probably the things that are less successful to measure.

Adi: Yeah, I think, maybe (laughs).

Yishai: So if we want to measure what is important, what is useful for an engineering manager to make decisions, to improve the organization, then what do you think are the critical things to measure or how are the really important things measured?

Adi: That's a good question, look it's a question that I think is divided into several things, one is the areas of the system itself and measuring the scale that my system knows how to withstand and its stability and its uptime, that are eventually completely business metrics. And at first we think it doesn’t Interest the business, but of course it interests the business, because if my system is not stable then the organization is in trouble and if I want to improve it I need to measure it and understand where I am improving it and where in the system I have a problem. A metric that I really like in systems is to measure the Time to Resolution. I mean not to assume that I will arrive with zero production bugs, with zero production bugs, but how fast I discovered an issue and how fast I fixed something I discovered. It's an excellent measure because It shows how fast I can actually put patches in production.

Yishai: It also reduces cost, my ability to resolve an issue quickly increases my confidence in coming out with something new that may have glitches but I can overcome the glitches quickly.

Adi: Then if I actually have a very strong observability into the software on the one hand and on the other hand I can fix bugs quickly, then even if my QA is not perfect and I do not think any of us have perfect QA, I can ... Exactly, I can feel good about things because I can go out with them and I know that I ... be sure that I have other tools that help me solve the problems. And that by the way is a very significant change in thinking, because we used to think we should not go out with bugs for production or that a bug in production is like a disaster and today I think that if I have these two tools then yes I do not want to come out with bugs for production, I want to come out with a perfect system, but I recognize the fact that my system is not perfect and I can fix it as soon as possible.

Yishai: It's around the quality, what about around the very process of engineering or the ability to deliver? At the end the boss wants to deliver faster.

Adi: So here are some metrics that I like to look at and measure, such as how long from the stage I decided I was going to do something to the stage that I actually get it into production, that's a metric maybe ... the automation metric is that right? Because maybe I can manually upload it pretty fast, but it does not really matter to me as the manual process is intended to provide the baseline for how fast the automated process can or should be -  from the stage I decided to do something, uploading it, until it is deployed to production and in front of first customers. On the other hand, see also where I have a bottlenecks in the process, where this is a bit more complicated because sometimes the bottlenecks are actually in the lack of knowledge of the developers, that, they inherited something and then they do not understand at all what to do with what they got, and they start looking for that knowledge and there it actually gets stuck. Sometimes the bottlenecks are in systems that haven’t been tested, and I understand that I need test systems, and understand how to produce them for myself even very simple test systems that I can simulate things on. I think this understanding is something that is very critical, and many times I think when engineering managers are told their team is not delivering, many times it means suddenly there are bottlenecks in a process that used to work great. Or suddenly we have  bottlenecks and our ability to identify those bottlenecks in the very broad sense of the word, can be and figuring this out from just understanding that the team is not delivering, which doesn’t mean that if I bring in 30 more people now it will help because I might bring in 30 people and it will be worse not better.

Yishai: You talk about a situation where you can reach the understanding that once we delivered fast, and today you do not say you can go back to the same velocity even if you know how to identify the bottlenecks, and you know how to solve them, investigate them. While it’s not a lost cause, because we grew in the process and scaled, but on the other hand it will not be the same - it will be a little different.

Adi: It will not be the same but for good reasons okay? Let's get to a place where it's not the same thing because I used to build a system from a POC. Obviously it will not be the same to build a POC patch to show the customer and see if they like it, versus  a robust system that supports millions of users at once. Let's stay in this place and not in such a place, I also once wrote the same code in two days and today it takes two weeks because this developer does not know how to test and should be taught basic testing first.

(Music)

Yishai: We talked about metrics, about things that are worth measuring or should be measured, and things that may not be worth measuring. I want to ask you a philosophical question about metrics in an engineering organization, and what does it look like on the part of the developers, are we being measured? Are we mice on the wheel? What did you encounter when you have tried or when you introduced metrics to an engineering organization? How do developers react to this? How do developers react to the fact that engineering even needs to be measured?

Adi: I think here we get into what you are actually measuring, if I measure them in lines of code then it really does feel like mice on the wheel, and it is also not a good metric to measure, but if you measure the value that they deliver, and they also understand why they do it, I think it's a great experience for developers, it helps them improve, it helps them understand. Developers  love metrics, love to improve something and see it in numbers, it's our bread and butter.  And it should not be about why you personally wrote only 3 lines of code today and not 20.

Yishai: What about the ownership of the measurement process, the decision of what to measure? It can come from above: let's measure it, everyone please align with the metrics, or it can come bottom up, where each team will decide what is right for them to measure, how do you see this -  between democracy and chaos? Top-down vs. bottom-up perspective.

Adi: I think it very much depends on the situation of the start-up and work style. I will explain, today we very much work in teams that are basically oriented by product from end to end teams responsible for a product and its delivery and its measurements and then these metrics are actually relevant to the specific team. How many more users can be onboarded to the system, how fast can  your system integrate with another system, such measurements. Then it is specific to each team.  Then there are things that are more horizontal. They are derived from having created a uniform CI process and we want to make sure that our build times really are within a certain scope of time, and if it took more than that then let's understand how we improve it all the time.

Yishai: So it's actually a combination ...

Adi: I'm talking about a combination, yes. I'm talking about a combination of metrics, and I'm also talking about the state of a company. If you build everything from scratch from the first day of the company then that’s one thing, if you go into a company and you make a change it's a different situation, I think each start-up  really is a standalone case unto itself.

Yishai: In this world where the developer is king or queen, insane demand for developers is one of the biggest challenges in growing companies, such as access to talent. On the other hand there is a challenge here of how to build together as a team, build value through code base changes. I wonder what you think about the aspects of the developer experience. What I or you, as an engineering manager, should think about when you look at the developers' experience. How do I create the right experience for them that will lead to both well-being and productivity, as well as success in the various metrics and ultimately a thing that delivers value?

Adi: So this is a great question because it's like something we deeply understand inside why this is an important thing, but externally this  does not really really matter to anyone––the experience of my developers.

Yishai: And to be clear, I'm not talking about the screen size or the number of ice cream flavors.

Adi: Yes, yes, obviously (laughs).

Yishai: Real developer experience at the work level.

Adi: Of course, obviously. Let's start with the fact that I think the good developers like a good work environment, and like that they have the ability to check their code all the time, and the ability to work with tools that are the right tools for the job, and integrate security into the engineering process, and run smoothly ahead with everything at once.  Which actually helps me understand how to connect it to their effectiveness, because in the end if I have a very very effective and very good experience it's a lot of fun for the good developers and it's very right for the organization too, it actually helps ... I'll give an example: If my developers build takes an hour and a half for example, and I will invest time and we will shorten it even to a quarter of an hour okay? Let's not talk about two minutes, even less than an hour, I have made my developers very happy, and on the other hand I saved a lot of time that is worth a lot of money to the organization. It's a win-win for both of these sides.

Yishai: So the developer experience was created from what? By priority decisions? What do I invest in? I invest in the non-functional to shorten build times? Or is this something that is created from ... I bought the right technologies? I invested in the right tool set?

Adi: It starts by saying - I want my developer experience to be good, and it’s important to me. Because when I choose tools. I  have a great example from today, in my organization for example we have tools for static code analysis. I had the opportunity to use such tools in my more distant history.  These were always chosen by someone who really does not understand engineering and just actually looked at the quality of analysis, and did not even consider what experience the developers will have with them, and whether it will be effective or not effective for them to work, and how fast they can actually derive value out of this tool. Today when we choose such a tool within our organization this is one of the considerations, it is whether we can integrate it within the CI process or not, if not then it does not enter In general. If a developer has a feedback loop directly when they write the code, if not then we need to think if it's a tool we can reconcile. So it starts with thinking if you want to give developer experience priority of consideration and it's both a combination of choosing the right tools and also prioritizing tasks, it's a combination of these two things.

Yishai: Who do you think is the owner of the developer experience? Is it the engineering manager? Are they the owner and the one who will lose sleep at night if the developer experience is not good enough or there is someone else?

Adi: So it's clear that in the end––the organization does not really care about dev experience, I can’t really tell the VP Marketing why don’t you care about the developer experience? Obviously it's my responsibility, but to me, it's also my place to give legitimacy to each of my developers on a daily basis. Because if you come across something that you do over and over and over again and it takes half an hour each time, and we can spend two days and shorten its time. It is not only legitimate It's your responsibility to take and escalate it, because I do not know all the tasks you do every day and there is not the ability to do it, but if you raise the flag and say it 'I must put in the next sprint or as an upcoming task because …’ To come up with this justification that says I will invest two days and I will save after that, what ... half an hour time X how many developers, and that is a conversation that is easy for us to have with product and understand where it comes in as a priority, it is the job of each developer to raise the flag.

Yishai: So looking at the developer experience in a very similar way to Waste, I see something that is ineffective so I will raise it, and ask to invest in solving it and resolving it. Are there places where the developer experience goes beyond Waste? I mean not only did I save X times Y developers but it touches things I can not immediately justify through time or efficiency? Because what is easy to sell to executives––yes, it will save us a lot of time and we will achieve more, what is harder to sell to executives is that it will make my life easier, it may prevent mistakes.

Adi: Yes, but to prevent mistakes is a great justification, it raises the quality, it is to prevent human errors, it has a certain justification.

Yishai: or "It’s killing my sanity to do it every day, save me from it somehow, find me a tool that will do it for me" ... Not all things translate straight into a waste that is easy for you to justify.

Adi: Right, here I think this is often the place where programmers are less empowered with explaining "killing my sanity" is an argument that we do not know how to prioritize over waste or business value or security right? It's like a conversation we can’t really handle, and it's often the role of engineering managers who need to specialize in how you "normalize" the sentence that a developer says, sometimes says "it’s killing me". Sometimes they will tell me it is not a best practice but they say it's for some reason, they will always say it’s for some other reason. They never come and say something like "this is what I want". I feel great, let's have a hackathon.  I want to write in Haskell in production now, so I will have a hackathon and write something in Haskell  and it will be cool. But If there's a good reason, a best practice often what sits behind the good reason or "it’s killing my sanity" is many times I just do it all day, the same monotonous work and I can do more things instead. And if I automate it now, then I can do even more stuff instead. It's a reason and it's our job to help normalize it.

Yishai: Do you find or see developers who interview the company about developer experience as part of their choice of where to go? As a major consideration whether they are going to work for you or another company? Because once many years ago there were the 12 points of Joel Spolsky that he actually published. I think this is the beginning of the developer experience as a mindset that people check if the company they are going to work for, how many points it got from the 12-point system, and according to that decide whether to work there or not.

Adi: I see senior developers who say if I tell them that now that they’ll work in three-week sprints instead of continuous deployment, then they will say no thank you very much, this is not the company for. I do not know if you include that as a developer experience.

Yishai: Partly, certainly, is the fact that there is a CD or close to it.

Adi: Or that we’re getting there, okay even if we’re not quite there today, but we’re getting there and not that it is fine and dandy to roll out versions 

Yishai: Spring Version 2022.

Adi: Spring 2022 is true (laughs), yes I’ve see such.

Yishai: It's a stopwatch you say.

Adi: Especially with the more seniors, because senior developers in the end also have a preference for how they like to work and with which tools, now this love to work with certain tools or in a specific way, we sometimes paint it in a bad color. But the good developers know what helps them to be effective, it's what helps them get into the flow of their work because it what they are familiar with.  In the same way that  I know to explain why developing in concepts based on Dov Hobbes' worldviews produce a better product, I know to explain it because I saw it in practice, and I saw when it doesn’t work that way, and the difference between them.

Yishai: Have you seen organizations that somehow manage to measure the developer experience directly? Say I was here and now I'm in a better place? Or does it end up translating only into waste or efficiency of work?

Adi: So there are two primary things I managed to see as measurable, where one of them is attrition. If you see attrition of people, it can be either when you understand this is someone who just wrapped up their tenure, and wanted to move on to something new, and had nowhere to progress within the organization. Or whether it is things like burnout. Burnout is completely due to recurring production problems, where you get up every day at 2AM to fix something manually instead of taking care of it, which is also in my eyes in the extreme of I have no experience.

Yishai: I don’t want to admit it, but I dealt with problems all day.

Adi: And I also get up every day at 2AM to take care of something that I can spend a week on now and fix, instead of getting up every day at 2AM. That leads to crazy burnout. Secondly is performing surveys, where you survey once every six months or so, or once a quarter or once a year, your engineering organizations and see the trend of improvement. Invest in surveys and you’ll see the trend of improvement, it's not something you can see on such a day-to-day level changing, it does not ...

Yishai: Do you see value in producing any gold standard? Here are the things you should strive for in the worlds of Dev Experience? Part of what you spoke about with regards to CD,  or what my cycle looks like, and how to get things into production. Is there any logic to distilling it into ’this is the golden list’ and if you are sticking close to it you are in the right direction? Or it's really every organization on its own and every case ... there is no such thing as that ... there is nowhere to aim.

Adi: That's a good question, I'm like I have my list that works for me... either where I aspire or where I want to aspire.

Yishai: So what’s your top 3?

Adi: Okay wait (laughs), I think my top 3 is getting to the place of being able to do CI/CD automation, where I have tests and everything sits in the right system, where basically my engineering process protects me, helping me actually get to a place of actual autonomy and independence for developers by exposing them to professional business knowledge related to the company as much as possible, that are also related to other teams that help them make the right decisions every day. Likewise the ability to be effective, the ability to actually know at any given time what my team's goal is and how things I do affect the entire organization, and in my eyes it produces a very, very important value and meaning for people.

Yishai: Push the context as close to the developers as possible. In the organizations you manage, do you manage  to reach a situation where developers talk to customers?

Adi: It depends (laughs), I'll tell you why I say it depends, because there are situations where it's a bit sensitive that developers will talk to customers, but totally that developers should hear conversations with customers, sometimes put developers in conversations with customers in a situation that the customer really wants someone to say yes about something, or that a customer comes to come down on the company and then putting the developer there is not always fair. In the end we do not grow up in a world that knows how to deal with customers, in the form of managing complex situations, so there is something unfair. But totally listening to customer conversations, participating In customer conversations, supporting customers directly, yes it sure is a good idea.

Yishai: And do you see that you can do that at scale as well? I already have 100-200 developers - can I still create this direct contact for some cases?

Adi: Yeah, yeah, totally, I think it's priceless because in the end when I'm developing something I do not know who uses it, what it looks like for the end user. Sometimes something that seems to me not bad at all, it shocks a person to see who uses my system, and after I see how someone really uses it or really talks about what they’re doing with my system, it becomes a game-changer in my mind for how to develop things.

(Music)

Yishai: So before we wrap up, I would love to hear from you maybe one or two tips––if you have a hard time choosing––the same developer who dreams of being a engineering manager or a team manager who just landed their engineering management position, one tip on what to focus on, how to swim in this deep water.

Adi: So I think I will split this into those who are not yet in the position and to those who are not in the position, to those who are not yet in the position and want to go to such a position I would recommend they always try to ask for the next task that can advance them to their next role. The task that will help you get there. And for whoever is in such a position, whether you chose it or there was no choice– this also happens sometimes. And even though you chose to go into this position, I think it's an amazing role. I think the fact is I chose to do it for the fourth time. Create a personal advisory board for yourself, such a group of people you can consult with who are from outside of your work, who are friends, who will tell you the truth about things, who you can consult with on issues related to your personal conduct or things in the industry, and so from time to time get help from them.

Yishai: People who are themselves engineering managers? From such a buddy-system (members of the system) or not necessarily?

Adi: So it does not have to, it can, it is preferable to have such but there should be a group of few people who will be people who can give you greater context, because sometimes I’m so deep in my own world and sometimes other people help to give me context, wait - it works this way for me too, and that way is okay , and it will work out soon, because it's such a phase, and it'll be resolved any moment. So it's great but also to have people to talk to are those that are peripheral to our job, from product or marketing or senior developers who can thus complement my knowledge and help give me a different context.

Yishai: What about one piece of advice for people who work with engineering managers, those who report to an engineering manager, whether it's CTO or CEO or people sitting next to engineering managers at the executive table, one thing they need to remember to work better with engineering managers?

Adi: I think maybe one, always give the engineering manager the business context of the things you ask for, I mean do not come and say do it for me 'like this' or the engineering will give me a system that only “does this” but also the business context, what customers want , what market do we want to penetrate, as much context as possible is very very helpful.

(Music)

Yishai: Thank you very much Adi, it was wonderful to host you in the first episode of Pituach BeHafraa - Dev Interrupted, the LinearB podcast, was wonderful.

Adi: Thank you very much, thank you for inviting me.

Yishai: Goodbye.

(Music)

Yishai: Thank you very much for joining us for the first podcast, more episodes coming up real soon, go to devInterrupted.com to sign up, you will also find all our episodes in English there. I remind you that we at LinearB are growing rapidly, recruiting for a variety of roles in all areas, visit linearb.io/careers to find your next challenge. I'm Yishai Beeri, until the next episode.

(Closing music)