On Freund, founder of Wilco and former VP of Engineering at WeWork, speaks with SE Radio’s Brijesh Ammanath about “upskilling” – going deeper or increasing the breadth of your skills. On has years of experience in helping developers master the skills needed to advance in their careers. This episode explores the importance of upskilling in a constantly evolving tech landscape. They focus particularly on how and why senior and expert developers should keep learning, upskilling, and reskilling throughout their careers. Freund offers suggestions on how to face some common challenges, especially for remote or distributed workers, and how and why engineering managers can help enable upskilling for their teams.
Show Notes
- www.trywilco.com
- Twitter: @onfreund
Past Episodes
- SE Radio 543: Jon Smart on Patterns and Anti-Patterns for Successful Software Delivery in Enterprises
- SE Radio 529: Jeff Perry on Career Management for Software Engineers
- SE Radio 524: Abi Noda on Developer Experience
- SE Radio 515: Swizec Teller on Becoming a Senior Engineer
- SE Radio 491: Chase Kocher on The Recruiting LifeCycle
- SE Radio 265: Pat Kua on Becoming a Tech Lead
- SE Radio 258: Cody Voellinger on Recruiting Software Engineer
Transcript
Transcript brought to you by IEEE Software magazine.
This transcript was automatically generated. To suggest improvements in the text, please contact [email protected] and include the episode number and URL.
Brijesh Ammanath 00:00:16 Welcome to Software Engineering Radio. I’m your host, Brijesh Ammanath, and today my guest is On Freund. On has years of experience in helping developers master the skills needed to advance in their career. On is passionate about creating new ways for developers to level up. He’s co-founder and CEO of Wilco, a free upskilling platform for developers. Prior to that, he was VP product and VP engineering at WeWork and VP Engineering at Handy. On is also an angel investor and advisor to startups. On, welcome to Software Engineering Radio. Is there anything I missed in your bio that you’d like to add?
On Freund 00:00:50 Thanks so much. No, I think you pretty much covered all of the professional aspects. I’d say I’m also an amateur drummer.
Brijesh Ammanath 00:00:58 Excellent, thank you. As the field of technologies constantly evolving, it’s crucial for engineers to stay current with the latest tools and technologies. We’ll be talking today about “upskilling,” on how developers need to keep learning, upskilling, and reskilling throughout their career. We have covered learning previously in episodes 543, episode 529, 524, 515, and 491. I’ll make sure we link to these in the show notes. Let’s start with the basics. So, from my perspective when I look at upskilling, or the closest other term that comes to mind is “reskilling,” which is, I have an employee or team member that I’m going to train to teach him or her to do something else. What is upskilling in that context? Is it same?
On Freund 00:01:43 Well, it is very similar. Those two terms do have a relation with each other. But for me, reskilling is the act of taking someone who’s skilled at one thing and making them skilled at something else. And those two things could be completely independent. So, for example, maybe I’m a salesperson and I’m going through a re-skilling program to make me a good marketer, for example. So that would be re-skilling. Upskilling is I have a specific skill set and I’m taking the steps needed to ensure that I become better in that skillset. So, for example, I could be a marketer, but I have some gaps in my knowledge in various areas. Maybe I’m only focused on PPC, but I haven’t learned anything having to do with brand marketing. So, I pick up brand marketing and to me that is a sort of upskilling. So, these were the examples outside of engineering. When we talk about engineering, the terms could be a bit more blurry because if I’m a full stack developer and I’m going through a process that turns me into a mobile developer, is that considered reskilling or upskilling? I can’t say that I have a good answer for that, but I would say that as long as you’re within the realm of software engineering, I would call it upskilling.
Brijesh Ammanath 00:03:02 Yep, that makes sense. So, if you are going deeper or increasing the breadth of your skills, that would be upskilling, whereas learning something completely new would be reskilling.
On Freund 00:03:12 Exactly.
Brijesh Ammanath 00:03:13 Right. You’ve also mentioned or talked previously about leveling up. What does that term mean?
On Freund 00:03:20 Yeah, so leveling up, unlike upskilling and reskilling, that sort of became industry terms, leveling up is a bit more informal. And to me, leveling up is if you are at a certain level — and I don’t want to put names some people might say junior engineer, senior engineer, if you have a career ladder, you might add titles such as staff engineer or principal engineer. And you could say that switching from one of these levels to another is leveling up. But I like to look at it as more holistic. You’re at a certain level, it doesn’t have to have a very clear and concise definition, but you’re at a certain level and you’ve picked up skills and you feel like you’re ready for more advanced stuff. So, you might, from a title perspective, level up every few years, but if you encountered something challenging — let’s say that for the first time you had to deal with something in production — to me that experience becomes a step function in your growth. And once you’ve completed that, in a way, you’ve leveled up.
Brijesh Ammanath 00:04:22 Right. So, it’s basically gaining experience and as you gain experience, you become more confident in dealing with that problem. You are almost transitioned to the next level.
On Freund 00:04:32 Exactly. And it’s not just confidence, by the way, to me it’s a combination of throughout this experience you’ve gained confidence, you’ve also gained more training for your data set, I would say. So, your pattern matching becomes better next time around. And you’ve also perhaps developed intuition as part of this. Eventually the experience, to me, is the combination of confidence, intuition, and pattern matching.
Brijesh Ammanath 00:04:56 Right. Related to that around professional development, do you have any suggestions on how an engineer should approach professional development? You’ve got to look at learning new skills, new abilities, as you want to progress in your career. But is there a mindful way one can approach professional development?
On Freund 00:05:15 It’s a great question. And I think that, first and foremost, I think it should absolutely be the goal for every engineer in their career. We are, most of the engineers I’ve met are very curious. And using that curiosity to gain further skills, I think, is one of the best ways we can do for both for our career and I would say also for our well-being, because most of the developers I know love development, and it’s not just a day job to them. They actually care about the profession and want to become better at what they do. The thing is, to become better it’s not necessarily just about writing better code, which is where I think a lot of the people are getting it wrong. Becoming a better engineer is a combination of many soft and hard skills that you need to pick up, and you need to find good ways to acquire them.
On Freund 00:06:05 So, I would say the first thing in your upskilling journey is to figure out where you want to go. And one of the nice things you can do is when you’re starting out, look around you and figure out who are your role models, and what have they achieved that you would like to achieve? And then start setting more specific goals on the way to get there. So, for one person, this could be, I want to become the top expert on topic X, and for another person that could be, I want to know a little about everything. And both of these are legitimate goals, and it varies by the character of the person. But first step in your upskilling path, just figure out where you want to get, what is your North star? And then from then on we can talk about the tactics to get there.
Brijesh Ammanath 00:06:53 Right. And throughout the session we will touch into various tactics. So, the first step is identify your North star and then work towards achieving that end state.
On Freund 00:07:03 Yeah. Exactly.
Brijesh Ammanath 00:07:04 Thanks. Moving on to the benefits of upskilling, I’d like to dig a bit deeper into that. Why has upskilling become more relevant now?
On Freund 00:07:13 Well, one thing that is hard to ignore is that technology keeps moving faster. So, the derivative, the rate of change, is becoming faster as well. And when everything is progressing and you’re staying in the same place, you’ve basically gone backwards. So, if you’re not taking the time to upskill, your skills are deteriorating. I’m no longer actively an engineer. I’ve switched over to management a few years ago. I think I was very skilled when I was an engineer. But then, looking at the world today, there are so many skills that I haven’t acquired. Like, I’ve never dealt with Kubernetes, for example, which has become the de facto standard for so many things these days. Right? So, staying in place could be a problem. And then more specifically, what’s happening today, two main secular shifts in our industry have a lot of impact.
On Freund 00:08:04 One of them is the advent of low-code and no-code platforms. And the other is AI. And everyone’s talking about ChatGPT, but this could also be GitHub Copilot or Tabnine. The combination of these two things mean that you as an engineer don’t have to focus as much on boiler plate as you used to in the past. So, the grunt work, the simple stuff is taken care of by machines. And when I say simple stuff, it could still be very time-consuming or had been time-consuming, but is no longer there. And now engineers really need to focus on advanced scenarios, on decision-making, on the places where humans shine. And getting the basics right is just not enough anymore.
Brijesh Ammanath 00:08:55 Agreed. I think I’m in a similar state where the technology landscape changes so quickly, the moment you step out of it for a short period the entire landscape changes. And it’s very difficult to then catch on or learn the new technologies.
On Freund 00:09:12 Exactly. I actually had to deal with it in the past. I kind of took a pause from engineering and had other roles and then came back, and I had to pick up completely new technologies — and we’re talking just 18 months. Within those 18 months, I had to pick up completely new technologies, methodologies. It’s crazy how fast it’s moving. We as engineers just the good thing is that if we have the basic skills right, we can pick up whatever change, we can pick it up quickly, but we always need to be at the top of our game.
Brijesh Ammanath 00:09:43 I have an entire section later on how engineering managers function in the new world and how they can support their teams on upskilling. So, we’ll come back to that. But continuing on the benefits of upskilling, what about the benefits for the firm?
On Freund 00:09:58 Well, first and foremost, if you look at research, you see that the number one motivator for software engineers is opportunities for professional growth. And there are so many surveys done on this topic, and it’s always the number one motivator — more than compensation or anything else. The second thing is, and it’s kind of the flip side, if you look at why people are leaving — so there is a McKinsey research on why people are leaving their jobs — and you see that the number one reason is lack of opportunities for professional growth. So, if not for anything else, I would say if you want to retain your top talent, make sure that you invest in their skills. The second thing, there’s a really cool comic strip that I like that has like two managers speaking to each other and one of them is saying, what if we invest in our people and they leave? And the other one is saying, well what if we don’t invest in them and they stay? So, obviously the better skilled the people are, the more productive they become, the less mistakes they make. And, we can always just try to hire more and more talent and more experienced people, but then sometimes it’s really a better approach to take the existing people you have and help them bridge whatever experience gap they have.
Brijesh Ammanath 00:11:18 Yeah, I’ve seen that comic strip. If we don’t upscale our employees and they stay, it just holds back the entire company from progressing to the next level.
On Freund 00:11:29 Yeah. The cost of someone who’s not good at what they do is disproportionately large. It’s really something you want to avoid in software engineering.
Brijesh Ammanath 00:11:40 Agreed. Related to the benefits, how important is it for engineers to have a diverse skillset?
On Freund 00:11:47 It’s a really good question and it relates to what I said earlier. Some people really want to focus on one thing and do it the best they can, and that’s okay. So, if you were a Cobol programmer in 1999, then all of the banks in the world wanted to get your time and were willing to pay top dollar for this. And having a narrow skillset actually worked in your favor during those years, especially if you were an expert. The reason I prefer to have a more diverse skillset is, A) because as we mentioned earlier, technology is changing rapidly and a rapid skillset allows you to evolve together with it. And two, I think that a lot of what we’re experiencing in one stack or one domain could be translated to another domain. So, I mentioned earlier that 18-month hiatus from software engineering and then coming back; I came back to something completely different.
On Freund 00:12:42 So, the last thing I did before that hiatus was working on Windows kernel device drivers. The first thing I did coming back was working on a Ruby on Rails web backend. Now these two are seemingly unrelated, but a lot of the skills I picked up in previous iterations helped me bridge the gap really quickly. So, I think a diverse skillset is super important. And then, I also think that there are a lot of skills that are always needed and always necessary. So, the ability to communicate with your team members, I don’t think anyone can live without that one, right? And the ability to do it in a respectful and efficient manner. The ability to take a problem and break it down into smaller problems, that’s definitely something you’re going to need in so many different domains. So, you could say, oh, I only want to focus on this specific language or this specific platform or this specific type of programming. But even if you’re doing that, I would say don’t focus on a specific skill. You still need to pick up all the skills that would allow you to work efficiently.
Brijesh Ammanath 00:13:52 Right. Can you give me an example how having a diverse skillset has helped you in your career?
On Freund 00:13:58 Yeah, certainly. So, I’m going to cheat a bit and switch to places where I was a manager. But when you’re a manager, you end up managing a large engineering team. And a large engineering team, by definition, is going to have different types of people. So, you’re going to have full stack web developers, and you’re going to have database people, and you’re going to have mobile developers, and front end, and basically anything, and data, and anything you can come up with. And the ability to have a conversation with each and every one of them, an informed conversation, is just priceless. Now, it doesn’t mean that you need to go speak to the database person and help them to write queries. That’s not the point. But when they come to you with ideas, when they come to you with requests for advice, you want to be able to have that conversation. And I did that as a manager, but it could also be for a staff engineer who spends a lot of time mentoring others. And if the only thing they know how to do is that specific area; if all they know is a specific type of algorithm or a specific backend language and nothing else, they’re going to have a really hard time mentoring people around them who are trying to pick up other skills.
Brijesh Ammanath 00:15:16 Yep, makes sense. So, what you’re saying is basically it helps you not only in coaching and mentoring your team, but also helps as you progress in your career to become an engineering manager because you’ve got a wider view in terms of the various things which happen in the entire technology stack.
On Freund 00:15:32 Exactly. And if you’re looking for a more tactical example, I would say I was working as a full stack developer, but actually it was more backend — maintaining the backend server — and the company got acquired and one of the first thing that happened post-acquisition is I actually had to deal with a production outage with the product of the acquiring company, which I knew nothing about. And the system was basically grinding to a halt, and no one was able to deal with it. And everyone kept increasing — so, this system had workers — and everyone kept increasing the number of workers to deal with the heavy load the system was experiencing. And even though I knew nothing about the system, I did know a thing or two about servers and backend systems and databases. And I quickly was able to figure out that it was actually the database that was the bottleneck, and the right way to fix it is not increasing the number of workers but actually decreasing it so the database can pick up and start processing things in the normal timeframe. So, even though I knew nothing about their server — it was written in a language that I wasn’t proficient at, it was a production system I was not familiar with — the fact that I had a diverse skillset enabled me to get into the situation and understand what was happening and then come up with a way to resolve it.
Brijesh Ammanath 00:16:56 That’s a very good example. We’ll move the next section in terms of looking at ways to upscale engineers need to take the initiative to learn new skills and improve their abilities in order to advance in their careers. What are the various avenues available to developers to upskill?
On Freund 00:17:11 Well, the first thing I would say, which I think is the most important thing, is figure out who are the people around you that you want to learn from. As much as it’s unscalable, software engineering in many ways is still sort of an apprenticeship model, and you want to find the best mentors around. So that is the first thing I would say. And the more people you have to learn from, the better because no one’s perfect, and you want to synthesize what you’re seeing from various people to be able to create your own career and your own style. So that is absolutely the number one piece of advice I would give to anyone wanting to upskill. And the second thing — and this is assuming, like we said earlier, that you’ve set your North star and where you want to get — is, apart from the people around, you figure out the resources that you have in your disposal.
On Freund 00:18:03 And I think if you want to maximize your learning, you need to combine two types of resources. You need something that’s more theoretical that’s going to give you the knowledge, and then you need something that’s more practical or hands-on that’s going to give you the skills or the wisdom. And on the theoretical side, this could be some sort of course, this could be at a university, it’s going to be an online course, it doesn’t really matter, reading a book. And then on the more practical side, you could contribute to open-source projects — even though they also have their limitations — but you can contribute to open-source projects, you can create your own side projects, you can practice using dedicated tools, but definitely make sure that you’re mixing the theory and the practice. One of them is simply not enough.
Brijesh Ammanath 00:18:52 Thanks. So, to summarize it, first, the starting point should be people or finding a mentor whom you can then work closely with to understand the resources available. And when you look at resources, there are two types of resources, theoretical and practical. And the practical ones ideally are the open-source contributions that you make?
On Freund 00:19:12 Well, I wouldn’t say ideally open-source contributions. I would say open-source contributions are one way of gaining hands-on experience, and it also has its disadvantages. So, contributing to open-source is great, but the workflow is usually different than the type of workflow you’ll see within a company. You’re most likely not maintaining a production system for that open-source project. There are a lot of limitations to that. So, try to combine as many ways of getting hands-on experience as possible. So that could be open-source contributions, side projects; we can talk about Wilco later. That’s another way to do that. The important thing is to mix various techniques.
Brijesh Ammanath 00:19:55 Right. We’ve touched on mentorship, I just want to dig a bit deeper into that. What is the role of mentorship and networking in professional development?
On Freund 00:20:04 So, it’s great question because it’s actually a topic we could probably talk for a full hour just about that. Mentorship is a very complicated, complex, and important relationship. And that’s why picking your mentors is really important. And these need to be people that not only represent what you want to achieve or where you’re striving to be, but also people who are able to create a good rapport with you and are able to point you in the right direction without judging. But also without micromanaging. A good mentor is going to ask you questions, is going to dig deeper into the various ways you are thinking of tackling a problem. So, let’s assume that you’re designing a new component and you want to get some advice from your mentor. One way a mentor can deal with this is say, oh, this is what I’ve done in the past. This is what you should be doing.
On Freund 00:21:04 Now this is great if the goal is to impart knowledge, but I think a better mentor is going to ask you, well what are the various ways that you are thinking about? What are the pros and cons that you’re seeing to each one of them? Now, they might add their own knowledge in between; you might say come up with a disadvantage of one of the ways that you were considering. And the mentor might point out, you know what that is actually not a meaningful con; you shouldn’t really be spending too much time on this. That’s okay imparting knowledge is one of the things that’s required out of this relationship, but it really needs to be a conversation where the mentor is encouraging you to think. And there are not a lot of people who can do that effectively. So, picking a good mentor is an art and science in itself, and it could really change the trajectory of your career
Brijesh Ammanath 00:21:59 If there are not many mentors or good mentors out there, any tips or suggestions on how one can go about finding and building relationships with mentors?
On Freund 00:22:11 Yeah, first of all, start with thinking as we said earlier, who are the people that you want to be like? And that could be because they have command of some specific hard skill set, but it also could be because you see, oh, these are people who are making everyone around them work better, right? That’s another thing you might want to learn in your career. And by the way, a very useful skill. So, figuring out who are the people that you should be learning from is the first step. The second step is — and this is a very tricky one — is understanding if you want your mentors to be from within your team or outside the team. And there’s no right or wrong answer here. A mentor within your team has way better context on the one hand, but on the other hand can seem as more biased or, at some point if they have a say in your promotion, could be seen by others as favoritism and things like that.
On Freund 00:23:11 So, once again, like I said earlier, you want to balance different mentors. So, I would say pick a few mentors both from them within your team and from outside the team. And this is a long-term relationship. So, before they become your mentors, they should really have — or you should really have a lot of hours spent with them. I mean this could be through work, this could be through various other channels, but you want to spend a lot of time with them discussing things. And in a way, at some point they’ve become an unofficial mentor, and then it’s up to you if you want to turn this into something a bit more formal or not. I really have no opinion this way or the other. But definitely spend that meaningful time with them beforehand.
Brijesh Ammanath 00:24:00 Okay, great. To make it a bit more concrete, and if you don’t mind revealing the details, what is your North star, and how has your journey been in terms of finding mentors and then building that relationship been?
On Freund 00:24:14 Of course. And in retrospect I actually wish I did a better job of defining my North star from the beginning. Luckily, I still got to where I am, but I didn’t really have a good North star in the beginning. And one of the reasons was that when I started my career as an engineer, the concept of separate IC and managerial tracks wasn’t as well-defined as it is today. So, some companies still had it, but today it’s become a defacto standard. Every company has a track for individual contributors and a track for managers. Back then, it didn’t really exist. So, if you wanted to get promoted — and I’m not talking about the very large tech companies like Microsoft, they always had this, but I’m talking about most other companies — you really had to become a manager in order to get promoted.
On Freund 00:25:08 And I kind of became a manager without even realizing that’s the decision I want to make. So, in retrospect, I was lucky because it is what I want to do, but I didn’t go through the right process of defining my North star. Once I did realize that I want to become a manager and a better manager, the first thing I did was look around me and see who are the managers that I admire. Who are doing a good job or who are doing a great job motivating their people, who are delivering at high speeds. There are various skills to management, but most importantly you need to, as they say, manage down, manage up, and manage sideways. So, thinking through who are the best managers for each of these three directions around me and just spending a lot of time with them. And at some point they sort of become your mentors, and they might be your direct managers as well, but if they’re good mentors, they continue to be those even when they’re not your direct managers. And this definitely happened to me with one of my first managers, and he was my team lead as I was an engineer and I have learned so much from him. And then I got promoted and we were actually peers for a while and then he got promoted and was once again my manager. And I was lucky to have him once again as the manager and not just as a mentor, but even in between he was always my mentor and always the person I went to seek advice from.
Brijesh Ammanath 00:26:35 Right. Thanks for that. A related question on management, so what are the various avenues for engineering managers to upscale?
On Freund 00:26:44 It’s a tough question because as managers, first of all there’s for let’s say that for every five engineers or six or seven or whatever, you’re going to have one manager. So, it’s just a smaller market and you’re not seeing as much content and tools geared towards engineering managers. So, it’s harder to get ahead. But the good thing is that being an engineering manager is kind of like being a manager outside of engineering. So there are a lot of resources on just being a good manager, just generally speaking. And then the second thing I would say, I mentioned earlier, managing up down, sideways. So, when we’re talking about sideways and up, these are things that I think engineering is not that different in, I mean it is different, but if how to manage sideways and upwards in a good way, you’ll know how to do it as an engineering manager, as well. Managing down is a bit different for engineering and for all the reasons we discussed earlier. So, because of that intrinsic motivation, because engineers are constantly looking for ways to upskill, managing down means supporting them on their growth path. And that means actively helping them find their North star and actively trying to match them with the right mentors, getting the right tools in their hands so they can gain experience. All of these things make great engineering managers.
Brijesh Ammanath 00:28:10 Right. Turning the perspective. So, looking from the perspective of an individual contributor, how does an individual contributor have a conversation or convince his or her manager that they need dedicated learning time if the manager is not actively promoting upskilling?
On Freund 00:28:27 Yeah, so first of all, if your manager is not actively promoting upskilling, in many cases it could be because they’re just too busy or have not given this active thought, but they’re still very interested in supporting you on that. So, this is where you need to take initiative and have a conversation with them and explain why this is important. And if you don’t manage to convince them and they’re not just actively not interested in supporting your upskilling but are actually not interested in supporting it at all, then that might be a good opportunity to look for a new manager. It doesn’t mean leaving the company that you’re in, maybe there’s another team within the company that is going to better support you. But definitely have that conversation. Most managers I know would be thrilled if their team members came up to them wanting help on their career path, and they would definitely love to do everything they can to help them.
On Freund 00:29:21 So, I definitely had points in my career where I didn’t give enough thought to upskilling, but whenever someone came up to me and said, oh I really think we should do this and that, I was very receptive to it. And this and that could be anything from conferences to books to courses, there are so many things that you can do to bring in workshops. There are a lot of things you can do. And then another thing you want to look into is whether your company has a dedicated budget for that. So, sometimes it’ll be called an L&D budget, which stands for learning and development. So, you want to understand your company might have an L&D budget per person, your engineering team might have an L&D budget per person. So, figure out where that is. And in some cases, even without your direct manager’s support, you might be able to use that budget towards things that you appreciate. And that means you’re going to have to have better mentors who are going to help you define what it is that you want to achieve if your manager is not supporting you. But at least you’ll have the budget to accomplish that. And most engineering teams I know starting from a certain size, definitely at a hundred people or above have some sort of L&D allowance.
Brijesh Ammanath 00:30:36 Right. And I think that’s a good segue to our next section, which is talking about engineering managers, the challenges they face and how they can enable upskilling. So, talking about the cost of upskilling, how do you justify the investment in learning and development –o, the L&D budget — to upper management?
On Freund 00:30:53 That’s a good point, and it’s kind of related to my previous answer. So, in the same way that you’re talking to your direct manager and trying to come up with your upskilling program for you, you could assume your direct manager is having that conversation with their manager trying to create an upskilling program for the team. And this levels all the way up. Now in companies with large engineering teams, there are usually enough advocates for upskilling that you as an individual engineer don’t actually have to convince the company that it’s important. You just have to steer the program in your right direction in the things you want to achieve. If it’s a small team, you might have to start from scratch. And I would start with things that don’t actually cost a lot. So if you’re a small team, you could come up to your manager and say something like, what if we do a weekly engineering meeting where every week someone comes up with a topic that they want to talk to the group about? And the topic could be directly related to something that happened or is part of the technology stack, or it could be something completely different that is somewhat related to what we’re doing.
On Freund 00:32:07 And, that’s a great way to start. And for the engineering manager, the only cost associated with it is the time allotted for that meeting. Now I’m not saying it’s a small cost. It’s definitely a big one. Getting all the engineers in one room for an hour is pretty expensive. But engineering time is, it works differently than what we think. There’s a limit, as knowledge workers there’s a limit to how much we can focus on any given problem in a row. And that’s why we like to say that we don’t like context switches, but then if you ask people how they solved a big problem, they’ll always say, oh, I took a break and did something else. Right? I thought about it in the shower. And so, actually taking an hour a week and just providing that context switch to people, even if they seem to be super busy, can actually I think be very productive.
Brijesh Ammanath 00:33:03 Yep. I’ve seen quite a lot of companies have the lunch and learn sessions where there are informal sessions where somebody within the company comes and presents and talks through a new technology.
On Freund 00:33:14 Yeah, exactly. Some people call it lunch and learn. Some people call it, I’ve heard the term brown bag because people bring the brown bag with the food into the meeting. Call it whatever you like. But just having that conversation on a weekly basis and having people come up with interesting topics could be great, and it really doesn’t have to be related to what we’re doing. So, back when I was at WeWork, we had those weekly conversations and we had someone speak about how they programmed the micro controller to remotely control their AC unit at home so they can turn it on before they get home. I gave a talk about how I created this algorithm for ranking sports groups. As long as it’s somewhat related to engineering and could pique your interest in something new, I think it’s worth it.
Brijesh Ammanath 00:34:06 As an engineering manager, how do you foster a culture of learning and development within your team?
On Freund 00:34:12 First and foremost, it starts with hiring. One of the things I hire for is curiosity, because I think curious people are always advancing or always upskilling and they tend to, it tends to be contagious. So, if you’re surrounded by a lot of curious people, there’s a good chance that some of it is rubbing off on you. So, starts with hiring.
Brijesh Ammanath 00:34:36 Sorry if I can interrupt over there. And how do you measure curiosity in an interview setting?
On Freund 00:34:43 It’s more art than science I would say, but the key thing for me is asking them about things they’ve done and then trying to push the boundary of what they’re explaining to me. So, talk about a system that you’ve built is great, but then I would ask them about a component that they didn’t have a direct interaction with and what do they know about it? Talk to them through a decision they’ve made, and as they explain the pros and cons you’re going to figure out how much they’ve actually spent in researching things around it. Talk to them about alternatives that they’ve learned after the fact. If you would’ve done it today, what would you have done differently? And part of it is going to be lessons that they’ve learned and, and another part is going to be just things — unrelated things — that they’ve picked up along the way and have changed their view on things. So, it’s just about finding the right questions that are close to what you’re talking about but not directly at it.
Brijesh Ammanath 00:35:46 Yep. Very helpful. Apologies for interrupting. So, you mentioned the first point around building a culture is hiring?
On Freund 00:35:52 Yeah. Some people say that culture eventually boils down to who you hire, who you fire, nd who you promote because that kind of sends the signal on what type of behavior is appreciated at the company. So definitely hire people who are learners, that’s the first thing. The second thing is showing that you care. And that means doing those lunch and learns or brown bag talks; that means showing that you develop. Sharing things that you’ve picked up with a team. When they see that you’ve picked up something new — and they know you’re super busy, right? — but they see you pick up something new, they say, oh this is great and if my manager was able to find the time to pick up new skills, maybe I can do that too. So that’s the second thing. And then the third thing, and really the number one tool I think for managers is always the one-on-ones with their team members. So, during the one-on-one, what I like to do is almost never talk about progress or anything like that. There are ways to give out progress reports. To me one-on-ones are all about supporting the growth of the person in front of me, and dedicating the entire conversation to it both creates the understanding with them that I am mindful of it, that I’m encouraging them to do that, and also allows us to discuss tactics and figure out the best ways for them to upskill.
Brijesh Ammanath 00:37:22 Right. To summarize, the first one that you should focus on is hiring. And if you get that right, you don’t need to do the firing. The second one is around caring for your team members’ career progression and growth. And the last one is having quality one-on-ones.
On Freund 00:37:37 Yeah. And also, leading by example.
Brijesh Ammanath 00:37:40 Leading by example. We have a session on software engineering radio around one-to-one where we do a deep dive on that topic with Vidal Gaupera and I’ll make sure we have a link to that in the show notes. What are some strategies you use to identify skill gaps within your teams?
On Freund 00:37:58 That is a really hard one. So, first of all, we’ll start by saying that many of the skills in engineering are not measurable in an easy way, right? So, some other functions in the organization or some other disciplines might be easier to measure. And the classic, classic example is always sales. Eventually there is a result, and it’s easy to measure salespeople by it. Whereas, with engineering, even though in one aspect we’re the most scientific part of the organization, but when it comes to measurements, we’re actually the least scientific part of it. So, it’s really hard to measure and this is where good managers have to shine. And eventually subjective reporting is as important tool as everything as anything else in this regard. So the ability of a team lead to say we’re missing out on this skillset and being able to escalate that, or the ability of a VP of engineering to say we’re understaffed on database expertise, we really need to hire for this or really need to train people on this, it really needs to bubble up for that to succeed.
On Freund 00:39:09 However, there are tools to help you map this out, and there are tools that would try to extract things from your code base. And a lot of the L&D tools, one of the things they’ll try to do is map out the various skill sets that people have and then present a sort of centralized report, so it doesn’t have to be on the specific individual, it’s more aggregated — the skills that you have in the team, the skills that are progressing in the team, et cetera. But eventually there’s no replacement to bubbling this information up the chain from the individual. And the more honest they could be with themselves, the better off they’ll be and the easier it is for them to progress. And then ,all the way up to the VP of engineering.
Brijesh Ammanath 00:39:54 Right. Also in the context of upskilling as an engineering manager, how do you balance the need for engineers to work on current projects with the need for them to upskill for the future? So, how do you balance the short-term demands with the long-term development of your team?
On Freund 00:40:12 Yeah, it’s always a tricky balance, and I want to go back to what I said earlier about engineers’ time working a bit differently. So, I mentioned that engineers are actually looking for context switches even though they say that they aren’t and they hate it, they actually need it. You could say it’s a necessary evil. Engineers actually, I believe, have a limit to the number of productive hours they can contribute in a day. And if they’re in the office — or it doesn’t have to be in the office; it could be remote — but if they’re actively working for eight hours, they’re most likely not working on production code for eight hours. They’re doing a lot of other things, as well. And one of those things I think, or one of the most important things, I think, should be investing in their upskilling and they’re within those eight hours a day, there’s actually a lot of time to fit in a lot of different things.
On Freund 00:41:10 Maybe they’re waiting on a code review; maybe they just need some context switch to solve a problem that they’ve been banging their head against the wall with. Maybe they completed a very difficult task, they need some time off. The cool thing is that upskilling actually lets you use up your time in a very effective way while still clearing your head. So, if I finish something big, I can go on social media; and that’s probably not going to be very productive, but that’s sort of a pause that I need. But then if I, instead of going on social media, I use that pause for professional development, then I’ve achieved two goals in one. I was able to get that pause and get that context switch, but it also became productive. So, find avenues where your people can spend 30 minutes on something that’s going to help their professional growth.
On Freund 00:42:06 And that’s one. The second thing is, I mentioned earlier that in a way we’re still an apprenticeship kind of profession and that means that whenever you are progressing there is a good chance that there’s someone a bit more senior than you who’s also spending active time on that progression. If I can support you on your growth path without needing another human in the picture, then I’ve actually freed up time rather than taken up time. And that really helps as you’re talking about the balance between investing in now and investing in the future. If that future investment is actually saving me time now, then it becomes a no-brainer.
Brijesh Ammanath 00:42:47 Right. Agreed. We talked about culture earlier and I just wanted to understand, how does that operate in the current environment where most of the teams are operating either in a hybrid fashion or where you have remote or distributed teams? Are there some strategies to ensure that the remote teams also are part of that same culture and feel equally involved?
On Freund 00:43:10 Yeah, remote is very tricky in that sense. One of the things that’s really missing with remote is the ability to tap someone on the shoulder and ask for advice. And it’s hard to do remotely. So, the first thing I would do is figure out some social norm within your company that’s the equivalent of tapping on the shoulder. If it’s across time zones, it becomes more complicated. But hopefully you can find the people in your time zone or at least in an overlapping time zone that you can have that tap-on-the-shoulder moment with. That’s the first thing. The second thing is, as you’re picking up skills, one of the most difficult things is what we call the unknown unknowns, right? These are the things that you should pick up and you don’t know about. So, the better that the knowledge is preserved within your organization, the ability for people to find things that they- didn’t even know that they need to know, the more you can support the culture of upskilling.
On Freund 00:44:13 So, let’s say that when I joined the on-call rotation in the team, one of the biggest or most frequent things I’ll tackle would be some admin interface that acts weirdly every time. Now if I don’t know that I need to learn about it, then I’m going to be unprepared for my on-call shift. But if there’s a good knowledge base of the things most likely to break when you’re on call, then I know what to look for and I can pick up those skills that I need to be ready to field that when it does happen.
Brijesh Ammanath 00:44:51 Right. Any examples where firms have implemented a good social norm for that tap-on-shoulder for remote teams? How do they do it?
On Freund 00:44:59 Yeah, this could be a dedicated Slack channel where — you could even call it a tap on the shoulder channel — and people join it when they’re ready to be interrupted, and then someone can just come into this, the channel and seek advice when they need it. So that’s one way I’ve seen this work. In the beginning when — beginning, well… a few years ago when people started exploring with how remote works, I’ve seen teams that are constantly on video with each other, and when you do that you feel a bit more comfortable virtually tapping someone on the shoulder because if you’re also looking at them… (I have to admit I’m not a huge fan of that. Feels a bit weird to me to be in an office like that.) So, definitely finding the async ways of doing that, use your corporate chat to your advantage, but also keep in mind that as everything async, it means that it becomes eventually consistent but not necessarily immediately. So if you’re tapping someone on the shoulder over a chat, you might actually get a response an hour later or maybe six hours later. And that’s why it’s important to have things that you can context switch into while you’re waiting for that. And that goes again to why I think that upscaling doesn’t really take time because there are so many opportunities for you to pick up other things as you’re waiting on things.
Brijesh Ammanath 00:46:27 I wanted to talk about a challenge that engineering managers sometimes run into, which is the resistance to change. So, some employees may resist upskilling, especially if they feel that current skills and experiences are sufficient for the present job or the current job. How do you talk to them and tell them that the new scripts and technologies, though not immediately relevant could help them in the future? How do you address this problem or how do you have that conversation with such employees or team members?
On Freund 00:47:00 Yeah, first of all, you, you need to go into this understanding that there’s only so much you can do to influence other people. And if eventually they don’t see upskilling as an important investment for them, there’s a good chance you might not convince them. The easiest way to convince them is through culture. I mentioned earlier, who you hire, who you fire, who you promote. If they see everyone around them investing in their skillset and getting promoted while they’re staying in place, then that could have an impact on them, right? That could be actions speak louder than words. And if I’m seeing that I’m not investing anything in my professional growth, and I’m the only one around that’s staying in place, there’s a good chance I’m going to get convinced. I would also share my history — situations where I was able to leverage seemingly unrelated skills, or talk to them about stories of people with similar concerns about upskilling that eventually did invest in their upskilling and the things they were able to achieve.
On Freund 00:48:07 But I think the trickiest situations are with the busy bee types? These are people who are always busy, and they just can’t seem to find the time to do anything. And the first thing you want to do with them is help them with time management skills. And once you do that, they not only get more time, but they also realize how skills that aren’t directly related to their job can also be very beneficial. So, figure out who’s the best time management expert around and bring them in for a conversation.
Brijesh Ammanath 00:48:41 And I think sometimes it’s a reflection of the environment you’re operating in. So, if your team is constantly firefighting, that means you don’t have time for upskilling. So maybe you need to look at how do you create that time to bring stability and resilience into your product or environment.
On Freund 00:48:58 Absolutely.
Brijesh Ammanath 00:49:00 Moving on to the next section, which is around measurement. We’ve already touched on it previously, but digging a bit deeper into it, how do you measure the return on investment on upskilling efforts?
On Freund 00:49:11 Yeah once again, going back to what I said about those things not being very easily measurable, the best place to start is self-reported. And when I say self-reported, that means the person and their direct manager. If I’m saying I feel like I’m behind on skills A, B, and C, but I’m really getting ahead on skills D, E and F — and I can do it in an honest fashion and then my team lead can also give me pointers and say something like, you know what, I think you’re actually too hard on yourself with skill A. I think you’re doing okay B and C, you’re right, you need to pick up the pace. D that you thought is going well, well I’d actually like to see you do better, and E and F are really doing great.
On Freund 00:49:55 So the synthesis of you and your direct manager should go a long way towards measuring the team. Now if you’re talking about a larger team and not just the individual, then you can start looking at all sorts of proxy metrics. So, let’s say that there’s an infrastructure team at your company and when something breaks in the infrastructure, you open a support ticket. What you can do is figure out how people are learning the infrastructure or getting better skills with that infrastructure by looking at the number of tickets. And as it goes down, assuming the infrastructure stays the same, if the number of ticket tickets go down, it’s a good assumption to make that people are better trained with it. Right? So that could be an objective metric. If training is happening during onboarding, you can measure the time it takes for people to become productive, or their contributions in the first few months, or the number of bugs they put into production in the first few months. Each of those by itself is not a good metric because it’s easy to game, and it’s easy to put too much weight into meaningless things. But a combination of many of these could be a good way to measure things. So, be very context-sensitive and figure out the proxy metrics that are going to provide the more objective measure, and use that to balance the subjective measure of the individuals and their team leads.
Brijesh Ammanath 00:51:33 Got it. It’s a difficult problem, but one has to keep the context in mind and use various proxy measures to get a holistic picture.
On Freund 00:51:41 Yep, exactly.
Brijesh Ammanath 00:51:43 And any thoughts in terms of how do you keep track of the capabilities of your team? Because as people upsckill, the skills are going to change. You could have hired a T-shaped developer who quickly becomes pie shaped or cone shaped skill, has DevOps and learns those skills, and how do you keep track of that capabilities?
On Freund 00:52:05 Yeah, it’s a great question and this is where I think it’s first and foremost on the team lead level to notice these things and notice who’s picking up new skills but also who’s losing skills, right? Because there’s a good chance that as you’re picking up new skills, you might be losing some of the others that you’re not exercising as often. So, it’s really up to the team lead to find a balance, and as they bubble it up all the way to the VP of engineering, then they have to look at the organization as a whole and make decisions based on that. But each level really needs to have a skill map of the various skills on the team, which ones are progressing, which ones are declining, which ones are going to need more work. In essence, I would say it’s an exercise in good management.
Brijesh Ammanath 00:52:56 Yep. Agreed. In the last section, I’d like to close off the show talking about what’s in the future. We have already touched on low-code, no-code, also about AI, but how do you identify which emerging technologies are most relevant to your team and to your business?
On Freund 00:53:11 Well, first of all it’s really hard. In Hebrew we like to say that prophecy is a fool’s errand. And we’ve all made really, really bad forecasts. So, we have to be very careful. And I think the trick is to invest the minimum amount required in a given piece of technology to figure out if you need to invest more in it, right? Sort of like a pyramid where at the bottom you invest the very minimum you need to understand and at the top this is a skill or a technology that you want to spend a lot of time on. Some companies might create some shortcuts for you. There are a lot of technology radars out there that would talk about the emerging technologies and which ones you should be adopting and which ones you might actually should be dropping. And you also want to listen to your people.
On Freund 00:54:05 So, I mentioned earlier about hiring curious people. There’s a good chance those curious people are going to spend time — even sometimes their free time — looking through new technologies, trying to figure out which ones are a right fit for the team. I know that when I was an engineer, I came to my team lead quite a lot with, this is really interesting, what if we try this? or this is really interesting, I don’t think there’s anything we can do with it right now, but it’s definitely something to keep in mind for the future. So, trusting your people, sending them out there to pick up things, whether it’s through conferences or through just reading, and then trusting their judgment to bring the right types of technologies back to you. I think you also want to balance this with some top-down thinking too, though. So, especially if we look at a company like Wilco, we also need to think not just which technologies are relevant for us, but because of what we do, we need to think through which technologies are going to be relevant to engineering teams, in general. And that requires kind of a balance of not just individuals coming up with ideas, but also more concentrated thinking and trying to identify major themes in the industry.
Brijesh Ammanath 00:55:19 What is your firm doing in the upskilling space?
On Freund 00:55:22 So Wilco, you can think of it kind of like a flight simulator, but for software instead of for aviation. So, we let developers join a fantasy company, and that company has a production-like system with logging and monitoring and analytics and load balancing and a real data set. But more importantly, it also has colleagues (that would be virtual colleagues) and team leads and product managers and support people. And on top of that, you go on simulations of real-world scenarios. So, this could be something like, hey, we have a performance problem in production, please figure out what happened, what’s the root cause, what’s the extent of the damage, fix it, and communicate it to stakeholders. So, we do that and the focus is not on the fix it part, which is more the theoretical aspect of things. I spoke earlier about the need to balance theory and hands-on experience. But for us, when you go through something like this, we want you to focus on how do you even know that something went wrong in production. What do you do to investigate it? When do you go for a quick and dirty fix? When do you go for something more meaningful? How do you ensure that lessons are learned and implemented? All these little things that we pick up throughout our career and make up our experience,
Brijesh Ammanath 00:56:36 That’s a very interesting approach to upskilling. And who’s your primary target audience?
On Freund 00:56:42 So, we have a free version that anyone can sign up to and play quests from within our catalog. And these are quests that we’ve written, but also quests contributed by the community — anyone can also build their own scenarios on top of Wilco — and also quests built by our partners. We have partners such as New Relic and Circle CI and Docker and a few others. So, you can play all of this content for free. And then, companies that want to invest in upskilling their teams can get the business edition of the product. That’s going to give them way more features and the ability to create their own custom quests for internal use, connect their own code base so that the quests can run on top of the platforms that they want to deal with, and also get the reporting, which goes into many of the questions you asked me earlier about how do I know which skills I have on the team and which ones are in need. So, getting that report from Wilco can really help you get the answers you need for that.
Brijesh Ammanath 00:57:41 No, I completely agree. I think you have so many firms going through a transformation journey and the challenge as you implement the new product, but you have no idea how it’s going to be supported, or is the team trained enough to be able to support it post go-live. So, I think Wilco the product over here will be a good addition to ensure, to give that comfort to stakeholders — business and technology — that the team is ready to support it post go-live.
On Freund 00:58:07 Yeah, definitely. And this is both for just the generic upskilling of your team and everything we discussed today. And also, for more specific scenarios, like helping someone join the on-call rotation, or boarding someone, someone new, picking up a new piece of tech, or maybe you’ve switched from one vendor to another. Eventually, there are a lot of events within the lifecycle of an engineer that requires an investment in their skills.
Brijesh Ammanath 00:58:33 We covered a lot of ground here, but if there is one thing a software engineer should remember from the entire session, what would it be?
On Freund 00:58:41 I would say two things. First, own your career path. Figure out your North star, where you want to be and invest in it. Like I said earlier, if you’re not moving ahead, you’re getting behind. And the second thing is, remember it’s eventually it’s a people’s profession. Find the right mentors. Invest in your soft skills. The ability to get along with people on the team is way more important than any line of code.
Brijesh Ammanath 00:59:07 Completely agree. Was there anything we missed that you’d like to mention?
On Freund 00:59:11 I think we covered quite a lot. This was very comprehensive.
Brijesh Ammanath 00:59:14 Thanks, On. If people can follow you on Twitter, but how else can people get in touch?
On Freund 00:59:18 Sure. Well first of all, my DM is open so they can just ping me on Twitter. If you’re playing Wilco, you can always use our intercom or any of our support channels to reach out, and also share your feedback, we love that too. And looking forward to hearing what everyone thinks about our product and the type of progress they’ve had and if in any way impacted your career, that’s definitely something we’d love to hear.
Brijesh Ammanath 00:59:46 Thank you for coming on the show. It’s been a real pleasure. This is Brijesh Ammanath for Software Engineering Radio. Thank you for listening.
On Freund 00:59:53 Thank you. Pleasure was all mine.
[End of Audio]
