Skilling Up for Devs: The Real Deal, Eti Dahan Noked

In the fifth episode of Dev Interrupted - the Hebrew edition, Yishai Beeri, CTO at LinearB,  chats with Eti Dahan Noked, VP R&D at Wilco about skilling up your engineers...how this differs from regular training and onboarding, and who's responsible for the success - managers or the engineers themselves?

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.

In this episode, we are happy to host Eti Dahan Noked, engineering manager at Wilco. Hi Eti, how are you?

Eti:              Hey, what's up?

Yishai:         I'm glad you're here. So we always start by getting to know our guests a little, and I would love it if you could tell me about your path, career, and how you got to this point.

Eti:              Cool. So I'll start from a little while back. My story, it’s funny, is that I studied math and there was a C++ course that I hated. I hated every moment of the course. I remember telling a friend I'm not going back to that class anymore. Fast forward a little and I enlist in the army. I was in the 8200 intelligence corps, but I was in computers. And so, for the next 8 years I dabbled in C++ and found out that what you study at university or in a course is not how it is in real life and not the way the profession works, but I really fell in love with the work.

After the army, I worked in a variety of companies. I was at Elbit, HP, We Work. In each position I was in an engineering, tech-lead, or management role, which is how I got experience in each. Before Wilco I was at Checkmarx where I established an engineering group called Code Bashing. In the Code Bashing group we made a product that teaches developers how to write code that is secure, which also integrates with other Checkmarks products, and teaches developers to write code that is secure and can’t be hacked.

And today I'm at Wilco where I manage the engineering team. At Wilco, if I had to sum it up in one sentence, it's a flight simulator for developers. And more than that, we made it our mission to enable all developers, no matter their background, to grow and gain experience and realize their professional potential. And we do it.

Yishai: Basically with the help of a product, of a platform.

Eti: With the help of a product, yes, we develop a platform. We create a kind of environment, a virtual company, that allows you to practice the things you know or things you want to learn, and we believe that the way to grow and practice is through experience. You can do it at work, but it's a bit slower or prone to errors or even unequal.[לה1]  And at Wilco, we create the platform that will allow you to learn and develop at your own pace, enabling literally everyone, no matter what your experience or background.

Yishai: So actually, at Checkmarx you worked in this world of upskilling, or a product designed to teach developers how to do something, in this case how to develop something, and then it was natural for you to move to Wilco, a company that deals from start to finish with upskilling.

Eti: Yes, the domain is very similar, and it's also great fun, because we make a product for which we are also the target audience, and a product that you can also use.

Yishai: Yes, that’s always fun. So really the focus of today's conversation is on this world of upskilling and how engineers learn and develop, whether it's at the beginning of their career or later on. Tell me why this is important, why should it be defined and why start companies around upskilling.

Eti: So I'll treat it like two sides of a coin. First of all, from the organization’s side. So, we build an organization and we recruit the team today. Then we look a few years ahead, and if we train our team and help them develop like this, then they are actually more capable and able to deal with problems that will arise next year, two years from now, which can be more complex, technically or product-related. Or maybe in another area which we might suddenly need to change direction into. So it's like that from the company's side.

And also from the employee's side, as a engineering manager, it is important to me that the employees know that I see them, that I know where they want to go, we care about their promotion options, we help find the opportunities for them to develop and learn, we are in a profession that is constantly growing, we have to grow with it.

Yishai: And if I am a manager in an organization and want to think about this world of upskilling for these developers, let's maybe start by asking - what should not be done, what should be avoided?

Eti: So I like to start with what not to do. The first thing I recommend managers not to do is prepare a contingency plan. You can't create a template that matches each of my employees needs and say “Here, this is what you need to do - 1, 2, 3, 4, 5 - let's go there.” We have to remember that the plan is for the employee, the person standing in front of us, and each of them is different with their own strengths and weaknesses, and we have to really adapt the plan to the person standing in front of us. And the second thing I always recommend to do is not to push the employee in a direction they don’t want to go, because in order for a engineering program to be successful, the employee has to be really engaged and willing. So if I think that every frontend developer should also know backend, but the person standing in front of me doesn't want to learn that, it won't help how much I push them there.

