Congrats! You’re a Unicorn! But wait till you hear about these engineering challenges, Karni Wolf and Daniel Korn

Episode Transcript תמליל הפרק

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

(Opening music)

Yishai: Welcome to the Hebrew version of Dev Interrupted, LinearB's successful podcast for development managers. Here we will talk about everything that hinders development managers. I'm Yishai Beeri, CTO at LinearB. With the announcement of our big funding round, we are excited to bring you the podcast in Hebrew. We will host leaders from the industry to talk about everything that hinders development managers, those who work with them and those who want to one day manage a development organization. In this episode, we host Karni Wolf and Daniel Korn. Hello you guys.

Daniel: Hello.

Karni: Hello.

Yishai: What a pleasure to have you here. So Karni is the director of development at Snyk and Daniel you are the director of engineering at Lemonade, tell me about the journey you took in your career, Daniel we’ll start with you, how did you get to this point?

Daniel: You can say that I started my career at 8200, with another permanent service in addition to the regular service, from there I did a degree in computer science at Tel Aviv University, and while doing so I started working for Red Hat, a company that sanctifies open source and free software. I really connected with the idea and I thought that this is the place I want to be. I was there for a long time - after that I did a period of freelancing and I was a kind of contractor. I moved between all kinds of different Israeli companies. And from there I moved to a small start-up at the time, today it's already a unicorn, I guess we'll talk about it, called Big Panda. I was there for around three years in various positions, after that I went on to Lemonade. I started there as a team leader and at some point I advanced to the position of director of engineering, which I do today. I actually lead the group for our car insurance, the last product the company launched, a relatively large launch, and we are developing an interesting product.

Yishai: Cool, we will dive further into the questions that arise from the rapid growth of companies or the transition from companies of different sizes, so you have given us material to talk about. Karni?

Karni: Yes? So I don't know exactly where to start, but I was also in military intelligence, not in 8200, more in the field of mechanical engineering. It helped me to know that it was not for me and I studied computer science at university, bioinformatics at university. I started to get involved in communities, so I was very involved in the establishment of she codes; in Be'er Sheva and later in the whole country. Then I started working as a developer at Dynamic Yield, and after Dynamic Yield, for a period, I also worked full-time at she codes;. After 4 years of volunteering, I became the CEO of the organization, but I decided that my heart really belongs to development. Today, so I'm approaching 4 years at Snyk. I'm one of Snyk's dinosaurs, because there aren't many, from the rapid growth, there really aren't many people who have been at Snyk that amount of time. Today, I'm a team leader. After about a year, I became Snyk's team leader, so today I am managing my second team. I decided to stay at Snyk and diversify the role. I moved to another group, another field, another product. This is part of the - I think - one of the advantages of a company with rapid growth, all kinds of different options within that company, and I enjoy the advantages of both new and old.

Yishai: And it's no coincidence that both of you are guests together on the podcast, so tell me a little bit about how you met.

Karni: Yes, this is also where the community comes in, which is a strong element in my life. When I took my first position as a team leader at Snyk, I did have management experience in other areas, but not in development. At Snyk I started managing, and as part of the activity in the Baot group on Facebook, which is a community of women in development, for those who do not know. Dafna Rosenblum, who is one of the founders of the community and its manager, advised women at the beginning of their careers in management to consult mentors, and then she introduced me to Dafna who worked at Big Panda then with you, right? Then she introduced me to Daniel and from there we met once every two weeks for a long time. We developed such a relationship, that we had really interesting conversations, both sides I think, and that's where it started, with the confusion between Karni and Karni.

Yishai: (to Daniel) From your side, what does it look like? What...tell the story, your record.

Daniel: The truth is that it's the first time I'm hearing the story from Karni's side. When Dafna approached me then, it was the first time that I did.. that I got to mentor a development manager or manager, and I didn't really know at the beginning how much I could really contribute. Very quickly, I think, in our meetings, I felt that I was learning a lot from Karni and that it became such a very fulfilling relationship. So later on it was also very clear to me, when I thought it was right to establish some kind of community for development managers in Israel, there would be no better partner than Karni to do that with, to work together with her, and happily she agreed. So roughly a year ago, we started Engineering Managers IL. It's actually our community and the name of the group on Facebook, a group that is for managers by managers, completely voluntary, and basically our goal there is to share knowledge, doubts, as much as possible. It's an open place to ask questions and get advice. We're happy to share, to let members of the community share about the things they are doing and also organize a physical meetup every month or two, each time from a different place, for members of the community to also talk.

Yishai: Karni, how many members are there in Engineering Managers IL?

Karni: Wow, good question. Close to 1,000 maybe? 800, something like that.

Daniel: Almost 800.

Yishai: And this is a community that you actually founded in the midst of the Coronavirus.

Karni: Right.

Yishai: Tell me a little about the experience of establishing a community while everyone is isolated and non-communal.

Karni: Yes, I think this is what also helped us even be successful, because everyone is isolated, but every time there is a decline of a wave everyone is dying to go out and meet people and also disrupt their professional community. So it helped us, of course. There were also meetups that came, fewer than we hoped, expected, and all kinds of times we wondered if it was the right time to meet physically or if we should still do it virtually.

Yishai: Did you also do virtual meetings?

Karni: No, we didn't, a lot of people ask us and always say, “is it recorded?”, “will it be zoomed in”, and many people also have difficulty with the times or the location we offer for our meetings, but really this is our main element. There is a lot of content on the internet to consume and many ways to consume it. That is of course also part of it, to consume such content, but we believe that the benefit with us is the face-to-face meetings, so it is important for us to keep it there.

