Individual Contributors: The Art of Leading Without Managing, Orit Wasserman & Shlomi Noach

Episode Transcript תמליל הפרק

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

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

Yishai: In this episode I am happy to host Shlomi Noah, developer at PlanetScale and Orit Wasserman, Distinguished Engineer at Red Hat, hello.

Orit: Hi.

Shlomi: Hello.

Yishai: What a pleasure to have you.

Shlomi: Thank you for giving us the opportunity.

Yishai: You invested in us, you came from afar.

Shlomi: Yes, we came from the Galilee, by train.

Yishai: What fun, public transport works.

Shlomi: In this case we succeeded.

Orit: Yes, today was good.

Yishai: Nice. So as always, I like to ask my guests to tell me in a few words how you got to this point, Shlomi, let's start with you.

Shlomi: My name is Shlomi Noach, I am a developer, 24 years in the field, (I just did the math), I work today at PlanetScale as a developer, before that at GitHub as a Principal Engineer and before that at other companies, booking.com, Outbrain, etc. I was attracted to the world of databases, I'm originally a developer but I was drawn to the world of databases because I had to do something with databases and I entered the field very strongly and in fact in the last 10-15 years I've been really involved in this world, writing also how to deliver solutions to the world of databases and also working either on infrastructures or as today, in my company, I work on a database as a real product. So I literally focus on this world.

Yishai: Right up to the DBA level? or,

Shlomi: Yes, yes, I mean for several years I was actually the DBA of my company, because there was no DBA and that's how I was exposed, but because I'm also a developer in orientation, so actually how these two worlds connected and the things I deal with today is precisely this connection between the world of development for the database, because there is a big black hole that needs to be filled. The interfaces and integrations are filled with friction, the whole way of operating and integrating with databases is usually unpleasant and there is a lot to be done in this area.

Yishai: This is your niche.

Shlomi: It's really a niche, yes.

Yishai: Well, thank you. Orit? Tell me a little about your evolution.

Orit: So I've also been in the field for many years, over 20, I don't want to count. I started as an Atuda soldier, I don't highly recommend the path, though, and I served in the unit that today is called Ofek, in the Air Force, so it was from M”MDS, in Palmahim. And I am in a similar field to Shlomi, I also like infrastructure, but even at a lower level than what Shlomi does, it’s considered as far as I am concerned, middleware a little higher. I came to this world by accident, it's just always something I was drawn (to), I wanted to see how things work down below, close to the irons, to the hardware, and that's how I came to storage by accident. I was at some security startup, the crisis of Y2K came and , what was it? 2001? I was cut, and I was looking for a job–I liked C++... so Linux. So I found a startup in storage and that's how I got into the field. Yes, I had a break where I moved into more of a virtualization field, I worked on KVM. But I came back to storage and that's what I’ve been doing in recent years. I really like open source as well. I came to this too by chance, with KVM, and since then I really like open source and the whole Linux kernel...all the open source projects and the community, it really speaks to me too. And I think that in the end I just love this intersection between the software and the hardware.

Yishai: Excellent, so our topic today will be the world of the individual contributor, you are both seniors who have progressed on such a path and I want to dig a little deeper into how it works, what it looks like, how you choose or are chosen for such a journey. But maybe we'll start by talking about the elephant in the room, you are spouses, both of you are senior individual contributors, how is it to be in the same content world, very close every day, 24/7, does it make a difference? It's not related at all? Does work stay at work?

Shlomi: It matters a lot, we have a lot of conversations about work, a lot in common, luckily we are somewhat in similar fields because really sometimes it's like that,

Yishai: The database can blame the storage...what nonsense are you doing with the storage and the data.

Shlomi: Right, really, really like that,

Orit: Yes, so the girls sometimes laugh on car trips, they hear our conversations and they don't understand what we are talking about. There are advantages to this because the world is, like when I have a bad day at work and I come to Shlomi to vent, he can totally understand what I mean. Yes, of course, you have to keep boundaries, not get into technical conversations too much, and also save time for other things.

Shlomi: There are sometimes conversations in the evening that really don't go in the right direction, it's (laughing) when we get into Kubernetes and hypervisors. I tell Orit–– stop, I can't continue (laughing).

Orit: But for us, it works. My brother-in-law once said why not open a startup together, but that seems to me like it would be a bit too much.

Yishai: Do you manage to take advantage of it for joint conferences and travel together?