Yishai: So basically you are saying - one, make it something that is personalized, that takes into account the person who is now going to receive the upskilling, and two, that it matches the goals, the desires of that employee, and if it comes with a desire to develop in a certain directions, then it will work.

If I don't have an upskilling process today, or at least nothing organized, what is my first step? How do I even think about it? Is this something I do for everyone? Only for new hires? Where do I begin?

Eti: So, first of all, I think it's really important for everyone, regardless of whether the employee is a junior or more senior, everyone needs their own plan for future development. And I've really been at a lot of companies and seen them grow, and in the end it really, really depends on the manager and the employee in front of them. I think that these conversations of understanding where he wants to go, what he wants to do, where she can improve and understand who is standing in front of you is the beginning, the basis.

And when we actually have this plan ready, we need to practice continuous feedback, repeat it all the time and understand our current position. The responsibility for this plan is shared by both the employee and the manager. As an employee, I need to reflect on what I want, where I want to go, where I’m lacking, and where I would like to see myself. And my manager should also explain what knowledge gaps I have and what types of tasks I can take on. As soon as someone comes to me and says “I want to manage a team” or “I want to manage a large project,” then I can adjust the my thought process and adapt the tasks to the individuals.

Yishai:  So we are talking about upskilling, and I want to understand if you think of that in terms of a programming language or some technical skill or working with React or with a certain library. Or does it also include approaching skills like team management, like handling an uncooperative teammate, or all kinds of things that are not found in some textbook?

Eti:  So I think that, first of all, a personal study program is very important for both sides, the technical sides of a new language, if we want another new framework or even go that way to other areas like a bit of DevOps or a bit of frontend, depending on where we came from. And also, the other side, as developers we have many things we need to know or skills we need to acquire that are not necessarily just writing code. We need to talk to people. We need to know how we plan. We need to know how to code review for friends and work on communication.

And, again, I intentionally note the communication because it is an important part of our day to day. And when an employee is in front of you, we need to look at where they need to improve. There are many things like this that we really work on, and the more you practice them in the communication work or detailing tasks or things like that, which you work on every day and you really improve. And we can this also through more focused work, like a specific task that is more the focus, or people management, which is a big task, if someone wants to develop and become a team leader.

Yishai: Something interesting comes up here, that in order to choose or adapt an upskilling program to someone, I actually also create a process of feedback, that is, I have to understand where the gaps are, where something is lacking, where there is potential to develop. And we don't always think about these things together. I mean, okay, I have a training or skills program and I have another place where I do performance evaluations, or have employee feedback with how they are performing. You are actually suggesting directing them and trying to get them to consider upskilling as part of the feedback process and vice versa.

Eti: Yes, I think that there are organizations that do a performance review, let's say, once every six months. And I think that as managers, if we wait half a year to give feedback, we are making a mistake, because half a year ago we could have improved things by giving more specific and continuous feedback, and then the employee can develop. So even when I build plans with my employees, we don't talk about it one on one, or at least not directly. I'm not saying we should constantly be talking about the goals, but I would like to sometimes impress upon them the complexity of a certain task they've been working on for 3 weeks, which aligns with some goal they set for themselves 3 months ago.

Yishai: A development goal.

Eti: A development goal. We create the plan together, and sometimes I look back at the plan to think about the tasks I have to assign to the team, and I say that this task can wait or can be give experience for that employee because they want to take on a task, break down a very, very large task. So they can take, let’s say, a smaller task and break it down into smaller milestones, work on it, and then it will prepare them for a larger task that they can manage that involves several other people.

Yishai: What is a bit difficult for me here, and maybe you can help me understand, is that you are describing a reality where the manager actually has this conversation with each employee and has a shared responsibility to define the goals and find the opportunities for skilling up through the tasks. And, in fact, during this feedback loop can say “Okay, here's a task that will help with development as well.”

