Engineering Management In Product Engineering (with Ryan Murphy)

It's definitely down to relationship between EM and product because sometimes you do have EMs that try to circumvent what product managers want because that's their way of doing it and they know best and vice versa with product. Welcome back to the Product Engineering Podcast. This week we are talking about engineering management and what engineering managers need to know about product engineering and this week I'm joined by Ryan Murphy. Ryan Murphy is a seasoned engineering manager. He's the founder of EMaccelerator.com and recently the founder of Crying on the Sofa. Tell us more about that. So Crying on the Sofa is something that was born out of just passion. So I'm a big believer in mental health and that everyone is fighting their own demons whether you like it or not. Everyone is. Whether you know about it or not, everyone is. And it's just my way of creating events with the goal of having one million conversations about mental health. I wanted to just write one conversation at first but I upped my goal a bit. I've always got one million conversations and we're starting in Sheffield, our first event and the reception has been amazing. We've been in the press about it, Reddit has blown up a couple of viral posts on Reddit about it and yeah it's gone really well. That's really good to hear. I mean it's difficult one of these things because people don't talk about it enough and I'll be perfectly honest one of the reasons why I started this podcast is because I noticed a lot of insecurity amongst software engineers when AI came about and people who not just saw their job as writing code but they saw their whole identity as writing code. I've known a lot of people outside of work that are really facing a crisis of identity now that AI is writing all their code. One of the things that we try and do on this podcast is show people another way that they can grow in their careers which is moving towards product and product management and product-led engineering. It's not an exact crossover but it's definitely one of the things I think about quite a lot from the reaction they've had to the whole AI revolution. Yeah and one of the same, a similar crossover I saw about people's identities is when everyone was loving it when we got to do remote work but then it started to shift and it started to go back into office again and I then saw the same, not as bad but a similar shift with people. So let's talk about product engineering then. What's your experience in general with product managers over the years? As a seasoned engineering manager you must have had to work with a lot of product managers over time. So how is your relationship been? What product managers have worked well with engineers? Which ones have struggled? See I have, I generally put it into two camps, big tech and not big tech and for me that is a really interesting divide because my experience is that when I first became an engineering manager I was at a company which had maybe like a 20 strong tech team and that was a mixture of QAs, engineers, manager, CTO and maybe 25 at a push and at the time that's the biggest company I'd worked at and I thought, no it wasn't but the biggest tech company I'd worked at because I worked with finance before and I thought well this is massive team, that's amazing. 20 engineers with me, like that's amazing. So for us, product managers were very ingrained into teams, they saw our decisions on things, they bought outcomes to teams and like that was, I guess I was lucky to have that experience early so that was my experience generally but as I moved like for example in finance, it was very different, it was more business analysts, there wasn't any product managers, I was told okay build this feature for this, I was told build this feature for this finance team and I'd go and have to do it or build it on SharePoint. I didn't really have a choice, I had to build it on SharePoint and like I left that job, you can imagine and yeah then I moved into Yelp and product managers were still within us but the product function sat separately to engineering and it was like one product manager might sit over like a whole space and like they might not necessarily be as ingrained into the team but they were ingrained into the space and that was a little bit of a shift for me whereas before it was like we were just one huge team of 20 I guess and that everyone was ingrained into that. Yeah that's an interesting kind of side note about how product managers are structured because I've seen both things work and fail in both environments so teams will typically take on more than one work stream that's generally like if you have a five or six person engineering team you might have several epics that are largely unrelated and I've worked at companies where they have a product manager for one or two teams and whatever that team's doing that's your product manager and I've worked for other companies where a product manager is assigned to an area or work stream or something like that and so a team might interact with two product managers and I think as I first went into engineering management that was the model I was working in so one of my first jobs as an engineering manager was to build up a relationship with more than one product manager and try and act as that bridge between engineers and their product manager. Yeah. Is that something you've seen? Yes I have however like I don't like this this middleman approach like I have definitely seen that where the engineering manager is like like these are my engineers and we're responsible for the how and come to me with the why and we'll talk to the team and it's very that's very like agile of a capital A for me and it's a super interesting way to do it but for me I would much rather like be more ingrained in the team and then presenting their problems and outcomes directly to the team rather than through me. I agree why do you think organizations fall into that model though of having a barrier between the engineers because some might say it was to protect the engineer's time that's a common thing you hear like they need heads down time let's not distract them with all that kind of stuff. I might get trouble for but I think a lot of it is ego and like people become managers and they're like well I'm the manager now like surely I should have a say before the team sees it and I should vet it before the team sees it and I'm protecting the team by doing this. Let the team just fire shots let them just fire their shots because I guarantee half of them are smarter than you were doing it. So yeah that's what I felt when I was engineering it was just like just let me out the product manager just let me out of them and I used to love it. Have you had many conflicts with product managers and what kinds of things do you think causes conflict? Yeah definitely conflicts when I've had product managers in the past say things like well it's just a button and it's like well it's not just a button it's a button which adds a new payment processor which we've got to add all the security for all the socks checks around that security and finance we've got to make sure it's compliant and that button was adding a whole new payment process but it's not just a button it's actually a year's worth of work. So things like where there's a misunderstanding but that's also on me because when I had those conflicts I was nowhere near mature enough as an engineering leader or an engineer to be able to talk properly during those conflicts and help them see my viewpoint it was just well they don't understand me it wasn't I never thought well they don't understand me how can I help them understand me it was they don't understand me they're the problem and yeah for me it's maturity point yeah. Yeah now absolutely so one of the things that one of the ways that I've seen this conflict come out is when product managers don't know where their remit is in terms of the task flow of their engineers so you might sometimes see product managers assigning individual tasks to engineers and that creates a lot of conflict with engineer managers because they sort of see that as their own thing and in a product engineering world engineers see that that is their job right like I should be picking up my own tasks so is that something that you've seen Yes yeah 100% and it's definitely down to relationship between EM and product because sometimes you do have EMs that try to circumvent what product managers want because that's their way of doing it and they know best and vice versa with product so I think a lot of it is like a symbiotic relationship with the EM and products but yeah I've definitely seen it and it's not great because people are just confused that EM might label it to kit in another way whereas the product wants it labeled in another way they might want they might want free in-flight tickets at one time on the Kanban board where as the EM might say four and it's little things like that which slow you down they're a problem and you need to address it. Yeah so one thing I've seen being really successful on combined products and engineering teams is when every single person on that team is given as much autonomy as possible so engineers are literally said this is the outcome we're trying to get this customer you go and speak to that customer yourself you read their feedback and that only works if you can pass context between people that know about it and people that don't so in the example you gave earlier on of a product manager asking you to put a button on the page and they didn't have the full context of how much so you could say that's a breakdown in how context was transferred from some engineers to a product manager but the same happens the other way around I've noticed as well so a lot of the time an engineer will say for example the classic would be I've done this it's shipped it's merged and the product manager would say I mean okay you did exactly what's said on the ticket but it's not actually what we needed in the end and so then the product then the engineers will get really you know they'll get their back up about that because well they would say well you're just scope creeping now you're adding more to the scope and the product manager will say well my job is to get the feature to actually change the user behavior the way it's supposed to so how do you manage context flowing between product managers and engineers explaining the technical context to product people yeah so I think a lot of it is I think people dislike these meetings but a lot of it is during like grooming and planning and stuff like that which which does help that's like the obvious answer the less obvious answer for me is is cultural things so for example onboarding something I've done in the past very successfully as an EM is every engineer that's onboard I don't care how even if you're coming in as a distinguished engineer I don't care you're doing this the first three weeks of your job you're not touching code I don't care who you are you're not doing that you're going to spend one week in sales two days in marketing three days in CS on the things and for me the least important part of domain knowledge is code and I've always said that and look at AI now I've been proven right 10 times out of 10 and I chuckled to myself a little bit about that because the engineers are going to excel now and the people are doing exactly what I said to do go and spend time with them make you the person that they think of when they've got a problem and come to the outcome they need and yeah so for me it's part of onboarding as well which can help that but also the psyche of things like what do you celebrate do you do you celebrate high technical talk and high technical excellence in engineers or do you celebrate engineers achieving outcomes and stuff like that and if you achieve if you celebrate engineers achieving outcomes rather than technical excellence and okay they've designed this awesome factory pattern right okay cool but did you reduce CS calls by five percent or reduce CS wait time by 32 seconds which made them impact on bottom line if you say that's what matters then behavior changes and the way people talk between engineers and product changes as a result of what you're celebrating that's a really really important point I think celebrating not just celebrating delivery but celebrating hitting something because I've you know teams will often celebrate when an epic gets to the end or something like that but ultimately if that epic wasn't the right thing to be building you know you very rarely celebrate creating a spike that didn't work I think you should I think I think if you spend three or four days building a proof of concept and then it turns out that wasn't the right thing that should be celebrated especially if you're a product engineering thing yeah absolutely because you've learned something you've learned that that wasn't the right thing to build right and you can spend the next three or four days doing the next thing so I do think we need to talk about AI how do you think AI and particularly like coding tools so I mean you talk about engineer management you might think of oh I use Claude to organize my thoughts but how do you think coding tools have changed the discipline of engineering management yeah so it's definitely highlighting to people the importance of that product focused engineer because now even though I've been off the tools for like I haven't I've coded but not professionally for years if I'm going to be honest with you like if you're my old team ignore that statement but I haven't coded in years and I miss it because that was my craft I found a love of it and I get these coding tools and I feel my passion brewing all over again and if I start working again as an engineering manager let's say touch with my my businesses don't work or something like that and I've signed a drink I'm gonna be a super freak I'm gonna be it's gonna be an absolute superpower of mine because I was always that way as an and now I've got these tools so what I think it's doing is it's highlighting to people that actually this soft stuff we've been talking about all the time about communication and stakeholder management and written updates all this stuff stuff we've been talking about while you've been hiding in the corner doing your code it's actually true it's actually more important than ever and as an engineering manager where it's so important is like how do you coach people on that do you do by example or do you actually take the approach of not leading by example and letting people fail at it and then coaching them afterwards and so there's so many different approaches how to do as an engineering manager but yeah it's definitely highlighting that we need to coach our engineers in a certain way not just push technical excellence what do you say to engineers that just say I'm just not very good at talking to people I'm not good at communication yeah I get that and I'm half introvert I'm half extrovert so I definitely get that and it's a problem but there are ways you can do it for example you as an engineering manager you can help these people by saying okay right in meetings we'll have a pre-read up front and you can add notes and add action items that you wanted to schedule a meeting before so you don't have to necessarily raise your hand and say let me interrupt the meeting let me draw attention to myself and let me make this point the points on paper and as an engineering manager I can say actually I know that you're an introvert and you don't want to talk about this sort of stuff necessarily and I can say hey Ryan's made a point here subconsciously let me bring that into the conversation and maybe ask people that like Ryan might be close to about in the chat and see if that bubbles Ryan interest a bit so there are ways of doing it um so yeah but I would definitely encourage you to talk to your about this and say like I just I if I was a manager and I had someone come to me and say to me look I'm not that good at this or I don't feel comfortable doing this but I understand that the way the world's going it's probably an important skill um can you help me and you'll know the caliber of your manager but depending on how they react if they're sympathetic if they engage with that if they find ways to try and help you then that's great but if they just say well that's an important skill you better learn it bucko it's going to be a problem for your career yeah no that's a really good point so that's AI coding tools and how that's changed people's identity from they have to develop their soft skills how about other uses of AI particularly in engineer management like how can engineers and engineer managers use AI to kind of create that personal operating system that we can do these days yeah so this is something I've got coming to EM accelerator soon is we've got a course in this from Owen Lewis who's a who's a an AI expert director at Oracle um and the thesis that I go with the way that I understand whether I used it and I've seen people that I coach successfully use it is to take the stuff that they don't necessarily like away so I actually see it making management easier because to be a good manager whether you like it or not whether you want to accept it or not you have to be organized you have to be on top of your tasks your outcomes your metrics um your inputs your outputs you have to be on top of it because it all bubbles up and it all gets on top of you all come crashing down and you look at absolutely like snowfall so you have to be organized so I think it definitely helps you stay organized so it can automate morning routines it can automate creation of docs it can really help you with not do it for you but going to help you with understanding how you want to approach performance conversations and metrics around those performance conversations and things like that so it definitely helps there but it can also be a partner to bounce back on to judge your opinion on how you're viewing something so okay is is my like I don't recommend like just relaying what chat gpt says for example but it can definitely act as like a partner to say okay am I being am I being a bit much here and stuff like that so there's two ways there's the there's the the coaching partner but there's also the the superpower which I think in people's operating systems it's going to help you be a more effective manager easier because there's two parts there's management and there's leadership not every manager is a leader and it's going to help you be it's going to help you do management better definitely I would also say that not every leader is a manager as well because a lot of like leadership is involved in like staff software engineering as a leader so I like you can be a technical leader in certain area but yeah no it's really interesting I do exactly the same I don't use AI to write slack messages but I will often run a slack message through AI and just say is this going to get me into trouble is this the right level of politeness directness is this going to be misconstrued no no I completely agree with that but yeah I think writing is an interesting one because you know people do tire of AI written documents and I'm sure you've seen this as well I like you get the meme is that somebody writes an entire document of Claude and then the person reading it just pumps into Claude and says give me the tldr right so like where do you think it isn't isn't acceptable to use AI in writing I mean would you write a product requirements document with AI this is something I've got fairly strong opinion on if you know me because at the top of some of my blog articles which people read I write I give a very big warning this was not written with AI and I do post on it and stuff like that and I'm a big believer that if you don't have the time to write it I'm not going to take the time to read it and it takes for me it takes personality out of it but for me also like I've got a brother that's dyslexic for example so it massively helps him hugely in that so I don't think we should ever take it away from people either for that but what I do think is for example the way I use it when I'm writing maybe I can write on a blog post is I'll say okay okay create a template for me to write on okay have like have like the headlines and I can like I can like expand on the headlines and you can do that with specification documents you that have one pages for new features at work for say you've got new features like a one-pager proposal you can okay outline bullet points for me that we've discussed and then I can manually expand on them so I think it depends on team ethos a little bit in your personal ethos because there is a bit of a should you shouldn't you in the tech world at the moment about about AI written writing because you're right people do tire of it and yeah you do need to be very careful of it but also you need to be aware that some people genuinely find it useful because they've got things like dyslexia which which genuinely helps them that's fair one of my favorite chrome extensions is the pangram chrome extension yes and uh ryan's do always show up as human written and that will stand out on linkedin these days because it's very rare to see somebody just posting human written stuff yeah that's really interesting what do you think um the future is for engineer management do you think now that it's so easy to use clodco to build stuff the expectation is going to be that engineer managers are also going to be building things with clodco and stuff see the truth is I can now the type of software engineer I was and the type of manager I was I believe that for example if I walked into pendo tomorrow I could do the output of a whole team myself I firmly believe that like but that is maybe why like I was like a bit egotistical and maybe that led to like a creator career and stuff like that because of that because of that like maybe like like unearned ego or something like that right but yeah if I'm being real for a second it's it's gonna be the opposite of what a lot of people are spouting right now so a lot of people are spouting you see these blogs and something from like james stania and stuff that say okay people are going to be much more hands-on and they're insinuating that the people leadership part of it is going to fade away and it's going to be like huge teams and you're going to be like almost like part of the team but you're going to people are insinuating that you're going to be like that's that management person but a normal engineering your team almost that's why the huge team and facebook are trying it and look how that's turning out right but I firmly believe that the human part of engineering management the people leadership part of it is going to be more important than ever and in a few years you'll see people really really indexing on that whether it's called engineering manager anymore I don't know but the role of being responsible for that for team health and people will still be there and I firmly believe it being more important than ever because as we spend more and more time talking to bots and less time talking to each other it's going to be a problem and people are going to burn out much quicker I mean look at me like I remember now spending 13 14 hours working a day easily and I look up and I haven't realized they've even done it and half the time for a few hours of hours just pressing enter on a keyboard and that's just the honest truth whereas I think if you have a team of people doing that it's just going to all end up like drones doing it and you need someone there to help that human element part of it and deal with that burnout and deal with the team relationships and stuff which are going to go missing I think that rounds out this episode really nicely to go back to talking about mental health because I've had several points in my career where I've found myself being an unqualified counselor for people that report to me and I kind of ended up in this situation thinking I have to help this person with something that I'm not qualified to help them with because I genuinely feel like I'm one of the few people that have spoken to this about so like what advice do you have for engineer managers that will eventually find themselves in that situation where you are somebody's ear and you are you know having to talk to them about things that are really beyond the limit of engineer management but you you feel like if they don't talk to you no yeah there's there's like the there's the process part I want to get out of the way because people do forget that you're a manager as well as like a hopefully like a people leader and the people leader is the part that we'll talk about in a minute but for the manager part of you you have to understand what resources your company has available for them what resources you can do for them from a management perspective in terms of is there like an unpaid time off policy is there mental health leave policy you need to understand that that is crucial if you don't and you come to this conversation I'm prepared for that it's going to be a bad look for you and you'll always regret that that mistake so my first my first advice is be aware of what you can give them from a management side of it now the leadership side is just try to shut up just just honestly just just try to listen just try to sit there and and ask the old question but just be that ear because a lot of my problems for example creating crying on the sofa where I was sitting on the sofa cry my eyes out deep in depression and I didn't know where to turn if I managed I started trying to give me advice on that about like one up it almost seems like one upmanship then that'd well me up a little bit but luckily I had a great manager at the time and it was just listening it was saying what I can do about leave and like having an ear and saying okay is there anything you need from a work perspective so it was really good for me to have a person just listen and just let me vent and I really appreciated that yeah I've done a lot of management courses and all sorts of leadership courses over time the greatest one I've ever been on was a hostage negotiator that used to work for Met Police and he did an active listening course so we all went along and we just learned how to listen yeah and we learned the body language of listening and we learned the questions to ask but like you just said when to just shut up yeah so yeah and it's it's when in your brain when someone's talking to you are you thinking is the first one in your head but or when or however that's a problem shut yourself down and just go back to okay what they're actually talking about yeah and that's my biggest advice about active listening is it's your first word is but yourself out of it yeah yes and instead of yes but yeah cool well on the theme of shutting up that's it for today Ryan thank you so much for coming on stay in touch and you'll find links to crime the sofa and the e-me accelerator in the show notes of this episode thank you so much