Yishai: And what do you feel that, apart from the desire to meet, and an informal exchange of experience and knowledge, are there any issues that come up? That the community is thirsty, want to talk about them? Common challenges, are there any themes that you manage to extract from what you see in the community?

Daniel: I think that once in a while there is a topic that comes up and generates a little more buzz. I think that around hiring we had quite a lot of content and questions. Also management dilemmas - the whole period of the coronavirus raised a lot of questions about working from home and how do we keep people engaged and how do we solve these problems. Maybe it sounds a bit like the topic that has been discussed, but at the beginning of it, a year ago, it was still very much in its infancy and people really wanted to share and hear how others deal with it, so it's also a topic that was strong in the community.

Yishai: And in terms of the people who participate, who are active in the community, do you see mainly team leaders? More senior managers? Is there any sense of who is joining, or who is participating? More experienced people? Juniors?

Daniel: I think there are all kinds of things. We had lecturers who are very young team leaders and a VP R&D very well known in the community from different companies, so really everything. And it's always fun to know that you can give a platform to even less experienced managers and then see the feedback and how people receive it.

Yishai: Wow. So Karni, you touched on Baot and spent quite a bit of time on shecodes;, so are you still involved in these communities as well?

Karni: Yes, so also in Baot I manage with a community partnership of female managers, so I have two parallel communities and this community. At our first meet up I laughed about the fact that this is the first time I managed a community with men, or that is open to everyone. Yes, and it's different and it's nice, but I see the advantage in both of these and each community has its own nature and its own characteristics and its own atmosphere, which is a little different.

Yishai: And do you see over the years that there is really a shift? she codes; comes to promote the entry of women into the worlds of developers' content? If you look back now - 4, 5, 10 years - do you see a change? Does it work? Are we moving to the right place?

Karni: I believe it is. There still is, I hope not always, but there is room for improvement. But in general, the fact that we now have, we have our community, I think that our community is special in that we bring this to the forefront. And right now in most of the communities I know, it's either women's communities, or sometimes it's predominantly men's communities, and it's not really balanced. There are several other open source communities including the Pull Request community that is also led by women, but I really, really see the difference between communities where women are involved in organizing and leading and communities where they are less involved.

Yishai: What differences do you see?

Karni:  It really comes out by itself. If it’s important to her, or if it’s important to him, then they will influence this and make the community look different. And whether it is in the female speakers that we bring to the meetup, and it is important to us that there always are, and if it is the speech, both the actual words and the content, that we preserve and the culture that exists within the community.

Yishai: So in such communities, more parts of the community feel comfortable in the meetings, in the content.

Karni: Yes, that's what I hope. That's how I feel comfortable and that's really one of the things that's important to me, that first of all I'll feel comfortable and that's how I'll find the way to make others feel comfortable too.

Yishai: And this community activity, how is it received, or if I look at the company, the companies you work for, how do you treat this activity? Is this something good? Something nice someone does on the side? Is this something that is perceived as a value that you bring back to the company? To what extent is your company interested in it?

Daniel: The truth is that I try to make a relatively clear separation between working at Lemonade and participating in the community. It's true that we hosted the first meetup at Lemonade, so maybe it didn't seem that way at first, but for me personally it's important to maintain some kind of separation and not feel that the community is so powered by Snyk and Lemonade, so that's the first thing. We do get to share, I think, in the group, a bit of our daily lives, so yes, you can learn about the companies we work for. I think it also gives back to our companies indirectly, through the fact that they know that the audience of managers and development managers in Israel know that there are people in Snyk and Lemonade who care and also want to give back. It's also through the things they hear through the content, it makes these communities a little more accessible to managers in Lemonade and Snyk to come to meetups. We do see them arrive, and then very good connections are made, they understand the importance of being part of the community.

Yishai: But the meetup is not a recruiting event for...Lemonade or Snyk.

Daniel No, absolutely not.

Karni:  It's interesting, because specifically for me, at the beginning of my journey in the communities, it was really important for me to separate, and I was always asked “are you the VP of she codes;?”. So, when I became a VP they were so enthusiastic about it and I constantly tried to silence it and separate because I didn't want to. Maybe it had to do with the interview I had here.

Yishai: Here in the building.

Karni:  Yes, here in the building. In the terrifying interview, I was here without development experience, but I was active in she codes; and then he made, the interviewer made me feel that I care about what I do in she codes; and what is that relevant to me? So since then I've really made sure to separate, and over the years I separate less, because I understand that it's just me and I manage development, and I also develop, even if not full-time at work, and I manage a community, and that's just who I am. For the element that it won't be powered by Snyk it's clear , but from the point of view of how it is perceived at work, over the years I am less...

Yishai: You stopped hiding the...

Karni:  Less of a secret, yes. There's nothing to be ashamed of, but I don't want it to mix with me, and over time it's less critical for me to separate, because I understand that it's a value, and it also gives people within Snyk value, to understand that we are part of a larger community of development in Israel.

Yishai: I see more and more that companies are interested in these questions and push and encourage the employees and developers, to participate, to speak. This is of course good for the brand. It also helps people in their careers, with exposure, so do you see it in yours? Do you participate in the process of encouraging people to go to meetups, talk in them, generate some talk about some solution, a problem they solved? This is something that interests you, because now I am actually asking as managers, not as community activists, but you have people who can do things in the community.