Where does it go from a manager to employee interaction to something that is organizational? To an organizational desire to skill up? Where does it get to the point that every manager has to create this dialogue with every employee? How do we move to the level of an organizational plan?

Eti:  So, first of all, the organization from the top down needs to lower its desire for employees to learn, or for them to invest their time in learning. There are all kinds of tools like LinkedIn Learning or other courses, which companies offer a license for, and it’s actually like “We are giving you the infrastructure, so come use it to learn.”

Moreover, we need to incentivize the growth of the developers, and align them with the goals of our managers, as part of the way managers are measured. It improves the employee’s desire to be like this, and their engagement within the company. And again, we help them grow, so as an organization we need to make it part of our goals and objectives, and make sure everyone is exposed to them. But we also need to do create a more formal process, and this process usually sits, in many of the organizations I've seen, as part of the review. You first start by looking at the past, and then look at the goals going forward, but this daily breakdown must be with the manager or whoever you work with.

Yishai: So basically the organizational part is one motivation. Let's say the motivation to work is there, managers are measured on their ability to help their employees grow and so on. And two, find opportunities for that or make it part of a formal review process or some other process that’s already in place. And maybe three, the organization purchases generic tools that anyone can choose to use. But in these three cases there isn't any real organizational plan, I mean, maybe there is at some level a desire for upskilling, but there is no connection between the upskilling that employee X will receive and what employee Y will. They are not all running on the same plan, meaning things are still very broken and fragmented.

Eti: Right. Now, if I say that this is a personal plan, then you can't look at the organization as the organization. You have to look at an employee as an employee. There are organizations that have their various learning levels, and you can see what level you are at and what you need to achieve to reach the next level.

Yishai: When the levels are defined by the organization.

Eti:  Yes.

Yishai: That means that you can be on Level 2 and you can count how many people went up to Level 3.

Eti:  Yes, you can. As an organization, you define what each level should include and that can be the basis for the manager to look at his employees and help them. So you can look at the amount of employees who have really leveled up, and we assume that through this they really upskilled themselves, and that can enable some kind of infrastructure for the organization that is more uniform.

Yishai: And from your experience, is this something worth the effort and really useful? Or does it try to impose some kind of settings that ultimately cause each person to not really be at a level, but sort of half in half out? I'm trying to understand to what extent it’s possible to produce uniform things compared to how much everyone is an individual snowflake.

Eti:  So look, as a large organization you have to create some kind of uniformity and I think it's the lesser of two evils at the end of the day. A lot of the definitions are also broader, or there are levels to the definitions. You can define things in the technical sense, a leading sense, literally for every level and what needs to be done. Then you can try to break it down into some sort of framework, so that for an organization that has hundreds of employees, you do need to have a set baseline, and help managers not just do it very sporadically.

Yishai:  Okay. Then I have the question of, how do I measure someone into these levels? The manager decides if I am level 3 or level 4? Or is there a test?

Eti: Yes, so it introduces the complications of measuring the performance of employees, at which level they even enter, because they might have been really good at the interview.

Yishai: We will soon talk about the hiring part of it.

Eti: Yes, it's really adds a complication that I think is not necessarily related to upskilling. It also affects many things later on, like your salary and chances of promotion and all kinds of things that greatly complicate the whole equation. It also adds a lot of complications to when people are dealing with a promotion for a month out of the year that you can go from dealing with it every day at large companies just to collect the materials.

Yishai: To prepare the case.

Eti: Exactly, to prepare it. And everything becomes terribly bureaucratic. To my delight, at least in the organizations which I had been a manager, it was a little less formal, so the manager has more influence on how things look. I don't know if that's good or bad, because in the end, when you are a very large organization, you have no choice but to do something more formal.

Yishai: The question is whether we really want to tie the world of upskilling to formal levels, and ultimately to salary and promotion. Or do we say that upskilling is a slightly more technical profession that requires some kind of specialization and try to put it into a general framework of levels and performance measurements. This misses the mark.