Orit: Yes, yes, yes, we were at Reversim now.

Shlomi: Yes, exactly, two weeks ago we were at the Reversim conference together, we went to FOSDEM together, but most of the conferences are not together, there are conferences specific to storage and there are conferences specific to databases, and we also keep our distance.

Orit: Yes, also, today they are older, but when they were little one parent had to stay and then we wouldn't travel together.

Yishai: Excellent. So, individual contributors, I now want to touch a little on the question first of all both from your experience and for those who might be listening to us and thinking what is my path, how do I want to move forward? So there is always this choice for someone who already deserves a promotion or is gaining some experience, am I going to be a manager, am I going to manage people or am I going to advance and influence and gain experience as a developer, as a senior developer, as an architect––this whole world of individual contributor? So tell me a little bit about the point you had and maybe a dilemma or how you chose or how you were led in these directions.

Orit: Well, in the army I was at first a developer, then I was a team leader, and after that, after I was discharged, I said I didn't want to be a team leader again. Especially in the army it seems to me that it was a position with a lot of bureaucracy and not easy, and I don't think that throughout my career I really made the decision. It's just always been - I've always been more attracted to the technical field, it's also a field that challenges me more, I'm also good at it. I think as a manager I'll be fine, but as an IC I'm really, really good and really enjoy it, which is the most important.

Shlomi: I completely agree, I mean the first thing I like to develop is something that brings me happiness, if everything works out then it brings me happiness, there are better days and less good days, but this is what I like to do and through development I manage to have a significant impact, on the community, on the open source world. This means that you can reach very large distances. I have been working as a developer for many years. If you ask this question of what do you want to do in 5 years, the classic question when you join any company, yes? The answer is as of today and for 15 years now, I want to continue being an individual contributor. I am less attracted to management. In the past I founded a company, I was a partner in a company and all this dealing with things that are beyond the product, development, the things that are, personnel management, retaining personnel and all these problems of management do not speak to me. I don't think I'm very good at it either, so I prefer to stick to my strengths and do things I enjoy.

Yishai: I want to challenge a bit what you said, you actually said we like to focus on the technical content, on the umbrella, but when an individual contributor becomes a senior, the form of their influence in the end is not in lines of code but in, well, let's talk about architecture. Let's talk about how to do things, in what order we will roll out this capability or the infrastructure, so that the work will be both effective and in the end we will deliver the product, and a significant part of everything I talked about goes back to the people. Because you can talk until tomorrow about architecture––but you have to motivate people to do the right thing, you have to give them feedback that they did the wrong thing, it's just like managing people at the HR level, so where, how do you manage to do it without spending,  quote / unquote , time on the people stuff.

Orit: Well, I can answer, because since I really progressed and became an architect, etc., then really the time to develop code has decreased a lot, even too much. I miss it very much, it's something I'm debating how to bring back, to an amount that would be more technical. It's true that it's people, it's definitely motivating people and convincing them without the authority of a manager. Because I can't tell someone to do it, I need them to want to do it. And that's definitely what -, it's more of a soft skill and not only technical, but it's a little different because you still don't manage the people in terms of today, you don't. Like there are companies, and there are departments so there is a people manager and there is a tech lead, so we still remain in tech lead(ership), meaning we don't manage the people. Yes, there are highly overlapping things, I agree, I definitely do, I even encourage, and help people to advance, in the sense that I talk to managers about a promotion track and this is something a manager is also supposed to do. So I do it for whoever I think needs help or is really good. I also set strategy, even sometimes decide what people will work on, so there is an overlap.

Yishai: And all this messing around in the world of soft skills and the people who go into the work of a technical leader, is this a necessary evil? or is it part of the

Shlomi: No, not with me, I mean I think there are simply different ways to inspire and motivate people than being in management. That is, for me, in my opinion of what an individual contributor in a senior position in an organization is, knowing how to identify problems and knowing how to offer solutions. And these solutions are good for everyone. That is, everyone is happy when these solutions arrive and everyone is happy to commit to them, and when you see that something is successful, it generates very, very high engagement. When you release something to open source, when you talk about it at a conference, it generates engagement. People like it, enjoy working with it, of course you have to be a pleasant person, and know how to talk to people and respect people and appreciate people as every manager must know. Every person who talks to another person should know how to give feedback and give a kind word, but it doesn't have to come from a place of management, I think that if there is something that I usually need help with or ask my manager to give me, it's actually the validation and backing to come and talk to another team. And basically it should be clear that I'm coming and I'm taking up a bit of their time, that if I'm going to talk to them then it's not like they're going to feel like I fell on them out of nowhere, who is this developer who now wants us to do something for him - but it's going to be good. That is, to help me to prepare the ground so that I will not be portrayed as this Principal who comes and assigns tasks to me.