Daniel: Yes, as part of the growth trajectory of the developers in our company, we offer the option of improving writing or expression in writing, publishing blog posts, participating in podcasts, delivering lectures at conferences, and basically we offer this encasing to those who are really interested in it. So, help in the initial ideation process, to help design the outline. Of course, in all the things that are around and also before conferences, before there are professional conferences, we try to do a little more think-tanks and demos and things like that, so it also happens in the company and I think that, as you said, the return on this investment for companies is, it is difficult to measure it directly, but it is manifested.

Yishai: So here your experience as a regularly active person in the communities surely helps you to promote it internally, even if you don't come with the hat of the specific group, you know this umbrella.

Daniel: Yes, as soon as -, I think that as soon as people in our company see other managers, hear about our activity in the community from other members of theirs or people who come to be interviewed as a result of this, then they understand the importance. And also people who come after they heard a keynote lecture from a person who is very talented in a company that usually does this. And then people come following who simply want to work with him, that's what interviewers hear, so there is value here.

Karni:  What I like about our company is that there is some kind of sub-community of such encouragement within Snyk, of people who encourage each other to submit and give ideas for conferences and meetups to participate in and give this internal feedback of “I know the work”, “someone consulted me about some CFP he wanted to submit and he asked me, “does that make sense to you?” Because I know his work and I also know the conference, so many times people have ideas, and they just need that extra push from people who know them, colleagues who believe in them, to do that little push and bring their voice to events and conferences.

Yishai: Like a circle of encouragement around these issues in Snyk, of wow, that we saw, that you spoke somewhere or that you presented something and they give you a pat on the back.

Yeshi: Ok, let's talk about the challenges and the process of a fast growing company. Karni, you have been at Snyk for a long time, from a relatively small company to a unicorn, a company with large development teams. Describe to me a little about this dynamic and how life changes when a company grows at such a speed, how does that impact you?

Karni: So I think the part, there are two main elements, the culture part, both the work culture and the development culture - as they like to say engineering culture - which changes over time. I don't know what the other thing I wanted to say was, but it will come. But this thing that Snyk is a company that I joined when it looked a certain way, the product looked a certain way and the code base was a certain way and the set of features or functionality was a certain way, and it changes very quickly. And I have to find my place within this company, my team that I manage, suddenly the dynamics change, the expectations. From the external interfaces, things change fast.

Yishai: Can you give an example of something like that which has changed?

Karni: Yes, I just talked to a team member I recruited only 3 weeks ago and told him, we are working on a big monolith D-com project right now and I talked to him about the fact that when I joined all the developers could all review this specific code base, and now it's impossible to comprehend at all. And I told him about the process, about how we started with writing it, to divide code ownership within the company, in this repo...this monolith. And actually he asked me when it was - it was in July 2019. I remember we sat and wrote, we literally went through files and distributed them among the teams, and it was actually not that long ago, like July 2019 is right. It's been 3 years and everyone likes to say why didn't we do away with the monolith? Why didn't we dismantle this monolith 2 years ago, but only 3 years ago it was still in everyone's ownership.

Yishai: What was the trigger? I'm interested in this issue of deciding that only certain people will review areas of the code.

Karni: The trigger for that, yes, it was that little by little people had less knowledge, the functionality of the system grew and we divided, I believe we were about 5-6 teams then and not everyone had the knowledge of everything and this, this shift in understanding that it is impossible for everyone to know everything, and there needs to be a more defined ownership and everyone's ownership, you know for sure, many times it just turns out that there is no ownership of all kinds of things.

Yishai: How was it expressed? They did a bad review and there were quality problems? Or no one did a review because “I don't know, so I don't touch” and he doesn't know he needs to?

Karni: I think there are always people like this and people like that, which is the same problem in a different way. Some people will do a review, overlap or miss things, not with bad intent, and some people will be afraid to touch, yes? Especially if it's a database migration.

Yeshi: Today is Thursday, four in the afternoon, it's time to do a database migration. I mean, part of the growth is that suddenly not everyone knows all the code. It's one thing you felt and solved in the first step by code ownership and today you are approaching another step of dismantling this monolith. So it's like a situation that results from the total number of developers touching the codebase and their ability or inability to encompass the knowledge needed to approve changes to the codebase. Daniel, what did you see as the, how is the challenge expressed ‘that of a development organization that has suddenly grown a lot?’ Where does this suddenly create blockages, or challenges in your work?

Daniel: I think there is. It can actually be divided into several various areas. I think that Karni really touched on the professional work on a daily basis, I think that this is also expressed in how you maintain a certain culture, how you succeed in recruiting people who can add to the existing culture and work well with the existing employees, how you communicate. I think that maybe this is not a topic that is talked about enough, but how does the communication hierarchy work in the organization once you want to make some kind of big change? It can be a technical change, it can be a structural change, in the way you work, the workflow of the developer changes, the development environments become remote, how do you move it forward, how do you train people and make it clear to them how we want the design and architecture to be? So, we all one day moved to microservices, how do we now make sure that developers know that those services should really exist, stand on their own, and how do they understand what that means, what's going on during the deployment? Then there are many things, there is a lot of that knowledge that needs to be transferred, so this is a second issue.

Yishai: And the challenge of this size is simply how to reach everyone? You can't put everyone in the same room and say “guys, from today so and so and so?”