Eti: I also think it's something that can happen simultaneously because we, as a startup, don't have all the leveling. It's really a topic we talk about a lot. What are my goals? Where do I want to go? Sometimes it's goals that are not measured. I can say I want to be a team leader, and that's a goal that you could say is maybe the next level or a change of profession. I can say I want to lecture at some kind of conference. That's also a skill that I need to maybe work on and try to get accepted. Maybe there are people in the organization who have already presented at conferences and can help me with how I submit talks, and that's not something that feels like a necessity to move from level X to level Y. So I think it's part of the skills that they are hiding for us within the…

Yishai: Within the formal systems.

Eti: Yes, within the formal systems.

Yishai: That gets back to the world of us as individual snowflakes and how everyone needs something a little different.

Eti: Yes, that is ultimately personal.

Yishai: So we’ve talked about all kinds of ideas around upskilling, and I'm interested in talking about the difference, or what differences and similarities there are between learning some technical skill, like coding in C++, or working with React, and this is how it works in our company, this is how we do code reviews, or this is how we create pull requests in our team, something that is a little more private or personalized to the organization, and maybe also related to the people around me. That is, I don't learn in a vacuum, but rather there is some interaction. Like, that's how we understand a comment about a pull request and maybe if I didn't learn that it would seems like the PR is bad or lacking details or troublesome. So there are many things here that are a bit soft but they concern the team. How do you upskill for this?

Eti: So actually I am going to simplify your question. How do we learn organizational culture or work processes?

Yishai: Yes, development culture even.

Eti: Development culture, yes. So if I don't really know how to quantify it into one skill, because you know, several skills are included in that, but I do think that the ability is to adjust, to learn, as in I've done things a certain way until now and here we do it in a different way, maybe it’s better, or not as good, and we can talk about it. But how I learn to fit in new work procedures and learn what's going on, I don't think it's necessarily part of the development program or the skills, it's really part of the onboarding process of a new employee.

Yishai: When you say it happens through the work and not necessarily as part of an upskilling program, or from some content that I come and study or progress in and finished, then I reached some kind of goal.

Eti: Yes, and mainly because I think it has more to do with your entry time. Even if it's within the company then it's with a new team, so this initial time when you learn the work processes, get to know the people, learn the codebase, some kind of thing that is like onboarding, and then they put it aside. Compared to the process of upskilling or personal development, which is continuous, we look at the current state and decide on goals, and in a few months we will check what we achieved, what we didn’t, and maybe we will talk about new things because suddenly we are exposed to other things that are happening in the organization and you would like to learn more about them, or maybe start some new project that you didn't know existed and that is very interesting to you. So you can also change the goals a bit, because in the end we are developing.

Yishai: That means that, in essence, my goals in this world of upskilling are a little more global than just how to work correctly in this group or that team, which is more onboarding.

Eti: Yes.

Yishai: An interesting diagnosis. It’s like onboarding happens while working, I learn from the feedback around me and maybe there is also some kind of statement that okay, now I am fully onboarded. But my skilling up is related to my career, to engineering, and the skills I will learn are probably transferable to the next place I work.

Eti: Yes, it may be that you worked in a certain form of development, like a certain development process, and now you work in a different process and you can add so much more value now that you know how to work both ways. But the main difference is that, in my opinion, onboarding ends, and at the end you are a full-fledged employee and no longer need it. Yes, you will always need another part of the code explained to you that you haven't seen or something new, but it is likely that you already understand the culture and work processes. It may be that now that you are onboarded you will help a little to improve or change the processes, but it is not necessarily this continuous process of me looking for how I develop or what direction I want, where I want to go.

Yishai: Within this world, and you talk about the fact that upskilling is something that never really ends, it is relevant to all of us. But I have to ask, how do you convince senior developers, developers with a lot of experience, that they need upskilling? They already know everything, they have seen everything, they have already written everything you do in Assembly. How do you come to someone who isn't thirsty to learn or perhaps isn't sure or doesn’t understands that he has a place to go, specifically on the side of the senior devs, how do you open this door? How do you create the desire and understanding that I can advance?