Yishai: And says you did not do this well, change it.

Shlomi: No, God forbid.

Orit: No, we never say you did not do well. This is, for example, something that you learn a lot at early on, that you ask questions, you say okay, what do we do in this case and what happens if this is the case and what if we want to use it for something else, then the answer is we didn't do this well, we need to do it differently. But all the, let's say the soft skills, then, generally in open source, in order to be successful, even though there is the image of Linus... that he doesn't come with strong soft skills, you do need soft skills. You usually can't come to a community of people, especially since the communication is also very, very asynchronous, and tell them what to do. You have to learn to convince, know how to explain yourself, explain architecture, explain why, understand the users as well. This is very important and I don't think it is a necessary evil, at least I've always really liked that when I do something, that I write software, that someone will use it in the end and say voila, it really helped me.

(transitional music)

Yishai: So in light of the fact that still quite a bit of time and attention go to what I call “people stuff”, motivating people through all kinds of methods, and it is clear that you need to specialize in this, but these are not technical capabilities, it is not writing code or a library or improving the architecture, but rather let's convince people that it's right. Let's motivate them to make it a priority and maybe somehow deal with the pressure they have to deliver, but I remind them of the fact that it can be done better and maybe we will get back benefits, but there is work of persuasion here, work with people. In light of all this, I return to the stage of someone's career who says wait, I think about how I progress, how I gain experience, credentials, status, and I am debating or debating between managing people and going to influence as a tech lead. In both options I am forced or have to leverage people skills and do things that are not code and really technical, I have to stay in this box of I just write code, I throw out excellent output but I have no effect, it probably doesn't hold water. So since I have to deal with people skills in any case, how would you recommend for someone to choose? Or say this suits me? Is it appropriate for me to influence people like this and not influence people like this?

Shlomi: I think it is true that both need people skills, but people skills are directed to very different places. As a tech lead and as a manager, I think that as a manager you have to support people with a lot of personal problems or professional doubts they have or, in general, interaction problems and conflicts between team members or between teams. And these are things that I, as an individual contributor, do not deal with and do not want to deal with. I mean I don't.  For me, it's both putting politics aside and putting authority aside, and it doesn't do me any good. So it's pretty clear to me that I won't enjoy it and I won't be good enough as a manager of people, at least in the near future. Who knows what will happen in another 5 or 10 years?

Yishai: Okay, so at the end of the day the point is whether I want or enjoy dealing with solving people's problems such as promotion paths, such as conflicts, if not then I should probably aim in the direction of tech lead, if I'm trying to summarize.

Shlomi: I think so if you don't want to, if you're not looking to be someone who solves people's problems, then you shouldn't at this point, because these problems will come and they need, they need a solution.

Yishai: Okay. There is another area where managers are involved, and maybe this makes the role of a manager a little different from a tech lead, and it is precisely on the sides of the so-called business priorities. At the end of the day, a manager of an engineering organization, in addition to handling people, also handles products and priorities, it will work this way, it will enable a this business move or business progress in one way or another, and sometimes the tech lead is less in this loop or, you tell me.

Orit: I'm in the loop.

Yishai: You're in the loop, okay, will you tell me a little about how you are involved with the business decisions?

Orit: Well, the first thing is the strategy and the business priorities, these are large entities as well, but there are all the product managers, that are called business units, which include marketing and sales, that definitely also have data points. But I am in contact with the product manager, in contact with very large customers as well, I hear what they want, I also follow the industry where the trends are going and provide input and this can influence a shift in priority. Apart from that, sometimes I notice that maybe the product is too busy, there is something that maybe needs to be done going forward because that's where the industry is going to, so I definitely do stuff like that, on the side, or there's a project or something that can bring us closer to a certain goal that we’ll need in another two years or something like that.

Yishai: So you say, for you, it’s definitely in the scope to work on business priority and how I will build infrastructure that will allow me to seize business in the future.

Orit: Yes.