Daniel: Yeah, so I think it doesn't work for two reasons. One of the rooms is becoming really, really big. When I joined Lemonade we were around 40 developers and we all fit in the attic of the Templar building in Sarona. Today, there is no room in the company that everyone fits, we haven't been there for a long time, in bigger rooms, but it can no longer work. And beyond that, many of the messages are a little more complex than something that can be conveyed in a presentation and they require a little more training, perhaps some kind of hands-on work. So, I think the more correct way to do it is to make sure that there is a hierarchy of information transfer. This could be through technology leaders who are in the various groups and are responsible for certain fields that can transfer the training or be points of contact for the various developers or use different methods, but such a one-of-a-kind lecture, I think it doesn't work beyond a certain size.

Yishai: You are talking about questions of how to work, or the way I look at it we call it development workflow. There is some kind of tool that is more or less known, less or less written, that says this is how we work, this is how we make a change in the code, definition of done, what is required so that will happen, microservice, or how we want to work. Are you talking about some kind of hierarchy of instilling it from above, or are there other ways? Are you of a certain size looking for how to make it more democratic? Say, each team will choose?

Daniel: There are things that are really up to the teams to decide, things that they choose. But it was important to us to keep the dev workflow broadly in terms of a fairly uniform definition between the teams, so I don't think it's really an imposition from above because these are things that are talked about and each and every developer has the right to make suggestions and improve. But, there is the right forum to bring it up. If it is the professional guilds or even the guilds of the business domains where you can do all kinds of things or other forums, if it is forums for more senior developers, for our staff plus engineers, where you can go to change such processes. And I think it is constantly evolving, and what is important is to have the right channels through which to transfer the information to the various people in the organization. Starting at a certain point, we started working with very organized design documents in a certain format. It may sound simple to tell 200 developers in the organization now that from today, features starting from a certain size or amount of time, they start writing with full design documents.

Yishai: We were just waiting for you to tell us to do it and now, thank you, we can.

Daniel: Yes, and now they will do them. They will fill them out exactly as the person who wrote the format expects, and of course they will also publish it and wait for feedback.

Yishai: The code is already written, you are welcome to give feedback.

Daniel: Yes. This is just one example but...

Yishai: So the advantage of relatively uniform workflows is that a developer can move from team X to team Y at the other end of the company and feel that the whole thing is familiar to them. Maybe they don't know the code, but they know the documents, the form, the approval method.

Daniel: Right, so beyond really permanent mobility, they can also move there for certain projects or even to join the design process of a certain feature that interests them to study in some technological field that is new to them, and I must say that one of the characteristics of rapid growth is that the teams are constantly moving and they change, so one day you can be in some area, but tomorrow the business dictates that this area is a little less important or you need to open some kind of group. A developer moves from a position to a management position and now they have to manage people, and if they work in the same method he/she worked in, then it at least makes it easier to get into that position. This is another advantage.

Yishai: Yeah. Karni, when you look at a company and a development organization that grows and sometimes grows fast, how does this affect the structure? On the structure of the development organization?

Karni:  I want to take a moment to comment, but still something interesting about the uniformity. I think that at Snyk we paid a lot of attention to uniformity, and, over time we loosened it a bit. I don't know to what extent this is intentional. Part of it is due to acquisitions of companies and it also spilled over to other technologies with the understanding that we really wanted to stay in a very specific stake. Let's say we were only using Typescript and almost nothing else, and recently we are also doing, writing more in Ghost, just an example of technologies, because it seems to me that at some point it is impossible, because the size of the development is large and there are different needs and there are different groups. The challenge is to maintain uniformity and yet give some space, room for movement to the teams.

Yishai: So this, this uniformity, you talked about the stake. What about how you conduct yourself between the sprint and the kanban?

Karni:  Also, yes, because in the end it's important to give people autonomy. I think uniformity is needed, but people need to feel some kind of autonomy of the operating space in order to feel happiness and satisfaction from work and productivity, and sometimes it takes different forms, it also sometimes depends on the time zone. Snyk has been very focused on the Europe-only time zone, recently we had all the acquisitions in the United States and Canada. It changes a bit and you have to work with it, I think there is no choice.

Yishai: So, who really looks at the issue of how the development organization is structured, what does the rapid growth do to the structure?

Karni:  So, there was also a phase when they suddenly realized that they needed to recruit directors, let's say. I remember that too, and there were many team leaders from Snyk who wanted to be directors but there was an understanding that they also needed to bring in experience from outside. It's not just in development within Snyk, it's in many bodies within Snyk. It's also a challenge, in hiring actually, how many are brought in from the outside and how many are brought in from the inside. And also like with everything, you need some kind of balance, and we've grown from several teams that all touch the same codebase to groups and departments, and it challenges and we make changes and optimizations every so often. It's not new anymore.

Yishai: But are you talking about adding another layer? Or we changed teams to squads from product responsibility to technology responsibility.

Karni:  Yes, both. Then we also added another layer; the first layer was groups, then we also added a layer of division, department, but also of area of ​​responsibility. So, if once all the teams were actually product teams, each team had a product or a very focused area, a product delivery, of value to the users, to the users of the product, and slowly we opened platform groups and infrastructure groups of 10 people. Not that we didn't have it at one time, to understand more, for the use of the development organization, and not just everyone doing everything for themselves from A to Z.

Yishai: So, they produce some kind of specialization. So in the original groups there was also a frontend, a backend, all the capabilities, and it slowly migrated to a group that does the UI or a team that does the UI in across...