Eti: So, first of all, I think it's not the manager's exclusive responsibility, because it's very difficult to make someone want to do something they don't want to do, but yes, there are all kinds of things that sometimes… like a very senior developer, who wrote everything in Assembly, maybe doesn’t know how DevOps works or how our frontend is written. Now if he is interested in expanding his knowledge there a bit, and the answer may be no by the way, then I will try to find the opportunities and the tools for him to learn.

Aside from this, even if you know the code really well and are able to take this whole solution and turn it into something that works, maybe working in a team where you outline the architecture or where we're going, but don't write all the code yourself, and that is something foreign to you that you haven't tried. And it could be that on one hand you are very senior and you have some areas where you are more junior, because people don't know everything, which is what's beautiful, right?

 Yishai: Some people don't know everything, some people know everything...everything worth knowing.

Eti: Yeah, I don't think anyone really knows...

Yishai: So I'll add little bit more detail. A senior developer can come and say “Okay, I understand that I need to learn such things, I learn by doing, and by that I mean my way to skill up is to do. Give me tasks like this, or I'll take them, and I'll progress and learn as I go.”

But there is a difference between learning by doing by just leaving tasks in such a way that they will help me develop a bit in a certain area, and saying that there is content here that skilling up, which is sometimes structured, not only through organic tasks, is looking for this transition from a smart selection of organic tasks to something where they say now is the time for dedicated upskilling, and it is not necessarily mapped to a task that you will simply learn as you go.

Eti: So the truth is that I've seen this a lot with experienced developers, and I'm the same way, that the best way to learn is with your own hands. In the end it's about trying, and that's why we founded Wilco, right? We truly create the types of tasks that you can do hands-on and try. So there are ways. There are also side projects that people do to learn new technologies or try them out.

I think that the statement of learning through hands-on work is very valid in our world, because sometimes just reading the documentation is not enough. Now when I say I give you time to learn, if she wants to learn hands-on, and I don't have a task to give, you should find the tools that will allow her to learn that new thing. It doesn't have to be like where I gave you a course in Udemy and you have to do it because... that doesn't work for everyone, to watch a course and learn things.

Yishai: So you’re saying to learn through hands-on, but there is a way to create tasks and learning and doing projects with your hands that are not necessarily actual organic tasks of the team, and not necessarily saying “Go look for a project on your own.”

Eti: Yes, sometimes there is also a big problem that we don't know how to solve. It's like someone should do a POC to try to see if we can pass this technological barrier. And only after we know that we can, it becomes something more organized with a product attached to it and tasks that will go to everyone. Sometimes we need this little POC to test whether the technology we know can solve this problem, and it can be a great opportunity for someone who wants to learn the technology.

Yishai: Okay, the way I see it, it is an organic task, admittedly a type of research, but if I understand correctly, at Wilco you actually produce a system where you can do engineering tasks, which are not the organization's tasks. In the end they are thrown away, but they enable me to do things  hands-on and in the process learn the skill I need, meaning, not necessarily a course but a collection of simulated or semi-simulated tasks.

Eti: Yes, they are all simulations. The truth is that we have no theory on this at all. We are not trying to invent the wheel. It is likely that like in real life if I encountered a problem I would go to Google or Stack Overflow, so we also expect from our users that, if they don't know an answer, they will Google it and find the problem. We create a simulated environment for them where they receive some kind of task from their manager, and she asks you to fix some kind of problem because production is down. Now it's some kind of skill, let's say to go to production and fix a problem that we need to know as developers, even as experienced ones. But I wouldn't want someone to practice it in real life, right?

Yishai: On production.

Eti: On production. If the system is down, I want it to come back up as soon as possible, so we give them an environment that is safe, no need to stress as there are no customers waiting. We might send a Slack message from the manager saying, “What's going on?” to simulate some kind of situation...

Yishai: You’re out under fire.

Eti: Yeah, no one actually fires and nobody loses any money. And besides, it also allows engineering managers to give some opportunities to do things that don’t exist currently in the team’s work. If I have a backend developer who wants to learn frontend, I am not sure that I have frontend tasks within my team. It could be another team in the organization, or specific deployment, or dealing with performance issues. All kinds of skills that you can expand upon, but don't always have the opportunity in your day to day, so we also provide that in our quests at Wilco.

