Software Engineering, Big Tech, and Agile - Interview With Jade Wilson

there's there's so many people in the market that have those soft skills whereas um if if you don't like work on those together. I definitely think like >> is it possible for big tech companies to have any type of agility when it comes to software engineering? What about companies like Microsoft? Is Microsoft too big to have any type of agility or is it all basically waterfall throughout the company? Hi, my name is Nick Cantino and I'm a principal software engineering manager at Microsoft. In this video, I was joined by Jade Wilson, who's a senior software engineer at Microsoft. And I thought this conversation was so awesome because we have very different experiences because of where we work within Microsoft. In this video, I was explaining to Jade how I work with more platform teams over the past few years. Jade, on the other hand, ends up working more customerf facing, which is really cool because we have very different types of interactions with respect to how we build software. Jade is also a very successful content creator. She's very big on LinkedIn. She has a newsletter and she's a YouTube creator as well. I think that you're really going to enjoy this video and I'd appreciate it if you could leave some comments below if you want to see more material like this. Thanks. Sit back and enjoy. I know like we were just mentioning like you like to focus on agile, right? You like to focus on DevOps. I know you talk about hiring, recruiting, all these. You talk about a lot of different things which is great, but how do you find like kind of steering your content or I don't know like how to how to balance it? Uh, I think like I'm definitely deviating more towards like I'm definitely deviating more towards like the like talking side and I think that is just because um I I've gotten really comfortable with it. Um whereas like uh the the coding side is something that I'm working on but it's like more in the background because it's much like it takes much longer to do. Um so it's kind of like just prioritizing. Okay. Well, like I've kind of set myself like a goal of basically trying to post like once a week and that's the the goal that I've been trying to set and it's been that thing of okay well it might not be the best now but it's slowly getting better and it's like I can see like you know the improvements are getting better and whenever I've got like an idea for what I want to do for either a blog or video then I just write it down of like these are the ideas that I've got. Um, and then I start planning out like um like I start planning out like high level like you know areas for that video like of what I want to cover. >> So uh at the moment I've got a few things um lined up such as the next video is um like how does stocks work at at a big tech company because that's something that when I joined Microsoft like I had no idea how stocks worked and I found it really confusing. So, it's just a little breakdown of okay, this is what they mean like what's the difference between vested and uninvested stock and like how do do you actually get what do you get in terms of cash like basically compensation wise >> and then like I slowly just start breaking it down by titles and then um and then I've got titles to talk about and then I talk about in the video and then I then write it down in the blog. That's the way that it seems to work and it all kind of comes together all at once at the end. Um, and then um, and then I've got a few videos that I want to do regarding like integration testing and using integration tests to refactor code when code isn't necessarily written in a way that you would unit test it >> and then then basically saying okay well now you've got these integration tests you can then refactor it so you can write good unit tests for it. >> I love it. Yep. >> Um because I think a lot of people get like they start writing unit tests for something that isn't necessarily designed in a way that should be unit test and it's like okay well let's take a step back let's not do that and let's write in a way that maybe we could write unit tests for. >> Yeah. The the first step ends up being they go oh like we have this code we're not happy with it. We'd like to refactor it or rewrite it or whatever. Like do some heavy lifting with it. Let's go unit test the crap out of it. and then they do it and then they're like cool now go touch all the code and it's like like you might not have picked the right type of test for for what you're about to go do. So that's I think that's a really cool topic. >> Yeah. So so that's what I've been working at the moment. But then it's just it's it's literally just been like planning it out and um I want to have good examples so I can say okay like this is how you could ref this is how it how it looks and it's getting there. It's getting there at the moment. So, I'm really h I'm happy with the way that it's looking and now now that it's um now that it's getting there, um that should be a good series. >> Um and then um I've done a few things regarding like um one of the areas that I'm really really interested in with regards to agile and DevOps is the actual it's not really about um like agile in like agile is a kind of buzz word that's used a lot of the time. It's more about It's more about like what is the best like way of delivering software for the context that you've got because context is different and context is important. So like not everything fits um like scrum like delivery for example and something might fit actually more like a camban style approach. Um, and then not every And then sometimes you could actually work in like um a waterfall way if you've done it repeatably before, like if you're doing um like especially with like uh deliveries where you're like installing things like um Azure and you're you're you're moving something from on on prem to to Azure. That's a very very like um like repeatable process. You just need to apply it to a new customer. And so you can't say like one type of delivery is the right way of delivering things. >> Of course. Yeah, that's a really good insight for sure because a lot of people will I I I hear it a and read it a lot more now where it's like agile has failed like agile doesn't work and it's like are you saying that because you picked scrum or you picked cannon or some implementation and you're saying look it doesn't work across everything and it's like I don't know if anyone ever said that like you're kind of I feel like people are making this argument that's not anything someone claimed so the fact that you said like you like focusing on agile but it could be these different types of like flavors of agile or it could be not even agile at all if that happens to be the better process. I think that's super cool >> and I think like a lot of the times people really try and focus on the process without any of the actual like values of of what it means. Um, and so they they focus on, okay, let's do scrum, but let's just do like the like events. Um, so we're going to do a retro, we're going to do a review, we're going to do planning, and we're going to do the daily scrum, like the daily scrum. And there's no like heart there. There's no like you know there's no there's no actual like like scrum is like um like set upon like values of like openness, courage, respect and things like that and that is just not there and they're just following the process for the process sake and like they're kind of been forced into doing that process which kind of removes a lot of that like actual like ownership that the team have right >> um >> and so it's all about working with the team to figure out what it is that they want because if they're being forced to say like either do story points or they're being forced to not do story points, then they're not making this decision what's best for them. Um, and yes, there's like a >> yes, there's a balance that needs to be had with the team and the rest of the department of course, >> okay, we need to get like we need to build a relationship there like of of trust. But like I think sometimes like there's external factors that kind of solve the problem for the team and that's not the the right way to go about it sometimes. >> Right. It's it's interesting. I you know John Cricut obviously I was just talking with John the other day and one of the things that came up in the conversation was like uh I can't remember the exact scenario but he was talking about working with I suppose some some type of PM role where they were saying like you know they're certified as a scrum master and they're like well we have to do retros and I guess the way that they were structuring it was not efficient. So like he he firmly believes like the retros are valuable but he asked them like well why like why are we doing this particular meeting and they didn't have a good reason for it. It was just like well I'm certified in this. That's what you do in this process. And as you were explaining that I thought that was I've seen this before. It was really cool to hear John say it. And this this idea that people are taking like the process which is almost defeating the point of I what I feel like a lot of these agile processes we're supposed to be solving. It's not just to have a process. It's like this isn't an implementation that helps us get these values that we believe in. And if you don't have the why behind why you're doing the ritual, the the different process, the cadence, whatever it happens to be, then I just feel like, yeah, you missed all of the value and it probably feels worse. And and you you tend to find with that as well is okay you go through these motions you have these meetings but you don't really get the maximum output that you would get from these meetings of okay well a retrospective should be really about a like is there anything that we can do um to be better next time. Is there anything that like you know we can improve on this process? What things went wrong? And yes, sometimes, you know, like you can have a little bit of complaining and that's absolutely perfectly healthy routine. It's sometimes a good thing for them to vent. Um, but they need to feel like they can make actionable change. And they also need to feel like if they say something that is wrong that is maybe like, you know, a business problem that they can actually there's something that can be done about that as well, right? >> Um, so >> you're not in a vacuum saying like this was really challenging. this is kind of it sucks for our team to have to do this. Now we're just venting and it's like cool like see you see you next week or in two weeks from now we can vent again. It's like it's okay to I had teams where like we were venting all the time but we would always use that to drive action. We're like this is frustrating us. Okay, good. We got that off our chest. What are we going to do about it? Like who do we need to talk to? What's the action that happened? Because if you don't do that, people would say like, "Oh, you downward spiral if you're only talking negative." And it's like, "You do if you're not taking action, but like we would fuel everything we did with like we don't like like we're uncomfortable with this. We don't want to be uncomfortable. What can we do?" And retros were awesome for us in that regard. One of the things that like I did um quite mistakenly when I started like the first time I was a scrum master um is I tried to take too much of that kind of responsibility and ownership of of things um when when I was a scrum master and I thought okay well I can I can take this action and I can try and unblock the team from that when actually what I really should have been doing is pushing it back on the team on what can you do to unblock this? what can you do to, you know, make this better to get that? Because by doing the thing that I did before, I was making the team more reliant on me to kind of block those things to remove those impediments whereas really I should have been >> making the team less reliant on me and making them be the ones to to resolve them themselves. And actually you find like when you do that and you start being a bit more pushed back to the team, get them to unblock themselves, they become a lot more like, you know, self- sustainable and and and and like more more efficient together and and that self-organizing u culture that you want to embody. >> Absolutely. I think that's a really good observation and it's I not my current team. I just switched teams at the beginning of this year, but the last team I was managing. This was actually a challenge for me where I came in as the manager and I was like, I don't I'm not here to go like disrupt everything you're doing because I think that's a huge mistake. But I am there to try and help everyone improve. And I don't like saying agile only because I think it carries so much weight and people get it confused. So I just like saying I like continuous improvement because I think that's what agile is actually about. just it's a little bit less painful to have conversations where people get heated about it. So continuous improvement, but when I I tried to push back on the team a lot to say, hey, like let's talk about the challenges you're facing and I was finding that people weren't speaking up a lot and I was like, how do I how do I balance exactly as you said, I don't want to just do the like, you know, not do the work for them, but for the retro do the work for them like, hey, I noticed that this was a a big pain point. I need them to do it so that they can go look I I identified a painoint other people on the team agree with this. I want to propose a solution and we can see that our input is being heard and we're acting on it. So I found that very challenging in the last team because not a lot of responses were coming forward and I didn't want to step on feet. So >> how did you manage to kind of overcome that? >> Yeah, it was I don't know. I want to admit like I don't think that I ever overcame it but I think a couple of things were going on the team a lot of people on the team were uh either junior or like relatively new to Microsoft so I think over time it started to get better um certainly not to a and this isn't their fault or anything but certainly not to a point where I felt like people could speak about anything and be like heck yeah we're going to like make this better because I'd talk in one-on- ones and I would hear that they still had pain points and stuff like oh the builds take too long or whatever it happened to be like some kind of challenges and I would remind them like hey this is that's a great topic for the retro. Um, I I started to interject a little bit and kind of and kind of say things like I heard like from multiple people in one-on- ones like this was a bit of a challenge like so when we would go do the retro we used uh in DevOps like Azure DevOps there's like the the virtual like uh sticky note board to put your your uh kind of like why wish wonder like start stop. >> Yeah, we we using that in a short time app as well. It's pretty good to be fair. >> Yeah. So I was I was using that and I would start to kind of seed some of the ideas like hey like I noticed this and then when we'd start to talk about it I was at least getting more responses. So that was helpful I thought but I think what was still missing by the end of it was I didn't feel like enough people were coming forward with the original ideas like they they started to have that reliance on me or they always had the reliance on me I guess but >> yeah it's it's quite it is quite a challenge to um like remove that reliance I found like one thing that worked really well in in in places that we did in the past was kind of switching it up between um between members um who was going to run the board like the the next week um to try >> you give some like some responsibility to people, right? >> Yeah, that that seemed to work really well in my old company. Um we we did that we did that quite a lot and um and that was that was good uh because because I was I was a lead engineer there. I didn't want to be the one to always run the board because um as much as I like uh facilitation, it can be quite um you know when like um there's always a challenge with remote where like if someone keep is the same person running things time and time again like it can get quite monotonous. Um >> I don't know if you found the same. >> Yeah. >> Yeah. Do do you work mostly remotely? >> I do. Um, and so I started like, and this is actually a maybe a cool segue, too, cuz I want to hear about some of your your Microsoft journey and like the probably day in the life. I think would be super cool. I know every day is maybe not the same, but um I did switch teams recently. I mentioned that a little bit earlier, but the previous team I was on, everyone was remote. Um the So I I ran two feature crews out of a bigger team, and everyone on my feature crews was remote. a couple of other people from the bigger team. They'd go into the office periodically. Um, but those are the people that I would already be interacting with on teams anyway. Like I didn't have a good reason to go in. So if my entire team was remote, I live like 30 to 40 minutes away from the office. I'm like, it's just not worth it for me to go in just to get on Teams calls. So for about three years, I I didn't go into the office. I went into the office like a couple times. Um, and the new team that I'm on, they actually do have people that go in, not every day, but like consistently a couple times a week. So, I'm kind of trying to get back into the mindset of like, cool, like, how can I make sure that I can be present for some of that? Uh, I love working remote. Um I I don't know the flexibility is great as a manager especially working with people in China not so much in India but if there's different time zones and stuff like I want to make sure that I have flexibility for work life balance so if I have to stay late for meetings with China I encourage my team like if you're doing the same thing don't work like a 12-hour day or if you happen to because that's the most convenient thing like the next day like start late or end early. Like you need to balance that. So I love that flexibility. But I have I'm starting tomorrow actually. I'm going to be trying to go into the office on Wednesdays. >> Are you um like uh M1, M2, M3? Which one? Like which uh are you? >> I I think it would be M1. So like for level it would be like a 65 like principal like the first level principal. >> Yeah. Yeah. The the reason why I asked is just because I'm trying to I was trying to figure out whether or not you do like the like you have a single team or do you have multiple do you watch multiple teams? >> It would be one single team. Yeah. Um and I use the word feature crew. I don't know if that's necess like I've heard a this is the second team that I've been on where we have feature crews that are just more like project areas but >> yeah. >> Yeah. So, um just I guess to explain for people out from Microsoft, you kind of this the structure is typically um you have um like a a crew and then if correct me if I'm wrong and then you have like a manager for that crew which is an M1 and then you have an M2 which like covers the M1s and then you have like an M3 that covers the M2s. Is that I think that's right, isn't it? >> Yeah. It's interesting though at Microsoft I've not heard M1, M2, M3. seen like if I were to look at like evil levels can't speak levels FYI there we go u so if you're looking at the site that shows you like the compensation differences and all that I think for like Amazon and Google I've seen that and they might even say it for Microsoft but I think like so for me it would just be uh principal software engineering manager then there's uh principal group I think it's group engineering manager so we call them gems I think that's the first like sort of M2 that you get because then you become a manager of managers. >> Yeah. Yeah. Um Yeah. So like with my with with my um boss, he just recently got promoted um from an M1 to an M2, but the level I don't know if the level like changed at all. It's just it's kind of like it can it's pretty much it can be the same level, but you can just you just have different responsibilities. Um but yeah. Uh, so I'm not sure how how it all works. >> Yeah. Yeah. It's it's it's kind of interesting. I'm not there. I think my my boss actually just got promoted to like a partner level, which is pretty cool. Um, I don't know numerically what that is. I just know it's definitely above mine. Uh, he's awesome. So, it's been it's been cool to switch teams and have like um yeah, a bit of a bit of a change. So, definitely. >> What was the reason for switching? Um it was a totally interesting like coincidental opportunity. So um I was not looking. So I'll say that because I I was telling my team like I wasn't I wasn't looking cuz I felt like I betrayed them almost but I don't part of me is like there's some things that we do in our careers that sometimes they might look selfish and sometimes they might they might be selfish but that doesn't mean that it's a a bad thing. It sounds kind of funny. I think I've had a a difficult time with this throughout my life. I think it's one of those things though like ultimately like you have to do the right thing for you and I I felt quite a lot of guilt when I left my old company as well like when um because when you I was like leading a team at that point and I was just leaving them like and I felt really bad until like you know I saw who was like you know coming on and I was like okay great they're in great hands but you do you feel you feel like responsible don't you feel like responsible for like you you've helped like you know get them to this point. You've done all this work with them and then you're just going but like you know the important thing to remember is that they are going to be okay. They're going to be like you know they're going to get a great like replacement as well like who's who's going to be just as great and and you get to do what it is that you want to do. >> Yeah, absolutely. So that's the exact feeling was like oh I feel guilty. Um, they did get a a great replacement uh em. So, I'm super happy about that. I was actually talking with him before because he was on the team already. Not my team uh directly like my report, but uh within the bigger team and I think he was interested in management. It was like the perfect opportunity for him. So, that was great. Um I was thinking about the people that I was kind of leaving on that team and I was like I feel like in their career development they're all on the right track. like I'm not walking away from something being like, "Oh man, I wish I could have like I wish I did bore." I was like, "This is this is actually good." So, I wasn't looking. Um I did have a couple of things coming up that started to feel a little bit more frustrating. This is no one's fault either, but for context, so you you worked at smaller companies than Microsoft before. Um I worked at a startup that was like eight people that grew to 300 for eight years before Microsoft. So kind of got to see the tiny company to small business and the I think the thing that I started to feel was that within our organization I started to feel like I didn't have a lot of uh I don't know if influence is the right word. I felt like I couldn't do my job effectively because I didn't have a lot of uh sort of direction to provide. It was kind of like I'm just getting the requests and like kind of funneling them through. I don't know if that really makes sense, but autonomy kind of in decision-m that started to feel like it was going away. And again, that's not because of anyone's fault. Um, and I started to realize this and I the reason I said this was so coincidental is that I'm not the kind of person that will go take immediate action for change if it's uncomfortable. Like self admitted, won't do it. But I remember telling my wife one morning, I said, "I'm starting to feel like this is like it's kind of interfering with my ability to like not be happy, but like to feel productive and be engaged." And I had a meeting that was scheduled for that afternoon, and it was literally my current new boss that was like, "Hey, do you want to like interview to be on our team?" It was the most coincidental thing ever. And I remember I thought the meeting was for something else and I was just like I think this would be stupid for me to say no. It's just too much of a coincidence. So that's the reason for the team change. It was definitely coincidence. >> Yeah, I can I can complete like I can completely see what you mean by like when you go from like a company that was like you know start growing to Microsoft. It's not so much that like um you don't get to do a lot of things. You get to make a lot of impact. It's all very tightly like controlled into one specific area, isn't it? It's like you only have influence on a very like small part. Whereas in like a start there's like so many possibilities of where you can go. you can go here, you can go there, you can do whatever it is you want where it's like it's you got like parameters you you're kind of stuck into, you know, if that >> and like that part is extremely important to mention, right? It's like the impact is there. You're going to be working on stuff like uh just as an example for people listening, it's like I have people on my team that they might go roll out a change that could affect traffic for literally trillions of requests per day. Like the impact is there. like you're doing things that have a big surface area impact and that can drive a lot of value. But uh Jade, as you're saying, it's like we have all these teams that need to work together and be cohesive, accomplish all of their goals based on semester planning. So like you end up being like very coupled to these other teams and making progress like you end up being tightly knit. So yeah, it sometimes it feels like there's not a lot of uh not as as much flexibility and that to me was was getting more and more reduced. So that was kind of a crappy feeling. But what what about you like what is you got into Microsoft what did that look like? And I guess like I've been talking a bit about the manager perspective as a a senior software engineer like what does your day look like and and how does that all fit? So I um I initially came in as a software engineer too. Um and uh it was it was in 2022. Um so it's a couple years back now. Um and uh like the way that our teams work is we do um like projects which are typically like around 3 to 6 months for different customers. So in in the UK you typically don't do it there isn't much product development as much. We don't work on specific product products but we work with like um our customers who are wanting to use our products with their products. So it's very much a we're very generalist in our role. um we have to work with our customers languages to help them like they it's so it's >> so there's two like industry like industries under industry solutions there's industry solutions delivery and there's industry solutions engineering and industry solutions delivery is typically things that have already been scoped it's quite clear what it is they need to deliver for the customer it's been done before whereas what we do is we're typically doing stuff that hasn't been done before >> and we're doing it like in like we're typically doing it in Azure like um so at the moment there's a lot of focus on Azure AI um there's a lot of focus on open AI there's a lot of focus on Azure ML so we're doing a lot of things regarding um exploring options for our customers to use those products um and we're basically doing a lot of um proving whether or not they can do something or whether or not they can't do something and so Um, a lot of our team is basically working with our customers to do that and we work together with their engineers so that when we leave they have the skills necessary in Azure to be able to do it themselves. >> And these are external customers, right? Like strictly external. Okay, cool. >> Yeah. >> And that's a probably a good maybe just thing to mention. So Jade, you work like specifically with external customers. The two teams that I've been on at Microsoft do not at all. like what we do will impact external customers but our like when I talk about customers from my team's perspectives they're other partner teams so we end up being a platform so deployment that I was on before our customers are the other teams that have services and now that I'm doing uh it's called the cafe team which is pretty cool name uh but so we focus on routing and things like that our partners are the other teams that have to have traffic routed but if we weren't routing properly that will affect the end user, but just like the customer framing is kind of interesting. So, it's cool that you get to work with like truly external customers. That's awesome. >> Yeah, it's good. And we have like um we have quite close contact with them. We have daily contact with them. So, we get to get a lot of feedback and validation of what it is they want um for for for what it is that we're delivering, which is really really good. Um, and the the thing the good thing about the way that our team works as well is that we um we we get projects and then we typically get a little bit of downtime between the next project. So, we can either, you know, use that time to upskill in what what we're likely going to be working on next or we get um, you know, we get to learn like something new within um within the combine. So at the moment I'm I'm still really trying to focus on learning a little bit more about um data engineering and um like Azure working with Azure ML for example because we typically try and we are Microsoft we so we we try and do use Microsoft products for the stuff that we do because that's um that's you know typically uh what um we like recommend. But like obviously um if the customer has a requirement to use um so recently we had to use um data bricks within Azure rather than using uh fabric um and that's what we we we had to do. >> That's the requirement right so you kind of have to go with that. >> So I think this is interesting because I was thinking about you know you are very focused and on on agile right like this is a really big focus for you. I love working like I was saying like continuous improvement which is agile but I find for me at least with um probably more like as a platform team it feels very challenging to embrace a lot of these things but once you mentioned you because you said I don't know if it's exactly a daily basis but at least pretty regularly you get to interact with customers like truly end users um how does that fit into like you your team's ability to like be agile and maybe adopt some of these processes like canban scrum or any other flavor like what does that look like? >> Uh so the so it really depends on the the customer and the level of interaction that they have and like the the skills within the team like the customer's team. So it's really good when um when like in our previous project we've had quite um we've had quite like daily interactions with them like you know we have daily meetings with them tots through what we've done we we give quick feedback if we've got issues we can say okay we've got an issue with this um you know could you give us some in in insights on that so stuff like that is really really useful. it can be quite difficult like sometimes to get the exact like um feedback that we need in terms of like the things that we're working towards and that's just because like we might not necessarily have the right stakeholders in in those meetings. So we work a lot with the developers and they have an idea of what it is they want but they're not like the final like um decision maker for what the actual business requirement is sometimes. So um with a previous project I'll I'll quickly talk about that we were doing more like a scrum based um like delivery uh so that worked well in that we had daily interactions with the developers but then we would have like um we would still have our like review where where the stakeholders would come and and still be able to contribute to actually what it is that we were delivering. They would still come to the planning so they would say what it is that they wanted. Um and some of the refinements as well because we would we split it out into technical requirements and backlog um like you know product style requirements because we we kind of realized actually um >> some of the stakeholders didn't need to be in in in these meetings. Um >> which is good. That's a good optimization, right? where you're able to look at who's attending like where the value of the conversation is because again for other people if you're watching this right and you're like well I don't agile just doesn't work like these meetings are so ineffective it's like no one said you had to do it like this exact way if you can split it up so you don't have half the the group half the stakeholders being like why am I here wasting my time I'm not getting any value change it like you can change it to make it more effective That's cool. >> Yeah. And so what we kind of did was we had our features and um we we basically said, okay, these are the things that we need to deliver before like the end of our our like working together. And um we would just literally focus on like the features that we were going to be we would break down the features that we were going to be doing in the next couple sprints. Um we would wireframe them out. We would um then like talk about like we would have our own refinements where we would technically like agree okay these are the technicalities that we need to do and this is like the um like the system flow that we need to design um and then we would um like validate like the actual like flow with the with the customer. And so it wasn't like a okay we needed to do this here and then we got what we needed when we needed it. right >> to to to to get the work done. Um and actually it was funny because by doing it that way we actually delivered more than what we initially set out to do. Um because we we didn't confine ourselves, >> right? That's cool. Um I have a a like because I don't know the exact structure of the team, right? So you're a senior software engineer. when you're talking about the interactions with the customers and that kind of thing. Who else is present like uh so from their side you were mentioning like you'll have their developers and for some of the other meetings that you have there other stakeholders will be present from the Microsoft side so people directly on your team like are there junior developers that also get to be present in those conversations what does that look like? So we don't in our team we don't necessarily have um any juniors at the moment. Um so um like the lowest level we we've got is um software def um SD2. >> Uh and and that I think the reason more is just why because um they want like because of the customers that we have like because we're dealing with customers on a daily basis. We're having like customerf facing interactions. they want to have like you know a minimum like level of of like um architecture skills in the jar and things like that. um just because we we are coming in as um experts in in Azure. >> Um so I think that's the main reason why but I can't say for sure I think um but I think so >> which I mean I think that makes sense right it's like I I don't we we haven't talked about this together ahead of time or anything but uh maybe it's worth kind of bouncing some ideas back and forth. I when I think about like a a team that's like kind of uh healthy in terms of being able to grow and have longevity like a balance across levels is helpful, right? If you've never put teams together, you might go, why wouldn't you just pick the best highest level people and stuff them all into a team? Like wouldn't you get the best possible results? And it's like like maybe but also not from like a longevity career growth perspective opportunities like you need to have balance and having different levels can be helpful and that means bringing on junior people can be helpful but it's not always that simple because Jade as you were saying if you guys have the expectation that you need to be able to like you're the experts you need to be able to get the customer requests start delivering and and and being ready for that I could imagine that if you had junior people like it would be challenging to say like you know you got to start and be super effective because we have these deadlines we're working with the customer. Is that kind of kind of your perspective or do you have different thoughts maybe about like a structure of a team? >> Um I I definitely think like it's good to have a balance. I think you know where possible you know it's great it's a great way to bring um you know people um like it's a great way of like building the next like you know generation of software engineers and I think that's really important thing to do. Um I think um I think like the it's just a unfortunate case like um with with certain teams that they they just need like certain like architecture skills like it wasn't a requirement that you had to have like you know like loads and tons of Azure knowledge um like in in my team like when you when you started because you can get you can get trained up on it. I think it was just a case of they were just looking for a certain baseline level um so that they knew that like someone could easily pick it up like within like you know a few months. Um >> it's like there's there's less risk with it I guess like that's part of it. So you don't have hey we have a new person like we would always hope that new people can ramp up fast. We'll do whatever we can to help with that. But I guess it is a bit of a risk versus like we have someone that's already at this level like >> but it's not I guess it's not just like it's not just like the technical skill side. It's the like soft skill side, the communication skill side that that that >> that all like contribute to you grow going up in the levels. Yeah. >> Um so I think there's a combination of that as well and because you are like dealing with customers on a like quite often um those skills are more important um from like our side. >> That's cool. Um and you mentioned like the soft skill part. This is like there's like two themes aside from just talking about C that I that I always love to talk about and one of them in particular is like soft skills and software engineering and it's been kind of tricky in more recent times to find examples aside from just like within your team like how do you have like you know how do you demonstrate your soft skills? Why are they important for collaboration? But you have a very good a very good situation to be able to talk about the value of soft skills aside from stuff that I regularly talk about and that's like you said interacting with customers like can you share a little bit more maybe about the different types of soft skills or why that's so valuable when you're having these interactions. So I think I think the biggest import like the important thing about it is you really have to build a trusting relationship with customers. You have to make them feel like they are safe in your hands. You are going to deliver what it is that they want. Um, and when you're having daily interactions with them, like the the best way to do that is to like, you know, build those relationships, be able to explain effectively what it is that you have created for them, showing them what it is that you've created, explaining the value of why it is that you've created, understanding what it is that they have actually asked you to deliver. There's another like thing in our in our kind of department. there's a lot of like fluidity and a lot of like lack of structure and um and that can be quite difficult when you're coming in as as a new um uh as a new engineer. I always think like for a new engineer coming into the industry is like mo for most engineers that come into the industry having a baseline level of structure is really really beneficial for them. Whereas >> like sometimes like the way that we work can be a little bit chaotic because sometimes our projects are like six weeks long. You don't have time to make like a really good structure for that. >> Um and so it's it's kind of like >> there's there's a lot of chaoticness sometimes. And so there's finding a balance there when you're when you have like more like um like new new people coming into the industry because they probably need a little bit more like um structure in that sense most of the time. Not all the time. I've definitely seen like you know junior um juniors and um entry level engineers who can just come in and just get get >> autonomy. It just happens. Yeah. It's Yeah. >> It's just not not as common. >> Sure. I agree. Yeah. Um it's Yeah, it's really hard to make statements. You're like, I'm being recorded and if I say this, someone's going to be like, no, there's an exception to this. It's >> Yeah. And and and that's I try and be really like conscious that like what I'm saying isn't everyone's like experience. I'm just saying for the average like for the average person, this is more likely to be a common thing. Like for someone who is just coming in like there is a reason why you know people who are contractors who are meant to be like you know self-sufficient are typically have been in the industry for like a few years kind of thing >> right because yeah they've gone through the motions of it they have the experience they kind of know what to expect right and it's a the same type of thing when I'm telling more junior software engineers like as they're going through and they're getting interviews or getting into jobs and you mentor people so you know all about this right the I'd be curious to hear your perspective on it. I find that everyone is hyperfocused on technical skills and we're in software engineering like it's technical like there's no there's no doubt about that and I find what's not maybe not focused on a lot or people forget it or I don't know but it's like all the other skills that aren't technical like sounds kind of ridiculous to say out loud but like how to be a good human and interact with other humans like there are some like call them social skills, people skills, whatever. Soft skills I think is the, you know, the really common way to put it. I find that there's not a lot of focus on that. And I I don't know what the answer is. But I've been trying my best just to like keep saying it to people that you can't forget about this stuff because once you start working, if you've never put any thought into how I communicate, how I collaborate, you might find like, oh crap, this is a lot different than I thought because I'm not just sitting at my desk looking at a coding word problem and just starting to write code. like what are your thoughts on like the people that you've had to coach and mentor or other people you've seen kind of coming into industry around soft skills? >> So it's really interesting that you like point point about the soft skills because like I've recently had a menty who has like just received an offer from um American Express and um one of the things that really stuck out to me was his ability to network. >> Cool. he like you know he definitely you know had the um like technical ability and he'd been working on that but like his ability to network and you know you know um be someone who the the rest of the team wanted to work with I think definitely like helped in his favor um it's one of those things where I think unless you are like someone who is has technical ability that no one else can do which generally quite rare. Like it's quite rare to get to that point. You're talking like PhD people. You're talking people who can create these really really like complex convoluted algorithms that no one else can solve. Unless you're that level, >> then you can't really get away with being like rude, I think. Right. And even for those people, it's like, yeah, you might be able to land a job, but like your your your box of like where you're going to be working is significantly smaller and specifically where Yeah. more more focused, right? Like it's hyperfocused because of that. So that's >> Yeah. And it's kind of it's that kind of need of okay, well, do we unless you're like this like brilliant genius, you know, and there's definitely people there who who are out there who fit that mold and and they're definitely needed for like, you know, the most optimized um like, you know, software engineering. The majority of people just don't fit into that camp. like the most the majority of software engineering is using stuff that's already there and like you know repurposing it and then like creating new stuff from it. Um I think if you you you're just going to struggle like because >> there's there's so many people in the market that have those soft skills whereas um if if you don't like work on those together. I definitely think like most people can like if if you can like identify a baseline level of like technical skill, most people like um it's much harder to teach the soft skill side. >> Yeah, that's a that's a really good point. The um the point about teaching soft skills is not that's not an obvious one, right? I think maybe I'll back up a little bit. People have said like, oh, like if I want to get a job like what language do I need to learn? What's the tech stack? And my philosophy has been like of course if you happen to pick a tech stack in a language that some companies using like sure that's helpful but in general and this is kind of throughout your the lifetime of your career the one language or tech stack like that's not as important as saying like I have these experiences because you'll be able to pick different languages and tech stacks and reapply them and the companies that can afford to do so like bigger companies especially sometimes it's not the case for startups they know that They can teach you the technical things, right? You know Java but we use C. Cool. Like come on board. You know Python but not C. Like you can program but you haven't used C. Cool. Come on board. But the soft skill side and maybe that's a good takeaway, right? Like I think for me that's a I don't know if I really thought about it that way. Teaching the soft skills is not easy. >> Have you? And there's and there's a there's a like if you don't like if you aren't able to teach someone the soft skills part and um there is an like potential negative consequence of that in that like yes they are you know they might be they might be like a great like technical developer but if they can't communicate with the customer if they can't like figure out what it is the customer wants and actually say what they're doing in a way that the customer understands it. That's a really really big problem like in terms of like delivering stuff because how how do you know like how how do you build that trust? How do you build that confidence with a customer? As well as that like if you can't you know communicate with your team if you can't actually um work with your team like you're impacted on like how how you can how you can teach them. How how is it that you're going to make the the rest of the team that you're you're you're working with a better developers? Like a big part of being a senior is being able to do that. How how do you progress as a developer if you are kind of stuck not being able to like >> pass on your knowledge to other people? >> Yeah. I I can imagine >> I I like to think that I have some type of like soft skills. So I can imagine if you like if that was a struggle for someone, right? It would probably feel very frustrating to be a software engineer because you would feel like I'm writing code, it's going up for review or I'm reviewing people's code having these design interactions and like why is it always so frustrating? Why is it so difficult to communicate what I'm why am I I think my design is valuable. Why I think this code choice is good or you're reviewing and doing the opposite. Like why can't I seem to articulate like why I wouldn't use this design? like some of the flaws, um, some things to look out for, it would probably just feel frustrating all of the time because your ability to communicate, and that goes multiple ways, right? Delivering your message as well as interpreting and understanding other people, it sounds really basic, right? But like it's it's a fundamental thing. And that's why I'm saying I feel like it could just be very frustrating as a software engineer to not focus on those. And it it's really it's really like hard to kind of like be like okay like you know um just because someone's not not learned this yet that they they they can't learn it. However, like generally like if someone's at least willing to learn like learn it or be aware of it rather than just completely say I don't need to learn this. This is not important to me. Um that that's a good sign like you don't have to be perfect at it. You don't have to you know you know I'm not I'm definitely not perfect at it. You know I've spent like the majority of my life really really struggling with like you know um eye contact and you know thing things that other people find really really easy. I'm really you know I have really bad social anxiety but I'm I try and I know that it's important kind of thing. Um, >> I think that's a probably another really good takeaway is like the fact that, you know, if you were watching this and you're like if that started to resonate about the soft skills, if you're like, man, like I haven't been doing that and you're thinking they just said it's really difficult to like to learn that and to teach someone that, it's like it's not it's not impossible, but like I would say the reason that it's probably difficult is that like any skill because truly these are skills, your communication and your soft skills, You need to practice them. You're not like you could read a book, watch videos, and say, "These are helpful things that I should keep in mind." But you don't read a book and go, "I can communicate with anyone now." Like, you need to practice that. Have these different interactions. Those take time. Those take different experiences. They take sometimes having bad interactions where you go, "Crap." Like, "Why was that so difficult?" And reflecting on it and being like, "Maybe it wasn't just the other person. like I should take some responsibility and see like maybe I wasn't listening, maybe I wasn't um I wasn't understanding what they were after and then you know changing my message to them. So I think that's probably why it's more challenging. >> Yeah. And I think another reason why it's more challenging is just the if someone doesn't believe it's valuable then they're not going to want to learn it. And I think once you change that opinion, I think is is if you say you don't like something or if you say you hate something, you're always going to hate it, I think. Right. >> Um and if you say you like something or if you say, "Okay, I don't particularly like this thing, but I know it's important." That's a different mindset at that point. You're not going to go into it being like, "I'm going to be really bad at this." You're going to be into it. I'm going to try and be the best that I can be >> to do to do this thing. Like, you know, I think, you know, about a year ago, I said to myself that I I hate Python. Um, and like I use it for like any sort of DSA style problem that I solve now, and I use it like in work as well. So, it's kind of like it's it's a different shift of okay, well, it it work it's it's good for certain scenarios. And I've stopped saying like, you know, that I I hate it. I I I just mildly dislike it in a lot of scenarios. >> Decoupling like the decoupling I don't like it versus it is bad kind of thing like yeah because if you can say I don't like it but I understand it's valuable like very different and then like you said you were able to kind of shift your perspective. I think maybe one final question for you because I'm super curious especially through like mentorship and stuff with soft skills. Do you find that like you you mentioned if people don't value it that's another thing where they're they might not drive change. Do you find that people that you are mentoring and trying to get into industry and things like that does that seem to be top of mind for them do they want that? >> Um it's a mixture. >> Okay. It's it's it's so you've got people who genuinely um like you know see the value of it you know have a really big strength in it um and you know use it as their strength and then you have the people who um come in and they aren't necessarily as um they they don't really like um they don't really see it as important. Um, and interestingly enough, the ones who do see it as important are the ones who maybe not aren't necessarily as good as it good at it, but like see its value are the ones who seem to have secured like offers. So >> interesting. That's uh that is interesting. Yeah, it's uh it is important, right? And I think if people are open-minded and understand like it is important, you might need more practice at it, that's okay. But you have to acknowledge it's important first. >> I kind of the for me there's like there's a few key areas for people who are getting into the industry. Um there's um there's uh building like projects repeatably um in a in a like you know consistent way to be able to say okay I understand how to work with this language. I understand like how how this language works. They only have to do it in one language. um they don't have to like learn loads of different languages. Get good at one language first. The second one is data structure and algorithms. And whilst this isn't necessarily like needed for everything and you definitely don't need to learn the the hard parts of data structure and algorithms, but like understanding what different data structures are is valuable, I think. And understanding how to manipulate them and change them is valuable. And so I always recommend like you know just being able to do at least easy sort of le style code questions is a good thing to do for even just to understand what you're doing with data because like there's been many mentees that I've worked with that don't really understand like the actual object that they're creating when they're creating stuff in like you know JavaScript for example and having an understanding of that is really really beneficial and then the third thing is soft skills um so that is another part where I say okay well we need to soft skills and networking um which is is that side um and and they're like the three main areas I think that are like super important. >> Cool. No, that's good that you're able to to focus on that with people, right? Because I'm making assumptions. You've you have like a you know call like a I don't want to say a pipeline of men mentees, right? you you've been doing this um and so you get to see kind of like some themes and stuff. So I'm kind of making assumptions because a lot of the people that I'm talking to it's kind of more scattered versus you're getting a lot more uh you know one-on-one conversations with people. So it's it is interesting to hear how much they're investing into the the technical versus soft skills. >> And what's really nice is they're all very different. Like everyone's journey is very very different >> but like you know they're very different people. You've got extroverts, you've got introverts, and like they're they're all like putting in the work to do the things necessary to to get those roles, which is very nice to see. >> That's super cool. Well, Jade, okay, so what's I'll get I'll make sure that I get links and stuff from you after, but if people want to get in touch with you, what is the best way if you want to, you know, say it for folks and then I'll, like I said, I'll get links from you after I can put them in the description and all that. >> So, probably the best way is um LinkedIn. So that's what the place for most active the easiest place to message me. Um and then I also have a like blog newswsletter and I also have a YouTube channel that I um like I've started posting to weekly as well. So I'll definitely give the links to Nick for those as well. >> Perfect. Okay. Well, thank you so much. I think people that watch this are going to have a lot of value to take away. I know that one of the things that I've been asked about before is like, you know, what is it like at Microsoft? And I think it's really cool like so you as a senior software engineer are going to have a different experience than me and you work in a complete not only a different part of the world but like a completely different interactions with like customers versus what I'm doing. So I think that was probably helpful for people because I can't offer that type of perspective. So thank you so much and uh I look forward to to more chats in the future. >> Thank you. Thank you for having me. Of >> course.