Karni: Yes, most of the teams are still full stack, with one focus or another, but there are also teams that work really only on the front end to make the front end more useful and efficient for all the developers in Snyk.

Yishai: Daniel, how does rapid growth affect working with stakeholders outside of development? Your work as a manager is in front of product, in front of even marketing, other bodies that are not under you or right inside your organization but you have to work with it.

Daniel: So, the truth is that it is somewhat related to the previous question, so I will, I will just explain for a moment how it was built by us and what happened in terms of growth of the structure and how it relates to work with the stakeholders. So at the base we have squads, teams that are completely autonomous, contain all the technical capabilities to devise the initiatives for the OKRs that are defined for them, and these squads also contain product people. And it menas working very, very close together. In the end, we are a product company, a B2C company, and also designers; quite a few of the squads are designers, analysts, QA people, so that's really the basis. When I arrived, there were 4 teams divided by regions in the system, there was one product, and as we released more products, more insurance products, each such product was quite independent and had its own needs and was in different stages of maturity. There are products that are still in the phase of very rapid growth, trying to move from zero to one, compared to products that are a little older, where you can do all kinds of optimizations to bring them to higher profitability, significantly improve conversion, which are much more A/B testing, all kinds of areas. So each product has its own challenges, and therefore at some point, Lemonade moved to a structure within R&D, a structure of companies, basically, the whole company moved to a structure of companies according to the different products, so in those terms I am in the car insurance organization, our latest product, and we also have home and pet. So, within the company there are all the relevant functions, marketing and operations and compliance and customer support and the group that actually handles claims, including the development group. This is the tribe that consists of squads. Some of the tribes that have domains are several squads that are joined together around some topic and each of these companies is much more oriented towards its product. There are the goals of this product and not just the general goals of the company.

Yishai: And the choice of the company name is because there really is a profit and loss for this company?

Daniel: Every company really operates, it has its numbers. Of course in the end it translates, it's a public company and in the end it reports, so every company, then in the end everything is reported, also together as in Lemonade, but literally every company has the, we measure the IFP which is the In Force Premium, it's some kind of measure of insurance, but the sales is compared to the spend and all the other business parameters are really part of the company.

Yishai: So that was my next question, about how to take advantage of the collaboration. Before you talked about infra, which is services for the company, but there is also full, I imagine interactions between areas that are in your company versus another company, that there are cross-sales and up-sales transitions even for example. But even at the technological level, in the end I as a customer, I as an assistant, must see one uniform picture.

Daniel: So we have, we really worship a concept called multi-product. It's actually capabilities that are shared by all kinds of different products. So, for example, the handling of claims in the company is done, there are many things in it that are done in a very automatic way, in all kinds of experiences that we know how to give the user. We handle 30% of the claims that are filed automatically, and behind this there is a lot of knowledge and heuristics that we do want to share between the different products. So for this, first of all, there are guilds that are around domains, then there is a guild that is really focused on claims, lawsuits. There is another guild that is around risk, within these guilds there is a lot of coordination work, and to understand what the challenges each of the companies are dealing with. And are there things in common that can be built in the corresponding team on the platform, that's one point. Of course, knowledge is also shared between them and there is this mindset that when we build some feature in one of the companies, if it's a feature that can be relevant to other products as well then we usually don't build it within the microservices relevant only to my companies, but there are services that are shared and there it is possible, actually there is this concept of features that are product agnostic, they just fit into...

Yishai: So I will ask how this mind set is produced and how it is maintained when the company has goals and it will take half the time and half the effort to implement it within the microservice, and I can move faster with the narrow view of how this company is run. How do I preserve that anyway? I mean, it's against the apparent nature of all the stakeholders, OKRs, incentives, the whole idea is to brainstorm at the campaign level, how do I make sure I don't lose that collaborative mind set?

Daniel: So I think that over time people realize that it won't necessarily take more time to produce something that is a multi-product now, it can serve several companies, whoever has the chance to actually launch a product and rewrite everything that was already written for these products is already a little burnt out, already understands this pain a little, or understands that he won't be able to use the features of other products that have already been developed if he doesn't use the existing infrastructure. And of course, it comes with constraints. I mean, the message gets through. Of course, within the development it's a little less problematic. We also did sessions with product and also with various factors, all kinds of other stakeholders who basically explain how the advantage of building things in a multi-product way is that it may have some kind of cost at this moment, but in the long run it will help us and we are building, if we look at the long term, then I think it is clear for everyone.

Yishai: Karni, what do you see with yourself and Snyk regarding this question of whether it's a company or whether it's a team that needs to do something and has goals, and features, and there is pressure to deliver, to do something that will serve others in the whole company and not directly my organization?

Karni:  It's really a challenge, because you have to maintain motivation, and I naturally think in teams to come up with something specific. I think that something that helps me as a manager is that I look at my team and my group. It is to consecrate and celebrate the collaborations as successes, to say here is something we built together and it made us go further, and not only in planning for the future but constantly thinking about what we are doing now and of all kinds of achievements and successes, to show how what we did together actually made us more successful. And this also goes back to cheering. I think, as in cheering, to encourage colleagues to submit meetups, seeing the successes of other teams and also cheering them on and seeing how it also serves us and how things we do can help others. Something that is really important to us, let's say as a company, as a product intended for developers, its dog fooding, to use the product we write and develop, so it's also something that really helps with...

Yishai: Each group uses everything that...