Shlomi: And for me the situation is a bit interesting because I am a developer and database person and I work for a company that produces a Database as a Service where our customers are developers. I mean I'm really, I'm in the loop of who I'm making the product for and what they need from the product. But I think it's true in general also because it's a relatively small company, there are 90 people if I'm not mistaken as of today. And more or less everyone talks to everyone. And also because we actually expect the developers to be a little more oriented to what the user experience will be or what the user or the customer really wants or wants to receive, so I think it is somewhat embedded in our development processes or in the choice of what we will work on. And besides all this, and this is another thing that I really like to turn to my manager, my direct manager, to help me with priorities, that is, I have ideas, I have suggestions, I have things that I think should be improved, need to be improved, and he will come and tell me what he thinks is a must for the existing customers or a must for the needs the company has today, that will push the company forward at this time.

Yishai: This really raises an interesting point, and maybe we will talk about the differences between how IC influences a startup or a small company, versus a very large company. You talked about your manager. I'd like to  ask whether your managers are people from the same discipline, that is, a technical leader. Let's say a chief architect who manages architects, or maybe in a small company, the manager is already a business manager, who has the IC who works with him, who helps him move things.

Shlomi: So even in my company today, at PlanetScale, also at GitHub, I had managers who came from the field, engineers who became managers. And first of all they have the technical vision and they understand the technical side of things, which is very, very helpful and easy, at least for me. But they are also very very product oriented and customer oriented, I think what I liked the most when I joined GitHub, my manager, my team leader came and said “nice to meet you, I'm Sam, think of me as your concierge, do you need anything? Turn to me, otherwise I will clear the way for you and you run ahead.”

Yishai: Was he a manager whose responsibilities were of the same type? Like a hierarchy of individual contributors? Or he already managed a team and had...

Shlomi: He already managed a group, as well as my manager today, who is actually reporting to the VP R&D of the company, regardless of the titles. It's a small company, but my manager is actually a VP and he deals with everything in the company, so you can say that he also comes from this world of the IC, but he definitely deals more with product and customers these days.

(transitional music)

Yishai: So let's talk a little about how, what are the tools of an individual contributor to influence. They don't have a rank in most cases of “I decide and that's it” and I tell you what to do, they also don't control the resources in most cases, the people or the developers, let's now put three people on a project. So what are the main tools for influence? How do I end up making things happen?

Orit: Communication first. There are all kinds of levels, if it's higher levels, then really show, many times the research before, to find proof, not to come empty-handed and say “just because”. And show, sometimes, even do a demo or POC, and demonstrate how this will work. If it's someone outside of our product, another product, then it's either contact the engineering and work together with them and that's how a relationship is created. It's a lot about relationships in the end, like above also downwards. I mean if one day I come to some group of developers and I tell them this is what needs to be done, it won't work, you need to be a known person. So I also introduce (the solution) to the whole group, give enrichment lectures in all kinds of fields, update on what is being done strategically, in which directions the industry is going. I do code reviews, I also try to sometimes join engineering meetings and give my opinion, and most importantly help and create a relationship.

Yishai: How does IC measure itself? At the end, when they are  in front of their managers, come on, it's been a quarter, what are the goals, the OKRs, what, how do you even approach it?

Orit: I sometimes look, especially now, that I don't get to write much code, so it was very difficult for me to measure my contribution. So I just look at things that I was involved in and what happened in the end, and things that I decided I didn't have time for, so I didn’t get involved or I let them go. Which by the way is a difficult topic, deciding to let go, when there are many things to do. And I see that somehow the things I'm involved in are successes. First of all, many times the projects are completed, they end successfully, the client is satisfied, everyone is satisfied, on time, which is something very rare, so this is probably the proof actually.

Shlomi: And I think this is also the role of my manager, I mean I'm ultimately a human being and I need someone to give me positive feedback. There are good times when I feel I really delivered something that improved the product, solved a problem, I don't know what, improved the service, improved the product, and it's clear to me that it’s visible. Something new came out and we're all happy, and there are times I don't know, I worked a little on infrastructure here, infrastructure there, I solved some kind of bug here, I didn't feel like I was riding some kind of wave anymore. And I talk to my manager, telling him listen, lately, in the last few months, I’m feeling my delivery was weak. He tells me what are you talking about? Look, people like to work with you, you solved a problem with a client, right, it seems like a small problem to you, but this client is a big client and within 3 days the problem was solved, so the client is satisfied, they could have left us. And this feedback that comes from external sources is very important and really helps me to evaluate myself.

