How To Build Teams That Actually Care - Interview With Ryan Varley

I like to use the term morale. I think a lot of people use happiness. If you want to make a team that's happy, you can pay them a lot of money, give them free food and pizza, put an Xbox in the kitchen, you know, like happiness is not the same. I think morale kind of implies a happiness and an engagement and an excitement with what they're doing. That's why I like to use morale. A high morale team cares about what they're doing. They want to succeed. they don't necessarily need to care about the mission so much. You know, like I get a lot of that where people are like, I shouldn't have to care about, you know, B2B sales in a in a job. Um, but you care about the the problems you're working on. One of my favorite sayings when it comes to complicated things is, well, it's not rocket science. But that might not be the case for Ryan Varley, who joins me today on this podcast. And Ryan Varley has a PhD in astrophysics. But what we got talking about was building high morale teams and focusing on continuous improvement. And for a lot of that, that involves balancing people's effectiveness and their interests as well. So for me, this was a really awesome conversation. I had a lot to take away from it. And I think that you'll enjoy it as well. So sit back, enjoy, and I'll see you next time. People seem to get nervous when there's a little bit of a countdown and then they don't know how to talk even though we've been talking already. Myself included because I used to do this with a buddy on a different podcast and we would uh not even have guests and we would kind of screw ourselves over with that and be like uh how do we talk now? Um but that makes it fun. So Ryan, thank you for joining me and I do appreciate you being here and I wanted to kick things off with maybe a little bit of, you know, career journey and like I was mentioning before I pressed the record button as early as you'd like to go, as much detail as you'd like to give. I think that would be awesome for the audience. >> Cool. Yeah, thanks so much for having me. Um, yeah, I'll I'll go uh high level and then I'll let you I'll let you focus in if you want. Um, so I'll start with university, which is always a fun place to start. Um I did a degree in uh astrophysics and molecular cell biology. It was a natural sciences is what they called it. Um and that was a 4-year degree in the UK which the last year is a master's year and that's when I focused on astrophysics which led me to a PhD in astrophysics and that PhD uh was about detecting uh molecules in the atmospheres of planets around other stars. Um so we were looking for things like uh water in in the atmosphere of these planets. Water was like a very ambitious goal a lot of the time. Um you know we were looking really realistically we were looking at planets like the size of Jupiter um rather than something that was more like Earth. Um but that problem it turns out is actually very data sciency and data engineery. Um, I realized later uh in my career when I met with other PhDs that I kind of chose the wrong field because people had been to uh on submarines and boats and they'd traveled the world and gone to Antarctica and all these other things. But I chose to focus on a problem where the telescope was the Hubble Space Telescope, which means you don't get to visit it. Um, you just get to stay in a university uh in a university office analyzing the data. Um so yeah I was doing this sort of problem which is machine learning data engineering and I found that I really liked that aspect the coding and the machine learning and less so the sort of academic theoretical stuff >> and I also really liked working with other people like I had a very collaborative final year of my PhD. >> Um so I thought rather than stay in academia I would go into industry. Um so I did a month-long sort of transition boot camp called science to data science um which t took PhD students and sort of paired them with industry companies to um work on real problems. Um and then I joined a small startup. It was about 25 people um as a data scientist. Um and it was very generalist. This was like 10 years ago and I I think data science was quite a different field. We were, you know, we were generally saying things were machine learning, not AI. Um, every there was almost none of this support infrastructure to help you. You had to be very generalist. Build your own uh data pipelines and feature engineering stuff and do your own machine learning and build uh test sets. >> Um, so I had a really good time at that first company. um just learning as much as I could about one how to work in a business and operate in a business and what they care about but just about all sort of aspects of software engineering and data science. Um that company was very machine learning focused. So it was a real crash course for me and really valuable and I stayed there probably like three and a half years before I thought it was time to move on and I was looking for more of a team lead role. >> Okay. Um so I joined a second company that was in the adte tech space and I joined as a data team lead and it was more data engineering than it was data science. Um so it was using a lot. >> Can you explain for the audience maybe like what at least from your perspective data engineering versus the science part because I think maybe if myself included when I see these terms come up it's like I don't know if like people are referring to the same thing or like misnomer or that kind of thing that might be helpful to to share. Yeah, it's super it's super blurred and as I said like I was doing a lot of data engineering as a data scientist. So I think data science is generally trying to build uh features with that use data or trying to do analysis trying to do predictions. Um it's not always machine learning. Sometimes the end resulting model will be huristics. Um, and within that it varies a lot between people that are shipping end-to-end solutions, just doing analysis, just doing experimentation. Um, but you tend to get you tend to get a lot of PhDs in that role and a lot of people that really care about data. Um, data engineering, I think, is more of a cross between that and engineering. um you're generally building pipelines, you're building APIs, you might be building a lot of the infrastructure and the supporting code around a data science solution. Um but yeah, it it tends to be on the other side and my version of data engineering uh was mostly large scale pipelines. So doing a lot of Spark, moving a lot of data around, solving problems there. Um and that's mostly what the the second row does. Okay, that that makes sense. Thank you. Sorry for for interrupting you. I just thought that would be a good opportunity to like have that explanation tossed in. >> Yeah. Yeah. No, that's fine. And uh that in that company, I went from a team lead to head of data science. So I started doing more of that strategy level stuff. Um and I turned the team there into a sort of end to-end feature team. So we were delivering stuff end to end without uh the need for much interaction with the other teams or much coordination with the other teams I should say. And yeah, actually starting to look at like the strategy of what we were building, you know, working a lot with product and clients and and the exec team and stuff like that. And yeah, I stayed there for about again another three and a half years before moving to head of data science at a an education startup. Um, so this was trying to enable the use of video in education. So there was some um that was probably like a mix of data engineering and data science. it was another sort of blend. Um, and after about nine months in that role, I moved to the sort of senior vice president of technology role. So, it's kind of like the CTO role managing product, data and engineering teams. Um, so that was fun. The start of the company was about 100 people. Um, you know, I got to experience board meetings and sort of high level strategy and fundraising and that sort of stuff. Um, and again, it's it's a common pattern. After about three and a half years, I I moved again and this that's where I am now. So I'm currently a fellow of engineering at Magnite, which is another adtech but much bigger. It's about a thousand people and I'm on the IC track. So I've gone from quite high up in the management track to now quite high up in the IC track. Um so a fellow at Magnite is it's above principal and staff. Um there's a lot of titles on the IC track at Magnite and I get to so I'm an individual contributor but I have a lot of impact still. I still get to mentor people. I have a lot of autonomy. I get to solve some of the harder problems in the business and that's sort of really fun and exciting for me and very different from I guess the past three and a half years. >> Just a quick reminder that if you're enjoying this conversation to give the video a like and remember to subscribe for more content. That's awesome. That's a a lot of different experiences. I think one of the things that you had said sort of at the beginning of that that I was curious about and >> and I'm making an assumption here so I want to kind of kind of see your if this is accurate, but uh when you said what you went to school for, I was like that seems like a very specific thing that I'm assuming was probably driven by like a lot of childhood interests and uh as you said that you know moving into like these other roles that came after. I was curious like do you miss the the idea around space and like being able to look towards space and focusing on space or did you really truly fall in love with like the data part and the fact that you were looking at things like space that was sort of like not actually relevant in the end. It was just almost like a vehicle that got you introduced to all the data work. >> Yeah. I never so I think space was always a secondary interest. Um so the the program was natural sciences and essentially how it works is you choose two subjects and you initially choose something like physics and chemistry or physics and math or physics and biology etc. >> So I chose physics and biology because those were the two sciences that I was most interested in. Um and then I specialized in physics because I was more interested in that than the biology. Um biology kind of turns into chemistry at university. Um, and chemistry was probably my least favorite. So I I sort of I sort of didn't didn't massively enjoy that side of things. Um, so I kind of naturally found astrophysics and then there was only certain combinations you could do and actually the only physics and biology combination you could do was molecular and cell biology and astrophysics which is why I ended up doing that very specific combination. Um, but no, I think I think actually programming was probably what I cared about more. I just lost it for a little bit. Um, I grew up, uh, I selftaught PHP and like when I was a young teenager, I built websites and WordPress plugins and little little apps with PHP. Um, and I think I enjoyed that more, but I don't know why it was, but I never even thought about doing a computer science degree. Interesting. >> It just never even crossed my mind. I think I was I don't think my college or um high school I think is the American version um >> really pushed that at all. So I I was still in the sort of purest subjects you know like the pure science subjects and I think it took university and particularly my final year for me to rediscover oh actually this is the thing that I enjoy because my final year project involved a lot of programming where I learned Python for the first time. >> Interesting. Okay. Well, yeah, thanks for thanks for walking through that. I think that's super cool. Um, and one of the other things that you had mentioned that I think is probably like it sounds like a transformative thing was in your last year being able to collaborate a lot more and having this this realization like hey working with other people is great. Like did you find that um going into like the the professional working world that that that was a common thing that you were able to kind of surround yourself with other people to collaborate with? Did you find uh maybe at different companies at different points in time where like the collaboration was like limited and that wasn't as exciting or like what did that kind of look like throughout that? >> Yeah, the the it can be very isolating in a PhD because you're often working for yourself. If you just turn up and decide not to do anything for two weeks, you've just lost two weeks of progression on your PhD. You haven't really impacted anyone else. So there's no one. So you have to find a lot of selfm motivation and I did struggle with that towards the end but I sort of found things that I was passionate about that sort of led the direction of my my PhD and then towards the end one of the final projects I did was yeah where I was really working with someone else and we sort of took two sides of a coin where um it was almost like antagonistic where I was trying to build something and he was trying to break it almost. >> Okay. And that and that was a good reason for that because we were trying to build like the best solution. Um and it kind it kind of made sense to hit it from both sides. But I really enjoyed that and I think that's what led me to the the initial career path because the first three companies I joined like 10 years of my career were startups. >> They were you know the first was like 25 and then I think it was 50 and then it was up to 100. Um but these are like very collaborative environments. there's not there's a small number of people. There's no um that's not my problem. It's you're kind of all in it together. You know everyone. Um you thrive, you have autonomy obviously because you kind of have to. But you thrive in that environment if you are very collaborative and are very autonomous and engaged. And I really enjoyed that. Um I think the only reason that sort of put me off startups in the end was and I think I will be back was the the sort of last five years we've had in terms of COVID and layoffs and >> right I I went through five rounds of layoffs at two different companies and obviously in in the last one I was in the senior management position and that took its toll on me quite a lot. I I like I just couldn't handle I felt like I needed a break from worrying that the problems I was working on and the sort of battles I was having in exec team meetings could be lead to like the death of the company, >> right? >> Like I have problems now. Um but if I lose if I lose this argument or I'm wrong, the company's going to be fine, right? >> You know, like where that might that wasn't true necessarily at the startup. if we made the wrong decision and wasted six months that could be it or at least it could be it for a huge amount of people at the startup. So um yeah I I did find them collaborative but I think they also are a little bit taxing. >> Yeah absolutely and that's like I before Microsoft I spent eight years at a startup kind of growing from like seven or eight people to like 250ish. So seeing that growth trajectory being along for the ride and you're you're totally right like um the super collaborative and it reaches points where like I I was uh we were still introducing like director positions. So before I left I uh did not reach like a director position. I have director reports that uh that are still there or they were direct reports that are now in director level positions and stuff. Now they're in at the point in the company where like they have that kind of influence. And it's very interesting that like I don't think a lot of people realize unless they've worked for for smaller early stage companies that like what you were talking about you know making a decision and like in 6 months the impact that that could have like that could be you know for a part of the company that could be potentially devastating. It could be something that's very successful, but I don't think people realize that that kind of impact on a company can occur unless you've lived it because sometimes I think people are like, well, a company's been around like I'm just just doing my job like paycheck comes. It's not it's not always like that though. Yeah. I mean, companies startups rely on funding and revenue and both of those things can be impacted and they can both be impacted at the same time. In fact, that's what happened to uh the company I was at during COVID, which um investors kind of went, "Whoa, let's the market's gone weird now, and we don't know what's going to happen." So, we're still interested, but we're not going to put our money in now. We're going to wait and see what happens. >> And clients are doing the same thing. They were like, "Whoa, our money's dried up, too, and our people are canceling contracts, so we're gonna hold back as well." So, you can have a situation where you think you're fine. you're just about to sign a deal for funding. Um, your deal and pipeline is looking good and then it can all go and that pretty much happened. Everything went overnight and suddenly you've got a runway that's burning fast. Um, and if you're in a startup, that runway probably isn't very long after revenue dries up. Uh, a lot one of the things I learned was, you know, a lot of people in their runway figures kind of factor in expected revenue. >> Sure. Yeah. But that that can stop in a sort of severe situation like COVID was and yeah that that can have very severe consequences because you can't just magic that money back and you are on a sort of ticking timer. >> Yeah. and that like yeah I think it's just it's incredible that it it's absolutely a real thing and that uh depending on people's work experiences and stuff they may be very sheltered from from that right until unfortunately like they end up in layoff situations or whatever it's like they're sheltered sheltered sheltered they don't really see what's going on until something like that happens but yeah it's uh it's co times were obviously very very challenging for many companies but that's uh yeah no it's super awesome thanks for sharing the the journey and I think we were briefly talking before about uh building teams with high morale and you got to kind of go through um this evolution of your roles to being up you know in sort of like this higher much higher up position uh than obviously when you started out it sounds like you're back to an IC role still obviously having very huge impact what does it look like to you when you have a team with high morale versus not like what are the things that you observe about that team that kind of tell you like what that's looking like. >> Yeah, I I like to use the term morale. I think a lot of people use happiness, >> but >> okay, if you want to make a a team that's happy, you can pay them a lot of money, give them free food and pizza, put an Xbox in the kitchen, you know, like happiness is not the same. I think morale kind of implies a happiness and an engagement and an excitement with what they're doing. >> I like that. Okay. >> And that's why I like to use morale. So, I think a high morale team is cares about what they're doing. They want to succeed. Um, they don't necessarily need to care about the mission so much. You know, like I get a lot of that where people are like, I shouldn't have to care about, you know, B2B sales in a in a job. Um, but you care about the the problems you're working on, whether that's um, you know, like I'm working on right now um some really tough challenges with uh huge data pipelines. So trying to join like uh data sets which are tens of terabytes onto other data sets which are like you know 10 terabytes and this is like a huge hard problem to to solve if you don't have unlimited compute and money and that's exciting to me. >> So I don't think you necessarily have to care about the mission so much as you have to care about what you're doing. But I think when people are high morale they work really well together. They see problems. They want to solve the problems that they see. They don't just ignore them. um they act, they challenge each other um like in a positive way. Like you obviously want some some uh challenge and I think it's just a really fun it's a really fun place to work and be, but you also progress really fast and and get a lot done and have a lot of success. Um so yeah, that's roughly roughly how I'd uh define it. >> No, that makes sense. And I think I I like that you called out when you started talking about happiness, right? I think I think that's an interesting spot to start. But of course, like people could argue this depending on how they want to define things, but I like that how you started describing that and then saying, but like sure you can introduce these things like whether it's more money or you these these perks like sure those are things that on the surface make people happy, right? It's a nice thing to have, but the the other word you used was engaged. And I think that that like I think when I talk about high morale uh like one of the things that I generally focus on is like an engagement level. But I I also really like that when we talk about things like missions, right? And you can kind of zoom in or out depending on on the scope of what you're talking about. You could say like so like at Microsoft, right, we have a mission statement that's like like planetary like impact and that's the company's mission statement. And I think for certain individuals, depending on what they're doing, it could be really hard to get behind a mission statement that's so broad where you're like, "The work I'm doing right here doesn't really feel like that whole mission." Maybe, yeah, I get it's a part of it. But if that was my only sense of like motivation and engagement, it would be probably disconnected. But if you're working in a space and like how you were describing like a particular challenge, the challenge that you're solving right now may not be like the company's mission, but it's something that you are very interested in solving. It's a good challenge. It aligns with your interests. Uh probably pushing you past a, you know, your current limits a little bit because otherwise you would probably solve it like that. Um, so like this good balance of like challenging but also aligned with your interests. And I I think personally like that's that feels like one of the really big factors even though like I think a lot of us would think about happiness. You want your you know your colleagues and stuff to be happy but I think engagement is like a really key factor there. >> Yeah. And it's what I hire for as well. I I love people that sort of have that attitude. And I can give a direct example like um one of the goals I had last quarter was to reduce the cost of the pipelines. Now, you know, I don't think many people are necessarily going to get excited about saving the company some money. Um but these were really hard technical problems without a solution. Like it wasn't just here's how you do it. I had to figure out how to do it. That meant like investigating, look at what's happening, look at what you can do, running experiments. And I find that really exciting and I like the challenge of it and to see how much faster you can get things to run and cheaper and better and improving the developer tools that other people can like follow the same sort of process. I get a lot of uh enjoyment from that. >> Yeah, that that's interesting. Um, yeah, even like it's funny you you mentioned like you have this problem that you need to go solve it. Like you acknowledge that yeah, like to save money that maybe isn't the most maybe not the most motivating thing for an individual. Like it's definitely motivating for like the company to be able to save money, but to get people rallied behind that where they're going to be engaged, it's like there's a there is a bit of a disconnect there. So being able to bridge that with like these are interesting challenges for certain individuals, I think is is a very helpful way to frame that. Um, >> yeah, >> there's a key way of doing that. Um, like I've I've talked about it a few times, but I think one of the things that I came to realize is a lot of people like to put roles in boxes. So, you know, you are a backend dev or you might be full stack, but most full stack devs I know >> are generally backend and do a dabble a little bit in front end or sometimes the other way. Um, you might be product, you might be something else. And one thing that I kind of learned was that that isn't really true. like everyone has a mix of interest and skill and it's something I plan on talking about in my newsletter soon. I talked about it a while ago. My newsletter is called brilliant people exceptional teams um because I tried to highlight the the brilliant people in teams and try to make people more brilliant and obviously form exceptional teams of them. Um, but there's this really interesting thing you can do where if you ask someone to put all of the sort of skills and things they care about on a 4x4 where on from top to bottom it's uh drains energy to creates energy and from left to right is low skill to high skill and you ask them to put things. So I might put you know spark on crates energy and um high skill but you might put other things like netnet. I don't really know any net but I also I'm not really interested in it. So it's sort of on that drain's energy scale and I can put things like product there and front end and all these other different things. And when you do that you realize that people are individuals with a a whole blend of all these different skills and what creates energy for me is different to what creates energy for you. >> Right? >> And when you do that for your whole team you can see okay so this thing that I don't like and I'm not skilled in this other person really likes whether they're skilled in it or not. And now you can start to sort of roll share a little bit. So I did that in my SVP role. Um uh I had a head of product and there were I did not enjoy some aspects of creating the board deck and or communicating the product mission and stuff. She really liked that. >> I didn't I didn't enjoy um other aspects of like how you would communicate some of the stuff to the rest of the business. Again, she did that. So it was we kind of and you look at that across the company and across your teams and you go okay this this person in my team really doesn't like the data pipelines and I don't need to force them to do it because not everyone in my team needs to be able to handle the data pipelines. I need at least two maybe even three but I don't need everyone. So I'm not going to force people to do what they really don't like doing. I want to keep people in their creates energy zone most of the time. And that's it's interesting too, right? Because the that last example you were giving, like I've talked about this recently where when you're forming teams and and evolving them, like there's there's going to be things that you need to have and the word is going to sound terrible off the top of my head. I don't have a better one, but you want to create some redundancy in the team for like skill sets and focus areas. And I don't mean redundancy because, oh, as soon as there's some redundancy, we can just get get rid of people. No, I mean like someone goes on vacation and now like and now something goes down or you you have like a live service you're supporting and it's like oh sorry the only person that knows this is on vacation like not a good spot to be in. So I to your point having at least a couple people it could be more than that depending on uh the importance of whatever that thing is is very beneficial. But in terms of getting the majority of time focused on like these high energy areas, you might have a situation where you're like, look, we actually do need to have more people focused on this on this thing because we only have one person right now and it's low energy for everyone, but like you want to minimize the amount of time that people have to spend doing that. Get them to a point and then make sure you can balance that back out with something that is high energy. depending on how their work is scoped, maybe you can pair them up with something that is also high energy. So, it's like, "Hey, we need you to kind of do this thing. I get it. Not the most exciting thing for you, but you also have this other project you can work on at the same time that's like very much aligned to, you know, to to your interest and high energy focus areas. So, it's this balancing act and like sometimes we have to do the crappy things, but they're really important. Um, but we don't want to keep people in those areas." >> Yeah. You pay cost every time you put people in their drains energy zones and people change. Your senior front end person in your team might be super super like brilliant and really highly skilled at front end and react. So they might have stopped enjoying it a while ago. >> Yes. >> They might be they they probably told you a few times in um some of the meetings how they want to get more into DevOps or want to do more backends and you probably was like, "Yeah, yeah, yeah, okay. Yeah, I'll try and get some more of that, but we really need you to do our front end because we've just really backloaded in the front end. But you're keeping you're pushing them in their drains, energies up and eventually they're going to leave or or something else. So, I think it's important to really acknowledge and understand that because I think it so often goes ignored. People just think, "No, you're the front end dev. You do front ends and you can't change from that. If you want to change, you're essentially going to leave." Um, >> yeah, >> but I think people can change and sometimes it's not even you need to give them just completely change their role. Sometimes it's just that they need like 20% at back end and suddenly their excitement's gone up again. Um, and they were just they were just sick of >> hugely individual. >> Yeah. I I even had like literally over the past couple weeks I've had that with a team member and it caught me off guard because when we were talking about something I happened to mention and they like I I was kind of like oh almost like a by the way like just so that you're kept in the loop and then they were like wait a second like that's that's incredibly interesting and I was like hold on what? Um, but it's I think it's a good reminder that like that exact thing happened where I had someone who's highly skilled in an area. Um, I consider them my subject matter expert in that area. Um, we have work to do in there. So, they can they can crank through a backlog. They can come up with really good ideas. So, from my perspective, I'm like, okay, well, this person must be like very engaged by this work. And it's like perhaps they have been and perhaps it's not like necessarily a huge drain, but it's probably reaching a point where like instead of being highly engaging, it's it's starting to drop more and more and more and reaching a point finally where they're like, "Hey, like are there other things?" And um it was a it was a good like I'm glad the conversation happened because even that individual said to me like like they were kind of reflecting on the spot being like I wonder if I should have said something about this sooner. like I think they were kind of realizing for the first time like wait a second like yeah maybe maybe a different thing would be good. Yeah, I think it's it's very natural in roles um because and that's why we have generally teams that are composed of juniors to seniors because you have work which will stop being engaging for a lot of seniors um that are super engaging for the juniors but the seniors get a lot of enjoyment generally out of mentoring the juniors um and it's you generally have this composition but I think so often now we see teams where there's at least someone where they are the only person with expertise in that area and they are doing all of the work from the stuff that they enjoy to the stuff they don't enjoy. >> Yeah. Yeah. And it's it's can be really hard like I think if you're if you're a person who's responsible for a team and that could be you know manager of a team could be a team lead tech depending on however that's organized. I think it can be really challenging when you have this pressure to be delivering and so you have this backlog of work to get through and obviously that's ever growing. It's never shrinking. Um, so there's always an infinite amount of work to do. And on the surface, what you would want to do to, you know, to optimize this would be, okay, well, whoever my most skilled person is at this thing, like get them on the next most important thing that they're aligned with like technically and should be simple. We just keep doing that and we'll crank through everything as fast as possible. But like that's not how it works. There's many other layers to this and exactly what we're talking about right now with like this, you know, what you're engaged in, what's going to give you energy. If you start misaligning that then and you're not paying attention to that feedback loop, then all of a sudden you're like, you're months into this and you're like, why isn't this working well? And it's because you've screwed the whole thing up and people aren't actually engaging what they're doing. >> I actually had a situation that was the opposite of that. um where the team was so interested in trying to get everyone to learn stuff, they weren't shipping anything. So the team was quite big and every time there was a task, so do this task, someone who didn't know how to do that did the task. >> So they were knowledge sharing was like super valuable to that to that team, but it just meant that nothing was getting done because everyone was working on stuff that they were junior in. And exactly as you said, a business doesn't work like that. you can't just not do anything. Um, and and the solution to that actually in the end was the team was just the team was kind of too big. Like I think it was 10 12 pushing that people. >> Okay. >> And it just didn't allow people to build expertise and there was um and have sort of real accountability and stuff. So that team ended up splitting into into two and then three. Um so that you actually had teams that were focused on specific problems that could get excited about that that and they could also develop sort of mastery and expertise and that worked uh really well. So I've actually encountered that opposite situation where you can go too far the other way. >> That's not what I thought you were going to say. I thought you were going to say that like you like serendipitously came across the situation where like all of the energy was going up. But that's a yeah that's a really interesting challenge. How did that get identified? Was it like basically through uh like deliverables where it's like wait a second like it's been a couple weeks now and like we're not actually shipping features? >> It was um it was when I stepped into that SVP role. Um so what one of the reasons for it was I when I joined the org as head of data science I sort of turned the data science team around started making them super collaborative with the rest of the business and started making them ship stuff and engineering was in a spot where they were very uncolaborative and were really knocking heads with the rest of the business. They had kind of established a bubble in which they were super happy but the rest of the business wasn't. So they were super happy learning all this new stuff and they had the sort of own internal culture but it didn't work for the business and that was causing like severe problems. So it was when I stepped into that role it's like okay so what are the reasons for this the business is saying they're not shipping anything is that true trying to find those reasons and through doing that we kind of found some of these things like okay one of the reasons is people are always working on stuff that they're learning they're not prioritizing delivering there's a sort of lack of accountability with some of these things um and there was reasons on both sides right like it wasn't like a the the true narrative from one side But yeah, that was a a problem I identified there and sort of then started to turn turn that one around as well by just making a few changes. >> Interesting. Yeah, that's a that sounds like a very a challenging problem because you would have people that seem like they are highly engaged and like it's almost it would seem like anything you go to do is going to disrupt that and like on the surface like only seem like it's going to be net negative to them, right? if they're already operating in this state that seems like it's ideal. Anything you do that's going to change that is going to disrupt it. How did you you don't have to go into the details necessarily, but like uh from a general approach, how do you how do you suggest change coming from the outside like you're you're making this observation and so you observe this group is operating. They seem to be you know they seem to be happy. They seem to be engaged and now you're going okay but this isn't working for everyone else. We need to introduce a change. How do you get people bought into that or or did you just kind of like say this is how it's happening and too bad? >> I I think this is a a really difficult part of leading actually and like when I self-reflect on some of these things I think should I have been more aggressive in in the changes I wanted to make? Should I have been less aggressive? Because you know I look back at it and think this took maybe three months to change >> but I knew the answer in like week three, >> right? >> So in a way I burnt two months. But those two months were kind of the team figuring this sort of stuff out. Um, so was that too slow? I don't I don't know. I still think about it sometimes. Um, but I think the ultimate answer to that is actually accountability. So I think the the core problem on that team was there wasn't a leader of of the whole team. In fact, there were three people that were sharing leadership of that team. And I kind of believe that on any sort of project, when you have more than one person that's accountable, no one's accountable, >> right? >> Because they can always just like point fingers. Oh, they were going to do it. They were going to do it. Um, you try and talk to someone and you're talking to different people each time and you can't pin anyone down. Um, so I actually think the key change was to make one person accountable for that team and then actually hold them to account because then because now they can start to see the problems. They can see the team. They're they're embedded in the team and we can sort of work on those problems together and it kind of filters down that way. I think the before they were getting away with not being accountable >> to the rest of the business which was frustrating the business and I think they were happy but I wouldn't necessarily say as we to reflect on the beginning I wouldn't necessarily say they were high morale they had big problems with the business in terms of how revenue was operating and how they didn't feel aligned with any of the goals and they didn't really know what the vision of the company was they they had they had their own problems with the business as well and I think it wasn't n't just solving some of the problems in their team. It was solving the problems that they had with the rest of the or as well. You know, it went both ways. There was a lot of things that needed to change in revenue and other aspects of the business and how how they work with product for example as well. Um that kind of created I guess a high morale team from a happy team. >> Yeah. Interesting. I and your your point about you know could could it have been done faster like did you waste months on this? I think it's a super interesting question and super interesting reflection because you know you could you could take the super aggressive approach which is like you make an observation once you have like a gut feel or whatever data you're using to back it okay like I'm making this decision everyone starting tomorrow like here's how it's going to be. Um that might have started the transition to that much sooner and then the question that we don't know the answer to is like yeah but would people have been bought into that? would they have been like screw this like I'm out like I don't like this guy coming in and changing things like I don't want to do this >> and and that's what I think really hard part of leadership is you don't always get to explore that decision I will never know what happened what would happen if I made different decisions there um I can encounter similar situations later in my career and make adaptions based on that but it's never exactly the same and you never really know what would happen if you did something differently. Uh did I get the balance right? Well, we ended up in a good place, but could it have been better? Could it have been faster? Um, and yeah, you you don't get to know. >> Yeah, I think I personally heer on the side of like and maybe too much so of uh like I don't like coming in and I think it's because I've seen this happen to me. Uh I don't like coming in and like demanding a change. Um, if I have observations, I will basically start sharing like, you know, try to kind of get the team poked to be like, like, do we think that we could do things better or do things differently? But I I personally lean very hard on getting the team to come up with the suggestions. And like I said, I think the reason that I do that is just from earlier on in my career when I was working at a startup, one of the things, and I don't blame the founders for doing this, but they would they would bring in people that, you know, they were like, "Oh, this person has done really well in the industry. We'll bring them in." >> And then I don't I don't know what that person was told when they were hired, but a lot of the time it would be like, "Well, I got brought in, so like I guess I'm expected to make some changes or do things a certain way." and they would start doing it and it would disrupt everything in not a good way. If it was disruptive in a really good way then maybe I think my mind would be uh made up in a different manner here but so many times it was disruptive and because I was embedded in the team so I was managing the teams but also like as an individual contributor at the same time I could see like people basically grinding to a halt on certain things and it's like this was fine two weeks ago like what's going on here right and uh I think what I noticed over time is that if I help try to ensure that people are part of that decision-m process. Even if it's like they come up with the exact same ideas that I had or if it's different, it doesn't matter if it's my idea or not, but if they come up with it, they seem to be bought into it more. And if they're bought into it more, then even if it's different, it seems to be uh more successful. >> Yeah, you you need to bring people along for the journey. Like they don't always need to have the idea. Um, I do think the worst situation is where someone comes in and just immediately starts changing things. Um, without understanding what the problems are. Often it's I did this in my last role and I'm going to do it exactly the same way here and it doesn't work. They haven't understood the core problems. If you go into pretty much any company and you talk to the engineers, they they're probably going to complain about sales. And if you talk to sales, they're going to complain about the engineers, right? Like it's it's just natural. Um I think it's without going on too much of a of a sidetrack I think it's natural partly because the incentives of both teams are different. Um engineers are really incentivized by um improving the product to giving value to to customers uh whatever the metrics are. It's very collaborative. Uh revenue teams tend to be really selfish and I don't mean that in a bad way but they tend to be measured based on their individual performance. Their their salary and compensation is based on their individual performance. their targets are on that and if they don't hit them they are they are let go because of that. So they are incentivized in every single way to be selfish generally. Um so that creates this this this sort of dynamic between the two. Um but one change mechanism that I really like and employed in every company that I've joined is the retrospective. Um, and I think when I've talked to people about this before, some people really don't like retrospectives, and I think it's because they've had bad ones. Um, but the good part of retrospectives allow you to go in, even as a leader, and go, "Hey, I see this problem. Let's talk about it." But the most important part being, >> let's try a solution. Like, here's my suggested solution >> and but let's talk about it and we can maybe do something else. But the most the key part being is in two weeks time, 3 weeks time, however often you do your retros, we're going to discuss this change and if it didn't work very well, we're going to scrap it or we'll adapt it or we'll try something else. And I think once you do that, people now feel safe with change. They now trust you to be okay. You've suggested this. We don't like it, but we will try it. And you try it and it worked really well. And they're like, so that's points for you. They trust you more. Or it didn't work very well. and they can be like here are all the reasons like have we got any better ideas of how to solve this problem because this problem still exists and you try that um and then I think people then get safe with change because the fear always is if someone comes in and goes hey we're doing this now >> you don't get to change it that tends to be it like I know people where someone's come in and gone we're all doing scrum now and and everyone's now doing scrum there's no process where in three weeks time they go is scrum working or even in three months time is scrum working it tends tends to be when that person is fired for destroying everything, then it changes to something else. But I think you want to create this where people are on the journey and they know they will be heard and they know if this change does not work, it won't continue. >> Yeah, I love that so much. I've talked about this before and my general approach is that I just like I feel like the word agile got really um dragged through the mud um for maybe all sorts of really good reasons, but I can remember being at this startup. It was called Magnet Forensics before Microsoft uh before I was at Microsoft, I mean. And um I remember we were hiring people and in the beginning it was like oh you know we're an agile software shop like we just talk about it this way and then it was like I'm still learning like even what that means and it's like okay so when I say that like okay well we have some every team is doing like scrum but it's not perfect because it's never perfect what does that even mean and then we had some teams that started to do canban and then over time what I really started to realize for myself was like it doesn't actually matter what we're calling ourselves because literally The only thing that I care about is that we're continuously improving. And your point about the retrospective, that was the only thing that I like really wanted to make sure we had was because then we had something where we could talk and then we could try it. Everything else like if we're doing waterfall the next day cuz someone was like, I really think that that's going to work and the team is like, we should try it. Great. Like let's go try that. Um if that really sucks then cool in two weeks. If it's so bad that before two weeks we got to talk about it, sure. But you know, in two weeks time we're going to have this conversation and go, "Yeah, that didn't work at all." Like, what's the next thing? And that meant that if we were to kind of look at the teams I was managing at least, were they scrum? Were they canban? I don't even know what they were, but they were always trying to improve. And I think that was the most important part. >> Yeah, I 100% agree. It's the main It's the only thing I demand really. And when I joined the second company, it's the thing that like people say, "Oh, don't introduce anything for like your first month." I introduced the retro on like day three. I'm like, "No, that the retro needs to exist. People need to get used to it because it's your change mechanism. It's your self-improvement mechanism." And and I take it a bit of a step further as well in that I really don't like it when you have teams are told what to do by someone several levels removed in terms of like how their process should work. So I I kind of believe that teams are very individual and I've seen this like every team I've run I've ran differently due to the pressures of the business the people in the team and the things we were working on. So I believe if you wanted to team to perform really well, they have to adapt to that and they have to learn how to work well together on the things that they're working on and they can't do that if you're imposing how they all work, >> right? >> So like one team might love scrum. I think scrum and again these things as you said these words get mangled into lots of different meanings but in a sort of base meaning I think scrum is very good for teams that are more like agencies or ticket based teams where their work is very predictable it's very um consistent I think scrum can work well for that um different teams like data scientists that are very researchbased it doesn't work as well canban's a bit more appropriate but even data science team can struggle with that but the point is this is all different one team is going to thrive with something like scrum another team is going to be absolutely destroyed by it and you should allow these teams to figure out what that is where so many companies do impose at the sort of CPO CTO level we are doing scrum across the board why there's there's like no reason really for that >> yeah I wonder if that stems from the fact where it's like hey if we mandate what it is that when it comes to interfacing with other parts of the business that it's consistent but it's like maybe but it's going going to be like consistently crap like because the teams aren't going to be enjoying how they're working. It's not going to be effective for them. >> Yeah. >> And you can let the team solve that problem. Like if I've got two teams under me that aren't collaborating on stuff and it's not getting stuff done and they haven't figured that out, then I'm going to have a conversation with them and be like, "Look, this is a huge problem you need to solve or at least we need to solve together. And we need to find a way to do it because these projects need to move. We can't have this project getting blocked for three months by that. So like let's discuss this problem and how we solve it and how two teams solve it might be different to others and you might structure things in in different ways as in like I like to structure I like teams to be quite independent and structure things in ways that they don't have to coordinate as much and I think you can kind of set teams up that way but largely you want teams to be able to solve problems themselves rather than coming to you you can just like bring the problem of hey this is an issue right now but ideally they've already identified that and are working on it in a perfect world. >> Yeah. And I think like I really like that approach where like the team itself has enough autonomy that they can make decisions, they can problem solve like on their own. Um, you know, obviously it's not like they they never need to interface with another group or never need help or anything like that, but um I would personally I would feel like if I was managing a team and they felt like they had to come to me with every decision to be made, I would be like I'm doing my job wrong because I want to be able to go on vacation, I always I always uh joke that like I think in order for me and I would argue for like even for individual contributors, it sounds kind of backwards, but for me to do my job most effectively. I should be basically replaceable, which sounds odd, but I should be completely replaceable and my team should still be kickass because I have ideally set them up to be like that to the and it's like not that I'm not valuable, but it's like I helped create the team and form the team so that they can operate that way. Um, and I feel like if I can't do that or I have not been doing that, then I still have a lot of work to do with the team to to iterate on that. Yeah, I think all all of the best managers I've had would all agree with that and all say that and I do as well. Um, I think managers need to be multipliers. So, you should be multiplying your team. Um, but I don't necessarily think that all disappears as soon as you're removed. You know, like one of the reasons you're multiplying them is because you're consistently pushing them forward. Um, and the team is a lot better than when you left it. And yeah, there's going to be some issues with if you if you if you're uh replaced or gone um regarding coordination, some other stuff, but yeah, the team shouldn't just collapse when you've left. You've just like you shouldn't be such an essential cog that you've set things up that uh it can't work without you. >> Yeah. Well, oh, Nick's gone. So now we don't know where like what's the next thing we work on? Like how do we ever find that? Like I really hope that's not the case, right? uh you know if we have to prioritize this over that like make a technical decision like no like there's super strong technical people on the team like you know yeah I it would feel very bad to me if that were the case but um just goes back to making sure people are empowered uh I think that when you have people that are engaged in solving those problems you will have people that step up to that to be like hey like I'm really motivated to go solve this area and improve it like no one else is stepping up um okay like let me put my hand up and but you have to create that environment for people or else they're like I don't even know if I'm allowed to do that. >> And one thing I do there that's quite rare I think um is I don't like product managing debt. Like I think the best people to manage debt on a team is the team. Like they know the interest rate of that debt. They know if it's causing loads of problems or if it's not. And I think so many people fall into the trap of prioritizing debt in the same way as features. And what you end up having is um like product is deciding when the deck gets done and when it fits in and communicating that. Um I like to give teams enough breathing room that they can do that because I I don't want to be involved in that decision. I don't want to hear about every piece of debt they've got. I want them to be solving high interest debt as and when it makes sense for them to do so. >> Right. I when I've seen that work really well is when and you kind of talked about this like with sales and engineering having like a sort of this this healthy natural conflict and I I personally I I see that work well with like engineering and product where >> um >> and I I've heard this so many times from engineers are like product doesn't give us time for tech debt and I'm going yeah because it's not a decision that they can they can make but >> ultimately if we're talking about scheduling and things getting delivered I would fully expect for engineers to be able to say Hey, like we need time to go work on this because everything that you're talking about delivering, like if we don't address this debt, we're going to be screwed trying to do that. It's only going to get worse. Um, and then making a case for it. But I, any product manager I've ever talked to has never like, especially when we're talking about, you know, engineers not getting time for tech debt. Any PM I've ever talked to has said like, I don't know how to prioritize that. if they can like explain like why that needs to be done like I'm happy to make the time for it but usually what happens is engineers unfortunately end up just saying like we have to do this and they're like well why well >> the code's not clean and it's like well what does that mean like there there ends up not being an actual conversation around it and then the other side doesn't end up understanding >> yeah I like to empower the team leads and I think decide upfront with product what sort of percentage we're looking at and it's going to depend on the org, >> but you're if you make the like you're never going to have debt is never going to win out against revenue generating features >> and to be honest the features that don't generate revenue are never going to win out against uh non-re revenue generating features even if those are going to be really important in six to 12 months. Um, so you kind of have to decide up front where your split is and if so you might be like 10% 20% debt and then kind of allow the teams to have that time to self organize um and and use that time either for research or experimentation or debt or however they want to do it without having to explain themselves all the time. You've just agreed that that is the right split for your organization or your team. >> Yeah. Because otherwise it's like, you know, every single conversation is this battle of like how do you >> how do you make that happen? And it's like like you said, it's it will almost never win unless you're like, hey, we have this debt that's going to and you can very clearly articulate how it makes you accelerate like, you know, pay it down over the next two weeks and the next 10 features are going to be done in half the time. And then it's like okay, but it's so hard to do that with every feature and if you had to do it for sorry for every piece of tech that and it would be you know you would basically never make any progress. So >> yeah the the best example the best sort of example I've heard of that recently was I can't remember his name but he gave a talk where he was talking about innovation in the NHS. So the NHS is the national health service in England and it's a huge organized public organization and he said if you want to make a change even a small one um you've got to create this document. It's got a standard process and it's probably going to take you three days to create that document. You've then got to submit it to this initial committee and if that succeeds there's three more committees and then once you get past that if it's above a certain value or it affects these certain areas it needs to go to these different other ones here and he went on just talking about this whole process and he closed that with and where you would have stopped trying to make this change is where you got bored in this sentence and I think that's true right like the more bureaucracy and process you put in devs are like I know this is a problem it's causing these huge amounts of effort but I am not willing to fight for it anymore because it's too it's too timeconuming. It's too much mental energy. I should not have to be fighting for something which is necessary and needed and have to overexlain it and go through all of this process and planning and documents and all this stuff for something that is might be like three days of time to change. >> Yeah. And I think on just on that note, I think understanding uh because this is something else that get missed and I don't want to go off the rails on this, but something else that gets missed is like the the time requirement for some of these changes, right? I think I've been in situations where some people I think most software engineers, this includes me, uh not very good at predicting or estimating time. And I think that if we can be more upfront and honest and time box this kind of stuff, it makes all of that so much easier instead of, oh yeah, it's a quick refactor and then 6 months later it's like, you know, I've rewritten the codebase and it's still on a branch and I can't push it. Um, yeah, not a good spot to be in. But, uh, Ryan, I wanted to say thank you so much for this conversation. Um, uh, I will collect links and stuff from you after, but if people want to reach out to you, whether it's LinkedIn, your newsletter, where can people find you? Yeah, I'm on I'm on LinkedIn mainly. I've literally like in the last few days started on YouTube and Tik Tok as well. Um I probably will we'll start on some other platforms. So yeah, YouTube uh LinkedIn is the main one. I also write a newsletter as I said called Brilliant People Exceptional Teams and yeah, we can put the links to those in the uh in the notes. >> Perfect. Okay, thanks so much. I'll collect those from you after. And again, really appreciate your your time here. thanks for for walking through your career journey and how you're navigating really trying to make sure that engineers uh are engaged and having really high morale teams because I think that that makes a world of difference versus just like pick the next highest priority thing off the backlog and and get to it. So, thank you so much. >> No, thank you. It was a real pleasure and really interesting conversation. >> Awesome. Thanks,