Karni:  We try. It doesn't always work. We have to, just as we have to convince other users to adopt the product, we also have to convince other groups to use our product. But every time we manage to do that, we're really grateful and we learn a lot from it.

Yishai: So, in order to maintain the motivation and this encouragement of “here, we did something together” and also a second group or another part of the organization enjoyed what we did, you need to choose, as it were, create partners for yourself. It's your peers in other places in the organization who will be with you in this motion and we will coordinate together how we deliver something that helps you too and how we also raise it up as a celebration event.

Karni: Yes, and working on communication and personal relationships, yes, that's part of it, but working together and very, very important, for effective communication, is explaining what I'm trying to do, why it will help the company, why it will help us, why it will help you, trying to avoid language of ours and yours, of course.

Yishai: So really an organization grows fast, and you talked about communication and establishing contact at least with the peers group, which is perhaps scattered throughout the organization. How do you do that when the organization suddenly becomes huge? You don't know everyone anymore, at least by name, and suddenly tomorrow there are 10 new people you need to contact. How do you deal with it?

Daniel: I think there are the forums we mentioned before, if it's professional guilds or forums of the guilds according to the domains, beyond that, in this time of the Corona we had to go through, understand how we communicate well enough through Slack and Zoom. So these tools too, even though I personally don’t like them as much or connect less with them, they can be effective as soon as you manage to understand how to convey messages in a relatively simple and short way, which is possible. Literally anyone can understand it and offer some layers of depth.

Yishai: But you're talking about transferring information, I'm talking about establishing contact. You can transfer information from here until tomorrow with someone and it will be effective, but we won't have a connection that would allow us to do anything beyond the basic, okay, I transferred information, but I don't know him, her, we don't have a connection that would allow us to do anything beyond.

Daniel: So at the level of the personal relationship there are the forums, but with peers we of course have a directors' forum, for example, which I am a part of, and it is, for me, my first team. So it is something that I am a part of and we have a lot in common. We share the same problems. We get to talk and consult a lot and it's a kind of comfortable place where I feel I can vent and also, I mean, they support me there and come to help me there, and it's free of competition or anything like that. It was very important for me to create a leadership forum within my group, which actually contains the heads of teams and the technological leaders, and that they will also feel that this is their first team and will be able to receive the same thing that I feel that I receive from the other directors. That is, people who can always be consulted, who can help, if someone is currently not available then can be a substitute, the way I think to do, to build this relationship. Of course, if it is possible, there can be events like this outside of working hours or all kinds of interactions that are a little more enjoyable and fun. If it is not possible, because sometimes people work in hybrid teams or some of the people are in another country at the time, other timezones, that I think the first is, what I believe in general is my people also know. Of course unless there is something very personal or private t to share as much as possible. I just try as much as possible, that everything I know,hat is better not shared. But actually make them partners, and basically have the accountability that they will feel like owners of this group, and that's how they also care when they see that something might fall or something doesn't work well enough so they will care to come and pick it up or talk to whoever needs to do it.

Yishai: Is this something that also extends to physical meetings? For example, a company that is ultimately international, this directors forum you describe manages to meet also for...

Daniel: Weekly, a weekly and physical meeting, yes, we have it. We have one of our directors, he is in Amsterdam, we have site engineers in Amsterdam, and he came here to Israel and we really had a long off-site with him. But also within my group we have, now we will have a team in Amsterdam, and we will have to find these solutions there as well. Meeting physically is important. I think we need to find more ways to do it, to create these connections even remotely.

Yishai: Yes. Karni, what do you do or they do by you that helps you establish contact with remote people, I'll call it within the company?

Karni: So, first of all I'll take a moment to what you said about the forums, I think it also touches on something that is important to both of us, it's the community. It's actually a community, we also create many communities within work and this space of community, of a place where you can share and talk about mistakes and to understand that everyone has difficulties. It's something that really helps in dealing with things and something that's also important to us, my team, the majority abroad, between several countries - France, Germany and London. I must be missing something now, but I don't really remember anymore, soon I'll also have in Romania and then we are really scattered. We also make sure to meet as much as Corona allows us, so I also visited London about two months ago, and this investment in a physical meeting for me is a long-term investment, because this meeting can shorten all kinds of cultural gaps, gaps that can exist even if we are from the same culture but a little different, get to know a little more, understand a little more who the person is that I work with. It shortens all kinds of gaps, and value we have at work, we call it over-communication. It does not contradict effective communication, it does not mean not to summarize, but it does mean to over-communicate as in if I'm not sure something is understood, what I'm trying to say, I add a little more of an explanation for those who want it. You need to understand this extra and part of it is also to assume that the person is coming with good intentions, and to assume that what they are trying to say is really with good intention and we are both from the same team in the end. The meaning here is not that of the development team, but we both have the same goal most of the time.

Yishai: Let's talk a little about managing up, about our place in front of our manager. In the end, most of us have one of these, and how the work with the layer above me changes, again, in a company that is growing fast or when moving from a small company to a large company. Daniel, where do you see this changing or generating any interest?