"Feedback that comes from external sources is very important and really helps me to evaluate myself."

Orit: Yes, especially in open source, which is another nice thing, it's not just your manager, you see what the community thinks of you and how they react, so you also have another source of feedback - which is cool.

(transitional music)

Yishai: I want to ask you what it is like, in your eyes, what does a manager who works with ICs need, you described a situation of a manager of a unit or group, a manager of engineers, maybe a manager of product people, and they have senior I's who actually help them lead the technological side. What is important for the manager when they work with someone senior in such an IC position, what is important for them to do and not do?

Orit: Well, I'll say what's important to me, so what really characterizes me throughout my career, I need them to give me a lot of freedom. A few years ago a manager micromanaged me, it turns me off, drives me crazy, I can't. I need them to give me autonomy, to trust me, and then the results are amazing. And I think this is true for all ICs, I think especially ICs, if you manage them too closely, you will actually lose all their advantages. Because their advantage is their ability to lead things, grow things and see things that you as a manager probably don't see, so it's important to give them the freedom to decide what's important. That’s all.

Yishai: It's true to say that senior ICs because of their strengths, may have a blind spot to questions of politics or what they’re stuck on, their ability to flag stuff for their manager and say free me up because this is what I'm stuck on.

Shlomi: There are those who do it great, naturally, I personally don’t.

Orit: I do it naturally, me, if I need help I just ask. I don't wait for the manager to help me, but I usually either solve it or ask, even go to the product, ask them to move things I'm stuck on, it's a matter of character. There are ICs that will just come, either they will manage to do so on their own, or they know how to ask, there are those who -, this is generally true, there are those who need help. In terms of organizational politics, sometimes the manager can't help, or the manager, and specifically the ICs, as if we say it's a large organization, so you can suddenly talk to another product, another business, precisely that the two ICs of these groups can solve the problem better than if they go through an administrative way, that is precisely because it is engineering to engineering, it is solved, and the relationships actually improve some kind of political problem. So it doesn't always have to be the other way...

Yishai: I understand, but at least the manager should be aware that not all ICs know how to communicate in the most effective way what they are stuck on and sometimes you have to be proactive.

Orit: That is true for every developer, there are those who don't know how to say they are stuck and there are those who will manage on their own and even notify before and...

Yishai: Okay, so it doesn't end when you become a senior IC, for those who find it difficult, it continues to be difficult.

Shlomi: Yes (laughs)

Orit: I think with experience you learn what works for you, what doesn't, what are your strong points, what are the less strong points, and a good manager knows how to work with them and actually improves your skills, strengthens you in your weaknesses and channels your strengths.

Yishai: I want to tread a minefield for a moment, in the world of development in general and maybe also, you tell me, in the world of seniors and ICs, the extent of the presence of men, women, and also where you are, if you see that it affects the ability to influence, it is easier for men to maybe have an impact because they are primarily seen as having more authority, I don't know, I know that this world is evolving, but there is still trouble. I see it in engineering organizations, they are unbalanced and promotions are not always balanced, so where does it meet the world of the ICs?

Orit: Well, this one’s for me (laughing). So this exists, it's very noticeable, like especially largely because of the like the percentage of women beforehand, even already at the entry into the industry is lower and of course over time. So, yes, there are differences. For example, I will talk about, of course, the fact that I say that I am a distinguished engineer so I have to give my title up front. I think if I were a man I could just say I'm something, I'm just a developer, but when it comes to someone who doesn't know me, it helps me a lot to say my title, which is a very senior technical one, and that already gives me a bit of a better starting point in the conversation . But I definitely start conversations many times today with people I don't know by self-introduction, which men don't need to do, so that they understand who they are talking to and that I am technical and I know, this means that this also happens to me with clients, unfortunately. Clients who know me listen to me straight away, but in the beginning there is a period when they have to be convinced so that they understand who is speaking, I just had a client from Turkey, which is probably culturally related, where it was very difficult with them and they didn't listen to me, but in the end they realized their mistake after they suffered and realized, I was right and now everything is fine, but it took a lot more effort and I'm pretty sure the gender issue was related.

Yishai: So maybe in the end we'll go back home a bit, two spouses who work in the same field, and besides in similar positions of technological leadership that work fully remote, long before COVID, you told me that you actually work in this remote mode with international teams.

Shlomi: True.