Yishai: So how, if I'm looking at an interesting example, when dealing with a problem in production, which is both to extract the information I need and in the end to fix it and maybe also deploy it, it's very different from one company to the next, even between projects or services in the same company. How do you simulate that on the one hand, but make the learning relevant to a particular company on the other? Can I make a setup that actually simulates our environment? Mine as a Wilco customer?

Eti: So this is what we suggest to companies, to adjust the quests, with the best practices that you have in your organization or... except for the frameworks and the languages, to choose things that are a little more specific. We are also right in the middle of developing our editor which allows the company to create its own quests. If she wants to adapt it exactly to the things you teach, and we also offer the service to customers. Maybe at some stage in the future we’ll connect it to their systems, like if you work with a specific system that we don't support in this version, we can add that integration for you and then you can simulate your system with your complexities in an environment that is more...

Yishai: So I can set up some kind of staging environment, but the developer who uses SSH to the production, does it with the same tools that really live with me in the production and Wilco sees and extracts from there what she needs to say you progressed in the quest or you did X or you succeeded, the data planted there is appropriate and yes further.

Eti: Yes, so some of the things we build at Wilco is really the infrastructure, like integrations with all kinds of external systems that we work with on a daily basis, like Github...we're right there with all the hooks to know if you've opened a PR and then we can also To approve it or not to approve it, depends, and we are constantly adding more and more collaborations or specific infrastructures of companies that...

Yishai: That allow you to actually simulate.

Eti: Yes, so that we can connect and get all the information on how you are progressing.

Yishai: Sounds like something that is very relevant to the world of SRE, not only developers, rather it is actually very private company information, that this is how we work and this is how production looks for us, but for an SRE, or someone in a similar position, who needs to maintain and make sure that a system is up, there is a lot to learn and simulations sound like a no-brainer to me to learn the role.

Eti: Yes, so literally every company we talk to takes Wilco for their specific use case. Their reaction is, wow, it's really good for onboarding to learn all these things, or you can take it in all kinds of directions. Basically, the goal is to have an environment to practice things you're supposed to know or want to learn on a daily basis, and we help with best practices as you go.

Let's say your first quest is to spin up the environment, because you are a new employee in the company. As soon as you are done and the code works, we say okay, come update the README so that the next person can pick it up in easily from there. This is a best practice that we believe everyone should know. What's nice is that we actually use it ourselves. There was this quest for me to do and my manager said that after I did the quest, which I did quickly, to let her know. I did it quickly and realized that the README wasn’t updated, so I went and just got it done.

Yishai: So, when I finish this first quest of spinning up the simulated environment successfully and updated the README, now I have to go spin up the company’s real environment, the real development environment. I didn't get if that was an outcome as part of the first quest, or is it?

Eti: In the first quest you spin up the local environment of the fake company you joined.

Yishai: I don't actually benefit from spinning up the real environment, okay. But then at least I have something to compare it to when I spin up the local environment of the real company where I suddenly see similarities or differences or…

Eti: So the goal is for you to get more of the things you need out of it. Like, if you move from company A to company B and you set up the environment for company A, it won't help you, maybe it will help somewhat, but there will be things that won't help you to spin up a the environment of company B. But the thought of the documentation or of helping someone who joins the team, that everything should be clearer, or for database seeding that it will be automatic, I won't have to do it manually or all kinds of best practices that you understand when you have the senior mindset in your head, you don't just solve them for yourself, you solve them for others too. So, these are the outcomes we want from every quest, and also lessons learned. We really emphasize these things.

Yishai: I understand. So, how do I now go back to the mindset of the manager, and even at the level of the organization, how do I know that I succeeded? That I have a system or an upskilling process that works well and people really progress? How does it feel, what are the signals I receive that I can say I succeeded, I can do it and it works well, I invested in the right places?