Daniel: So the truth is that my manager is the reason why I joined the company. I came half by mistake and Erez is the one who convinced me to come. I think that for a long time in my previous position the domain was wide enough for me to feel that I was really managing up and basically asking my manager for the things I need or raising the issues I want to talk about, whether it's in one-on-one or meetings with the other team leaders. So it’s some kind of process that happened and I think that the more maturity you gain in management, the more you understand what things you need from your manager. Upon entering my position, to the position of director, then another vertical management function was actually given to me, which is my company leader who already also holds the business hat, and actually it was something I had to teach myself how to conduct myself in front of her. I mean, it's no longer managing up, It's more to pull from her the things she needs from me or that the business currently needs from me, and with whom it is important to her that I work in the other groups to promote the campaign. It was a slightly different challenge to step out of the engineering and R&D area for challenges that are more business-like and collaborate with functions that I haven't had the chance to do before.

 "I think that the more maturity you gain in management, the more you understand what things you need from your manager."

Yishai: So I think that part of what you see when you grow up and when you take a more senior position in a growing organization, really this reversal that I don't just try to understand what I need from my manager, but I have to ask what he/she needs from me, there is some kind of reversal here in the end. I need to be proactive and know what he needs, what she needs to promote the goals they are in charge of and how I can create for her and for him, in this area. How does it look to you Karni, coming from a company that grew very quickly, how did your relationship and the dynamics of working with your manager change?

Karni:  So, first of all, there are many more interactions, there are many projects that cross the development organization and you have to take part in a lot and it is my joint work together with my colleagues and my manager to prioritize all these projects and to understand what part, we as a group, is important for us to take and what part is important for us to bargain a little more. Maybe we should actually contribute less there, maybe we should focus our energies in another area. And another interesting thing for me is the ability to bring the domain to the management, because the more layers there are, which is what happens when the organization grows, there is a natural distance, there is nothing to do, and learning to read and understand the domain from development and upwards, this is the greatest value - one of the greatest values - that I can bring as a development manager for my manager and for human resources and product and any function in the organization.

Yishai: Which in my opinion is an excellent example of this inversion, let's say to be such a kind of feeler or filler, to what is happening in the field. It's usually not part of the job description and part of the regular redemptions I get from my manager, but to recognize that it's ultimately something that the management needs. I can provide it and I can seem to help because maybe the development manager doesn't have an OKR for employee retention, but higher up there is such an OKR. There is someone who does care and wants to know that the developers are happy and the way to do this is create this visibility. It is very difficult to do a top down and say let's look and I will try to understand what the feelings are on the ground.

Karni: And it's critical to productivity and delivery and everything.

Yishai: Unequivocally. I want to touch very briefly on the questions of recruitment and it is clear that recruitment is always difficult. Employee recruitment, how is it different or more difficult or easier when in the background we are talking about a company that grew quickly, whose size six months ago is suddenly very different from its size today. Karni, how did you feel about that?

Karni: Yes, recently someone wrote to us how long should pass before I should stop answering yes to people asking me “Hi, I don't know you, are you new?” So they answered him, new to Snyk, at work.

Yishai: Like a new immigrant.

Karni: Yes, like a new immigrant. Like how long my parents, who are here for more than thirty years, are still new immigrants, yes. But then they told him 3 months. I don't know, but for me, in my team, I need to let it go because whoever joins the company doesn't matter. It doesn't matter how long they've been there. Whoever is there is there and needs to be taken… because we chose to accept and wanted to recruit you, so you're here, so come take part. We'll learn how to participate in recruitment processes and everything, but we try to share from the very beginning and to release even the people who joined the feeling that they are new or that they know less because the veterans know more. Because they don't necessarily know more. They have a different angle and you have to take advantage of the angles of the whole spectrum, in my opinion.

Yishai: So you're saying, from your point of view, if I imagine this, this growth to, I don’t know, an increase in some slope, then the fact that we are now in the middle of the increase, as someone new comes, they ignore it. Come on, you're with everyone.

Karni:  Yes, you should be nice, not demanding, be very patient, but not make any sort of separation between newcomers because...

Yishai: Because everyone is new in the end. And for you, Daniel, how does the fact that we are in the background of rapid growth, how does it affect the effort to recruit and engage employees?

Daniel: So I think there is a collection of challenges here. If we look, for example, at each part of what is called hiring, then I think the first thing we realized is that each such group, each company has its own challenges that are a little different and also require slightly different developers to manage this whole thing, and we moved to the management of the hiring within each of the groups. I mean, each one is supposed to recruit for themselves when there is also some kind of general recruitment, but by and large build for themselves the pipeline of how to actually bring in candidates, do the recruitment process and then actually do the on-boarding for them. Here too there is something in common.

Yishai: Does this mean that there are people within each group whose profession is to recruit?

Daniel: The talent acquisitions are shared by the entire organization, but there are recruiters who, let's say, work more with other groups or according to certain areas, and then, maybe then, cooperate with them. I had, say, weekly, one of the recruiters for the back end for a very long time, when we were trying to build the pipeline correctly and I think that the challenge here can be divided into several areas. So, there is the fact that we need to bring in many more people, the company has grown a lot, suddenly we now have to fill 20 standards of developers, so how do you do it? How do you do the sourcing, where do you find the people and what kind of people do I even need? So the definition of what I actually need is joint work that was actually done according to the moment, what the business sees that we will need in the future, and then actually sit down with the technological leadership forum to try to formulate what roles we really want to bring in and what the groups, what the different teams will look like, build the structure of the group and then based on that decide what we recruit. From there, actually the sourcing is also probably a whole book. I think there are different ways to do it. LinkedIn works a little less for me, so there are other pipes, I have to say that Twitter is a bit more…

Karni: Have you managed to recruit with Twitter yet?

Daniel: Yes, the truth is that there were successful hires there...

Yishai: This platform will be closed soon.