Yishai: A little about the mechanics of it, where does it work better, less well, what is life like for someone who lives in the Galilee and works in technology in depth, all day on Zoom? I don't know, tell me a little about how it is, two in the same house.

Shlomi: So the truth is that the nature of our work is very different, Orit works more on Zoom, I hardly ever do. In fact two or three weeks ago our CEO put out a memo on the company's internal blog that he noticed that we are doing that too much, that there are too many meetings and we want to cut back. They believe less in meetings. I think it really depends on how much interaction you require with other people and how open the people you work with are to this idea that you work remotely, that you are in a different time zone, etc. I also had the privilege of working at GitHub, also at PlanetScale in companies where remote work is a first class citizen, first class, meaning there's no assumption that you'll be available at a certain time. I'm here right now recording in the studio, that's also work time. Maybe someone is pinging me right now, but no one expects me to answer exactly at this moment. For me, the work is almost completely asynchronous, that is, most of the time I work in solitary mode, occasionally chatting or in Slack or sometimes in a Zoom meeting, but most of the time I am really alone and do not need interpersonal communication to move me forward. From time to time there are places that I get stuck and then try to sync.

Orit: Yes, so unfortunately I'm not like that anymore, I have many meetings as Shlomi said, so we used to be in the same office, but now he is no longer willing to be with me. (laughs) He says that I have too many meetings and it bothers him, so I got the office, it's mine (laughs). No, it's not really mine, we have two desks, but we don't work at the same time because I have a lot of meetings, plus that's why we have another excellent setup and workstation in the bedroom, where the desk is fully stocked.

Shlomi: But it is abandoned, I usually sit on the balcony with a cup of coffee and program in front of the view.

Orit: Yes, Shlomi likes to sit on the balcony, I envy him, but somehow I like working at the table, I like a framework more.

Yishai: And there is the, you said there is no expectation that I will be available at any moment, but sometimes there is a situation where okay, the other people are not that remote and then the one who is remote is at a disadvantage, okay, everyone is in, I don't know what, an office , and someone joins the meeting remotely.

Shlomi: True.

Yishai: You're at a disadvantage, if you're in Zoom and everyone else is at, at some table,

Shlomi: I agree.

Yishai: So how do we solve it or how do we approach it?

Shlomi: It's very difficult, when you're the exception to the group, it's very difficult, especially if it's an Israeli company or an Israeli group where it's natural, in our nature, in our culture, to talk and to chatter in the hallway, in the kitchen, etc.

Yishai: And with our hands.

Shlomi: With our hands, right (laughs) and then you lose something, that's right. There must be a commitment from the rest of the team, ok, it's impossible for them not to talk, but things need to be written down or things need to be formalized, and if that doesn't exist, then in my opinion there won't be symmetry and it will really be very difficult. You'll be some kind of outsider, half guest. It's still workable but you won't be in the same position as other people. If everyone agrees to this commitment to formalize things, write things down, share issues, pull requests, internal memos, no matter what, then the integration is much more authentic and you yourself can respond in the same language, write things, etc. and share your knowledge with them and reach a little more symmetry.

Yishai: To wrap up, do you have one tip, one thought, for an IC at the start of their journey? What they should pay attention to, how, what to do, what not to do, one thing that you would like to contribute as a tip to someone who is starting their career and thinking about how I become a leading IC?

Orit: Hard (laughing)

Shlomi: Promotion is not necessarily a managerial track, it is possible to make an impact in development, it is possible to make an impact in sharing knowledge, it is possible, there are many ways to make a significant impact on a company, one that is valued, one that receives good feedback, without reaching the managerial stage, and perhaps this is the basic thing to start with .

Orit: It doesn't matter, I think the track you choose, SOFT SKILLS are key, you should work on soft skills, not neglect them.

"It doesn't matter, I think the track you choose, SOFT SKILLS are key, you should work on soft skills, not neglect them."

Yishai: You can't run away from it, eh?

Orit: You can't run away, especially we also have to remember that in the end we are writing software that should be sold, so remember the user who pays us in the end and also look at their needs.

Yishai: Shlomi and Orit, thank you very much.

Shlomi: Thank you very much.

Yishai: It was excellent, thank you for coming.

Shlomi: I'm glad you were here.

Orit: Thank you very much, it was a lot of fun.

(transitional music)

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

(Closing music)

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

• Red Hat
• PlanetScale
• Reversim
• FOSDEM