Eti:  So, it starts with the definition. If we sat down with the employee and defined goals, then you can come back to it later and see if you achieved them. I think our role as managers is sometimes to reflect successes or have an impact on the things that are not obvious. That if an employee invests in documentation or improves development processes or something like that, you show the employee that they also made an impact.

"I think our role as managers is sometimes to reflect successes or a significant impact that is not immediately obvious."

Now how do we know if we succeeded? If at the end, when we do a review, we see an improvement. That is a little difficult to quantify, unless we put KPIs at the very beginning, but you can’t really implement a quantitative measure for every success. But, for example, when you said “I want to take ownership of a big task, a complex technical task in which several people are involved,” if you got there after six months and led a task and you can talk about and explain it, we succeeded. We may have also set a goal that is a bit longer, that we don't achieve in six months and it continues. We work on it in small steps, and then we can reflect on the smaller successes.

Yishai: Okay, so at the level of me and my manager, you can really see if I've made progress with my goals, whether organically or through external upskilling programs, but I've made progress. But if I look at this at an organizational level, you are an engineering manager, how do you feel that the issue of upskilling works well in your company?

Eti: So I have to point out that this is something I learn through doing. It is also something that is possible through conversations with the manager or someone else in that level. The question of what you managed to achieve this year or in the last six months that you didn't know you could do before, or all kinds of questions like that, is a bit subjective, it's not very strict. It's about having a lot of conversations.

Yishai: And when upskilling works well, or in places where you were part of it or saw it work well, what other effects, besides the fact that I am more upskilled at the end of the process, what other effects do you see in employees, or in the company? What are the side benefits or perhaps surprising effects?

Eti: I don't know if it's surprising, but as an organization you can see things that improve like teamwork, the influence of the team on things that are cross-organizational. You can see that the velocity of a team increases, if you now know how to better handle problems or fix bugs which six months ago was more difficult. It's probably also demonstrated in tasks that now take less time for you. So, the effect that it has is more specific to the employee, but it also has an effect on the entire team.

Yishai: Okay, so I want to ask about the ownership of this topic at organization level or group level. Obviously at the end, every manager of employees should be owners of their personal upskilling, but if we are talking about starting a program, or an organization that until now has not treated it in an organized manner, from what you have seen, where is the ownership usually located? Who gets to be responsible for the upskilling in the company, and maybe if you have seen enough, where it is successful or what step allows the organization to succeed, as opposed to steps where ownership is incorrect and does not allow success? And I'm thinking specifically about upskilling in the developer world. Who is the owner, VP R&D? HR?

Eti: So I've seen all kinds of structures for this. Sometimes it's HR, sometimes it was some kind of L&D department. There's a specific person there who works with the VP R&D or the director in each group to help. I think the owner needs to be either the VP R&D or an engineering director, up to a group manager, for it to be successful because in the end it’s the people who work like this every day and understand where it is possible, how this plan can be built, it comes from above. We also need to train the managers on what is important to look at, which opportunities can be seen, because it’s not very clear to everyone. So, I think that as part of the way to introduce this into the organization for the first time, we need to do some kind of employee training, to understand how to look at things, how to identify things that the employee is strong in or less strong in, according to what we will build this program.          

Yishai: So, in large organizations you see an L&D department or something similar. And in smaller organizations it simply falls directly on the VP or the director who manages the engineering and they do it organically?

Eti: Yes, the L&D, at least at Checkmarx it was L&D that worked really closely with me, and all the time also helped with tools he found. If there was some new tool he would like me to look at or something in that direction, they do have this vision of how to create the learning and how we measure these things, but in the end it is my responsibility as a manager to make sure that my managers have it as their top priority as well.

Yishai: So, at the end of the day, the KPI or OKR of making sure we are upskilling is owned by the one managing the development.

Eti: In my opinion, yes.

Yishai: So, as we get toward the end here, share with us how you do upskilling yourself. What do you invest in? How do you find time for it? How do you decide what's important?

Eti:  It’s cool, the truth is I'm not the...

Yishai: I don't need upskilling...