Daniel: I hope not, but also a lot of referrals on this, and here there is a challenge of how to actually convince people to bring friends or colleagues from the past to work with them. It worked great for us, but only from a certain point. I think people have to be in a very good position to bring friends to work with them.

Yishai: It's a great measure of people who love, are satisfied, and are also proud of their place.

Daniel: So, one of the questions I would ask in Skype meetings, actually a meeting with the developers in the group, is what prevents you from bringing a good friend or colleague now, and it's a great way to identify things that work a little less. And I'll close these parentheses for a moment, so referral is also a great way, but once we say we did the sourcing, it was excellent. Then it could be to improve the brand of the company or the group, or contact specific people, usually personal inquiries, so there's the issue. The challenge of recruitment itself, what happens when suddenly 5-6 people come for interviews a week, how do you build this infrastructure of interviewers in general? Interviewers need to be trained now and usually there are several stages in this process of interviews. How do you do it? How do you build this process so it is efficient enough so that ideas will be between, I mean the whole process will be between say a week and ten days, so that you can be competitive with the other companies out there and really give an answer as quickly as possible to the candidate?

Yishai: And maybe these interviewers joined the company a week ago.

Daniel: So, it's also, we started, and within two months we went from one interviewer in backend and one in fullstack or frontend to essentially a complete set up that contains all the team leaders and all the technology leaders, and from there also to the developers in the group. But it really required training and to define it as something that is sufficient, it's important that it's a high enough priority and not something you see on the schedule, “oh, I need it now,” I have an interview that sucks, it's stopping me at work right now, so as soon as you define it as a top priority and also celebrate these victories that we were able to do hiring, if it's in a meeting, a group like this or in the other forums. Karni talked about celebrating successes, then also celebrating hires, so it suddenly becomes the top priority of people in the group as well. They also want to bring in a referral, also want to come in as interviewers. This give them some kind of parameter in their personal growth as well, to start interviewing and participating in homework inspection, if there is any, or things like that, and the last step is, what actually happens as soon as someone is coming…

Yishai: Or ten.

Daniel: Or ten, yes, so I think that the way we found, that we thought was the most effective, we have an organization that is like this among the different companies called Makers, that basically everyone who starts, basically every developer who starts at Lemonade starts there, which is basically some kind of comfortable cushion to start from where the teachers actually go through all the trainings together and all the lectures. And, in fact, it can be any period of time between two weeks and several months. The graduation is personal and there is a name. It is, of course, very convenient for juniors or less experienced developers, but seniors also start there. Basically, you get the first tasks there, you learn about the dev environment, you learn about the company's business, and it is also such a support group. Again, this is another such community that wanted all such courses together and actually after graduation the developers are dispersed to teams, each in their own time, and they join the teams and there is also some kind of buddy within the team that helps them to be absorbed.

Yishai: Really a buffer organization like this, and does it have real missions? Or is it all just training?

Daniel: So, we started with such general training tasks that each group had to carry out and at a very early stage we realized that it wasn't going to work and we wanted real tasks, and also to have some kind of interaction with the people in the teams. And today each of the teams actually has Maker tasks, which means that someone who starts is already assigned to your team. Everyone who starts the Maker program already knows where he/she is going and then he does real tasks from the backlog, usually simpler tasks that help you get a sense of accomplishment, that you managed to do it, and are working on them with someone from the team who mentors and helps in tech design.

Yishai: But I sit in another organization.

Daniel: Yes, but you are sitting with a lot of people who are new, who will have the same problems in the environment that you encounter, they encountered them two days ago and you can ask them the questions and it will be very convenient. Some people are a little shy to ask in a very large forum, so there are always those people who started with you or a little before you.

Yishai: And in this Makers organization there are also people that this is their job?

Daniel: Yes, so there are also team leaders, yes, yes. There really are team leaders there, which is what they do, completely, and it's also the people in terms of character and who they are that you would like to meet when you enter the company. I mean, these are the most empathetic people with the biggest hearts and huggable like that, so the entrance is smooth.

Yishai: Cool. As we get towards the end, Karni, one piece of advice or one idea or one thought, for someone who is a young manager in a fast-growing organization, or even a developer who wants to be a manager, how to prepare or what, what to think, that we are now suddenly a tsunami of growth, from your rich experience?

Karni: I think mental flexibility and listening. Try to understand, recognize for yourself what you can bring, what your value is. Understand where you sit in all this growth, and what are the advantages that you can bring to the company, because there are certainly some. When the company that is growing so fast needs it, and this is a real opportunity.

Yishai: Daniel, one thought, one idea for someone who looks like this or sees the company he/she is in is on a path of rapid growth, how to prepare, put on a belt? What...

Daniel: To put on a belt, to dedicate yourself, but beyond that to also be ready for changes. But also with a great desire to learn. Be open to everything that is going to come, especially to accept that much more will be demanded of you and the demands will only increase and become more complex and you need to develop and continue learning in order to be able to meet them.

Yishai: Thank you very much, thank you to Karni, to Daniel, it was fun hosting you.

Daniel: Thank you very much.

Yishai: Go to devinterrupted.com to register, you can also find all our episodes in English there. I remind you that we at LinearB are growing rapidly, recruiting for a variety of positions in all fields, so go to linearb.io/careers to find your next challenge. I'm Yishai Beeri, we'll catch you in the next episode.

(Closing music)

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

• Engineering Managers IL Group
• SheCodes;
• Pull Request
• Baot
• Snyk
• Lemonade