Eti:  No, I never had a side project that I worked on. It was always through my job. You know, sometimes you maintain things at work, and I learn through that. I like reading blog posts or listening to podcasts on topics that interest me. As I moved into management, I started hearing a lot of things, other people's opinions or other people's approaches, and then you formulate your management approach, and I find for myself the things I want to achieve. If it means being a guest here on the podcast, I presented a month ago at Leaders in Tech, which was also some kind of goal I wanted to reach, and then you learn.

Yishai: You literally defined the growth tasks you want to do and then you went and carried them out, I mean it's not just ad hoc.

Eti:  Yes, I found what I want to achieve this year, or where I want to go, like with the conference, where I want. I decided that I want to lecture at the conference because until now I have spoken a lot internally within the organization and I wanted to see what it's like from the outside, which is a skill that is a little different from telling an idea or talking to your employees that you work with on a daily basis. So I also define the goals for myself and work with my partners to see how I can help those who work with me.

Yishai: And you conduct the conversation about these growth goals with your manager? You mean it's part of your conversation?

Eti: Yes. It works all the way.

Yishai: Eti, so to finish, give us one thought or one tip for someone, someone who wants to start entering this world of upskilling, whether it's a manager who has employees in the world of engineering and wants to start thinking about it in a more orderly way, whether it's an employee who wants to produce some conversation with his managers about skilling up. One tip on how to start, how to enter this world.

Eti: I will divide it in two.

Yishai: You got two...

Eti: From the point of view of the manager, first of all I look at my goals, where I want to go in terms of the organization and what I lack. I try to direct my people to where they need to grow or what skills I would like to see in the organization. And from the employee's side, it's a moment to stop, and the question I like to ask most at the beginning of our work together, in an ideal world where you have no constraints - what task would you like to do? And it's an interesting exercise to think like this to yourself - if I could choose and they didn't tell me what I would like to do, and when I understand where my passion is, then see how I can grow there and where I want to go. And you can look around a bit, there are the people around us, and I see those in the team, what others are busy with and what interests me.

Yishai:  I also want to do this, I also want to be in a place like this. Excellent. So I have to thread in another question because I promised it was the last one but there will actually be two. We mentioned the topic of hiring, and I want to talk to you about how hiring corresponds with the world of upskilling. Mainly around the ability or desire to learn, I mean how much does it play a role in you deciding on hires or when you see organizations that have invested and learned how to do upskilling, how does this affect the hiring process for them?

Eti: So I think that with us specifically it had a great impact because some of the conversations I would have with candidates were about where do you want to go, what do you want to do, because it was important to me that I could create, even if not now, then create these opportunities in the future. Because if I have three managers in the organization and there is someone who really wants to manage, it is possible that in the near future I will not have this option, and this is something I like to put on the table, so that the candidate also knows this is the case. Besides, looking at the team like this and understanding what each one is strong at, what they are good at and what directions they are taking, allows you to also see what is missing. If you have strength in the backend team and you also need the frontend side, then maybe like in the search for employees I will look and look for someone who is stronger on this side.

Yishai: Are you looking at, say, the history of upskilling of employees you recruit? Did this candidate invest resources in this, invest thought, know how to articulate what is important to him or know how to articulate how to develop? Is this part of the criteria in your eyes?

Eti:  I don't think it's part of the criteria, it's part of the conversation. Most of the candidates I talked to knew where they wanted to go, and even if you don't know it's okay. It might be something we'll need if we start working together, to figure it out. We didn’t necessarily have this conversation.

Yishai: Yes, but you want to find some kind of openness to a yes, I understand that it is important, I want it, I have a desire for it, even if I don't know exactly where, but I want to develop.

Eti: Yes, I think most of us want to develop in one way or another, it doesn't have to be on the same track, because we are not the same people, but...

Yishai: Yes, you say you will find the way to find this desire of how to develop and make it a reality. Eti Dahan Noked, VPR R&D at Wilco, thank you very much for being with us. 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 areas. 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:

• Wilco
• LinkedIn Learning
• Checkmarx
• WeWork