How hands on are you?

I mean, I dropped the topic and you're going with the actual prompts. This is, this is how it should be.

I just want to have more than one sentence to say.

That's the problem, I think, I mean, before getting to the depths of it. I think that's why I wanted to bring it up. I think it's a very nuanced part of our role and I want to rewind before we start getting into the topic.

I've got post it saying, right, introduce properly and to ask for feedback and all this other stuff. So I best do that first.

Let's do that.

Cool. Right, so this is the Managing Engineers podcast, version two, episode three. I believe we've now beat version one. We've got three episodes in the can. I'm Si Jobling, Engineering Manager, and this is Neil Younger, also engineering manager.

Hello.

And having known each other for a while, but not very well, not into the depth, we thought actually it might be a really interesting podcast to understand the nuances of our jobs and how we compare notes and is there a problem in the industry or something you want to share about it? Anyway, so, yeah, I'm going to stop rambling and get to the point now. We were thinking about topics the other week and it's my turn to bring one this time and it was quite a hot topic for me. It was about how hands on are you as an engineering manager. And without getting to the depth yet. I think Neil's already got some thoughts on this. So how do you want to do this?

If you already started, I guess why don't we start with what do you mean by hands on? I think that's going to be a good place to start from. And at some point during today when we maybe go down a rabbit hole, I'll refer back to our learning episode. And I, and I was excited about going to Agile Cambridge and I can tell you some of the outcome of that.

I love the way you segue to another episode, so people have got to listen. That's great. So context. I've been engineering managing for, well, in that job title for the past sort of five years. And every time I've gone into that role, it's not been very hands on. When you say, what does that mean? It means I'm not necessarily making changes to the code of whatever we're building. As an engineering manager, I know what to look for, I know what we should be doing and I know the kind of skills we need and the abilities and the best patterns maybe and stuff like that. But don't leave me loose on that code because it won't be the best quality. And as a QXQA manager person, you're like, whoa, don't let sign here that obviously. So when I was going into this, I was like, well, I know this is quite specific to my role. When I look talk to all the engineering managers around the industry. I know some are very hands on. They are very much like in the commits, they're writing the code, they're doing all the good stuff around it. I just really wanted to get your thoughts, Neil, on, like how hands on do you get in your role at the moment?

Okay, I'm definitely gonna answer that question, but I think I'd like to want.

To rewind and unpack it a bit.

I think I'd like to know from you, Sime. So you mentioned hands on for you was like getting into the code and I guess I was just gonna throw out a challenge before we. And I'll get back to how hands on I might be at the moment or have been. But is. Is that all an engineer might do? Write code?

Oh, very good. No is the simple answer to that for me.

Right. So I'm wondering.

I should. Yeah, like, yeah, I should probably put some wrappers around that. So as for me, I'm not an individual contributor.

Okay, got you.

So writing code is just one factor of that. Right. There's also the designing, the problem solving, the bug fighting, the monitoring, all the other good stuff we put around engineering as a whole. I might do some of that, but it doesn't mean I'm actually contributing to the, the repository of code or a specific app or whichever line of code that they need to make some changes to. I might be able to jump into a merge request or a pull request to see what's going on and understand it. But I, and I could in theory approve that request if need needs be, but I tend not to and I try not to in, in my role because there are some tech stacks that are completely over my head. It'd be dangerous for me to do that. One caveat to that. The other week, well, the other month I had an NGSA si. Can you just help me get this config change live? No one else is around to approve. I was like, if it's that little low risk, it's just a minor bump on a virgin number and we've got the pipeline in place to protect it. Sure, I'll put my name to it, that's fine. But generally I try not to do that.

Okay, cool. I Think it. And the reason I ask is when this question comes up whether it's referred to as hands on or technical, I think it's always useful to unpack that because there's an argument to be said that there's a lot of technical work that isn't just writing code. So using that definition you might be more technical and more hands on than you realize, like in terms of what you're applying. But if we're using the hands on equals writing code sort of smaller or narrower definition at the moment before we go wider. No, I do not write production code at the moment. In my current.

You go near it, would you be tempted to or would you like to?

That's a great question. Hempted? Yes. Would it be wise? Less so. I think.

This is why I get into it. I'm comfortable being around code, I'm comfortable talking to other people about code. But I am nowhere close to being the expert in any room at the moment and haven't been for quite some time. So I think it's acknowledging that you can bring some nuance to a conversation, but you're not going to be the expert or even close to the expert. You might vaguely hang on to what the expert is saying, but that's probably about my limit. I'm always been comfortable making small and minor changes. I'm always comfortable reviewing and working with engineers. But right now much, much less. So I think there are as an acknowledgement that there is more value with people who are closer to the code every day doing that than me.

Yeah. I think both being ex engineers in different types of them, we have a natural inclination to understand what's going on.

Yeah.

And we could possibly understand the pseudo level of the code and maybe not the depth of the detail of what they're doing. But I'm also a little bit of a geek, not gonna lie. And if there's a bit of code involved, I'm gonna try and find out what's going on. If I'm. I mean people talk to me going, so what does software engineering manager do? I'm like, well, I don't build the stuff, but I certainly help people build the stuff. And they're like, but that's really cool. That's like techie, right. I'm like, yeah, probably more than what you are. But I wouldn't say I'm highly technical like some of the engineers I've got around me.

Yeah, I think that's. I like that analogy in terms of that I think the. It can be. And in some, in Some guys, the engineering manager and engineering leader is that supportive function, supporting and being part of the building process. But that doesn't as we could probably agree that an engineer isn't typey. Typey on a keyboard every day. There's a lot of other parts of their role that would or could be described as technical and being involved in those is equally as important.

So you're telling me you'd like to, but you wouldn't be comfortable and confident?

Yeah, and I think like just means, I guess it's like a.

So an analogy. Many, many years back, I learned to ride a unicycle. Fun fact. Sorry if you don't know that about me. I can ride unicycles.

Here we go. This is what I like to learn about you.

And it took a long time and I love it. Still do as I get older and my body is less agile. I still unicycle occasionally, but not. And I think that's it. It's going back to a previous love. It's remembering what you, what you really enjoy, but also being aware that maybe it's not as the most sensible thing for you to be doing right now. So I think that is how I would treat sort of code. It's going back to. It's a fondness, a memory, but also very mindful that, you know, maybe it's. It's not a pro. Just while it's not appropriate for me to be unicycling every day now it's not appropriate for me to be.

It's very, very cool and I get you because I feel like I, I watch basketball NBA when I can, when it's not stupid hours of the morning. I love, love, love basketball. It's one of my favorite. It goes back to my youth and what I enjoyed doing. Just throwing hoops all the time. When we had lockdown and we were allowed to go to the park with the kids and do occasional exercise, I went down with them. I was like, come on kids, this would be great fun. I was like, wow, that's why I don't do it anymore. I am not as flexible and agile, as fit as I used to be. And there's. I'll keep the memory where it was rather than what it wanted to be now. But hopefully the kids will be interested in this stuff.

I guess it's also about realizing what the value you can bring like has formerly when you're able to do things at a particular level and now less so that that you have a memory of it and you know that you could offer value, but your value now is probably decreased just because you haven't been able to do it as much. You're not as practiced. So it's about acknowledging that as well. And I think that desire still remains. Right? It's, it's always a desire to help and support, but it's, it's making sure that you're, you're directing your attention in, in the best place.

Yeah. Another recent example, like even this week I was speaking to another engineer. They're not a traditional front end engineer. They don't necessarily touch JavaScript, HTML, CSS. She told me I need to learn JavaScript. I was like, ooh, where are you starting? And she started talking to me about setting variables. I was like, oh, how you doing that then? And she told me, oh, constant let. I was like, oh, take me back. We wouldn't have touched those things. That's typescript stuff now. But at least I was comfortable having that conversation with her saying, you know, what you need to do is look into this area and then go and speak to this person who's really good at this stuff and let me know if you need any more pointers because that's what I see myself now as engineering manager role is signposter saying, what do you need to do? All right, I know he's going to be your person or hang on a minute, tell me more about what your problem is and I'll help you weed out the solution together and hopefully you'll feel a bit more comfortable and confident at the end of that conversation.

Reminds me of some other examples at work. I describe my situation and currently I line manage other engineering managers. So maybe a step away from immediate teams and code. But between that group of engineering managers there will certainly be some who for instance during like the advent of code will actively be doing that with engine. And they're complex stuff to solve. Right. And they'll be solving it in the open, writing down their answers on Slack and being very vulnerable about what they know and don't know and working with engineers on it. We also have a very successful code club that's run by one of our engineering managers and again that's practicing, mobbing, practicing code together as a group, building things, but not necessarily for a product or for a delivery, but building for the sake of building and practice. And that would be run by an engineering manager. So it is definitely mixed. And I like that, I like that different people can bring different things, especially when you're in a community.

Absolutely. And again, another example I've had Recently I noticed we've got like Slack at work. We've got an open change notifications channel which everyone can follow. I noticed one of my peers, my engineering manager peers, pushed them into prod. I was like, oh, do you do this often, mate? I didn't realize we were doing that sort of stuff here. And occasionally I like to keep my, my hands clear, you know, involved and understanding what's going on. There was, I think it was another scenario where I was the only person that could actually get it all the way through to production. It was one of those deadlines we needed to hit. So I just went, okay, I'll get it done. It's been coded properly, I'm just pressing the final button. But again, that's another version of being hands on in a sense. Like look, I won't be writing the code, but I can certainly help you get it to production or enable things with feature flags potentially, if that's another approach to getting things out there.

Very true. And so I don't have a code example from this, it was last week. But I have an example where I lent on some of my sort of previous a long time ago testing when I used to be a tester testing skills and there was a, a general shout out for can we have people help test this AI chatbot? So a quick sort of look at OWASP security vulnerability is reading up about how we might test that and then sort of cracked on and had a lot of fun for an hour and actively contributed to the project. And it was very hands on and it was applying what I'd learned and sharing with others and, and joining in the testing sessions and actually contributing. And I love that. So sometimes I think you can. Right? I think it's. I felt comfortable doing that. Was that anything that would be pushed to prod? No, but it would make production better because we, we were exposing the vulnerabilities, we were fixing stuff. I wasn't doing the fixing, but I was certainly leaning on some of my old skills to help expose where we could be better.

For instance, I totally get that. And even just knowing general best practices and patterns and stuff like that, that don't tend to change too much. You know, we were contributors. I'd say, say 10 years ago, maybe more than that, but I still have skills that are relevant now. I was looking through some books recently went HTML5, wow, I remember that came out and I was trying to trying things out. I was speaking to another engineer the other day when do you know all these went. Do you know half of them existed. Exactly. Have a look, have a play, see what it's capable of. It has changed a little bit, but to think technology has not evolved that much in certain parts of the web. For example, HTML 4.01 has pretty much changed at all. It's still out there and wild working fine, so. And even JavaScript to an extent. We know jQuery's out there still unfortunately, but it works so why change it and break it?

Yeah, that's very true. I think that's true of a lot of engineering we, we rediscover sometimes. It, it does make me laugh or not laugh, but it makes me smile when we rediscover as a industry things from like the 70s or the 80s.

I've been listening to the Tim Berners Lee audiobook recently. This is for everyone and the language that he uses. It's really weird because Stephen Fry's narrating, Steven Fry's talking about code, real techie topics which he's comfortable with. But hearing his voice talking about HTML and BR and stuff, I'm like, weird. But to think that all those concepts were designed in the early 90s and they've not changed significantly. Oh no, nearly 40 years. Like XP technology to sit still.

Yeah, years. I mean how many. It's very old now and still not have people discovering it.

Clean code concepts and all those other analogies that we know about good software programming, they might not be as specific, but the concepts don't shift that much. You know, even just true agile working, which could be a different topic for another day. But I just feel like we, we have learned the hard way as well as the easy way how these things really work and then we can play into that a little bit more when it comes to being more hands on.

Per se, I guess. Yeah, you can, you identified or certainly worked with some of that technology or some of the principles of the, of the technology. The, the names and the tooling might change but there's a lot of familiarity there even if we haven't been actively involved.

Yeah, I think that's very true. So I would, I'd been playing with like thinking of technical now rather than not rather than as, as a supporting sort of analogy to hands on as well. I think hands on can be very specific. Technical I found really hard in the past because it's hard to know what people mean by that and sometimes people mean technical to equal code and sometimes they mean technical to me mean a whole load of other things and I'm definitely in the lots of other things camp Because I think many, many things are technical. And it's not just a software engineer who's technical for instance. And I was having a little look around and there was some interesting definitions. There was like technical as a system thinker, there was technical is a, an enabler. So that's like the sort of engineering life cycle trunk based workflows, CI cd, that sort of stuff. And then the one that I think we were touc on now is hands on is that technical as that code literate collaborator, someone who can sort of understand. So I think there's definitely, definitely spheres of that and more than I thought of when I started having a little look around.

Yeah, it's a fair point because when I said about being hands on in, in our conversation it was like it, it was very much focused on the code part of what we do or what, what, what we're involved in. But you're right, those sort of other engineering behaviors and skills that are still technical, they're not behavioral. You're not limited yourself to software by the way. This could be absolutely design, it could be, you know, even products definitely all the other sort of surrounding roles in software engineering there are very technical hard skills in verticals. I hate that soft skills like Word. It's just cries my goat. But I feel like. Yeah, I think to my point it's like how much do we build and deliver things? Even if it is the system thinking part or the process part or the cloud part or whichever part that we don't necessarily always do on a day to day.

Yeah. So for me the being or remaining technical largely means in the role I am now either knowing what I don't know and being able to find people to support what I don't know, for instance, that's a useful one and knowing enough to be involved in the conversation. Because I think if you, if you're in a conversation that you can't add any value to then that sometimes that might be okay because there are other people in the room. But I think it's important at least to understand or even to understand enough to ask why, what if type questions to get people thinking. And you can't do that, you can't do that if you don't know at least some of the principles or design decisions or the way that something structured, even if you don't know it into that sort of real deep depth. Being able to ask those questions, I think to a group could be really important.

And just to kind of give you some more examples, this one's a bit more of a vulnerable one for me, actually, we've got a lot of program work going on at the moment that I'm managing up basically a lot of stakeholder conversations, lots of report writing, all that sort of stuff. And I've got senior people coming to me asking what's going on with this problem or what are your main bottlenecks? I might have the high level version of that in my mind, but when it comes to the technical details as to why it's happening, I don't know. And I'm. That's where I'm realizing, oh, I probably need to get a bit more hands on to understand properly what the problem is because one, I might be able to solve it with the engineer that's having these troubles. But ultimately I want to be able to communicate out where we might need some extra help because that's what those sort of conversations are meant to be about, those stakeholder updates. It's very much where are your challenges? Who do you need to help? And you know, do you know why it's doing that?

So a challenge to you, Si. Do you need to do that or can someone else maybe.

Now this is where it pushes me a little bit because I have been in many roles over my time where I have just been enabling.

Right.

I think you used the word earlier. So if I don't know, I'll take someone with me or bring them along or ask them to join in or send an update later. I don't want to put them on the spot because those sort of conversations are quite intimidating for some engineers and individuals and contributors. I'm happy to be the face, the voice, but I need some detail. So it might be just go send me your update on Slack and I'll forward it onto the right channels and I'll get them to ask us questions together if it makes it easier for you. So to your point, no, but I want to be better enabled to go back with some confidence that I know what I'm talking about rather than fluffy words. Fluffy words, fluffy words. We're fine. And that's generally got. You get a lot of in these conversations.

Yeah, I think that's very fair. And I certainly had examples, examples of depending on the conversation. Knowing a little bit more can really help because it. Yeah, not everyone, not everyone in the room needs to know, but they sometimes need to know that, you know, if it makes sense and you're not paraphrasing someone else.

I don't want to make my seniors or stakeholders to get concerned that I don't really Understand what's going on. That would be. I'll be a failure in my eyes personally. But so again this week, very vulnerable moment. I was in a big stakeholder conversation. They're asking some really tricky, detailed questions. I was like, I don't know, leave it to me, I'll find out. And it made me go and have proper deep conversations with people that were doing that stuff to sort of go, what do you mean? Can you explain it to an idiot? Because I am. And they were like, oh, you're not an idiot. But yeah, I'll, I'll talk you through it. I went, got you now. Thank you. I can go and summarize much more confidently to the other parties that need to know about this. Yeah, so I think even having those moments of vulnerability prompt it sometimes to go, I need to be a bit more technical.

Right, okay, that makes sense. I do like that. I don't know yet. Answer to questions, that's always a good one. Because you can't know everything all the time. For any question that might be amazed.

If anyone knows anything. I've got engineers that have been in the job for nearly 20 years and they don't know it all. My. If they don't know, who does? What about you? Have you got any similar stories like.

That about needing to have more of the detail?

Yeah. Have you ever realized I could do knowing a bit more X, Y, Z, whatever it might be, and acted on it? I suppose.

I think it's a great question. So definitely yes.

Some of it comes with time. I remember when I started working where I am at the moment and so much complexity, so many different, you know, so many different systems, so many different teams, so many different architectures, so many different code bases, so much so many different languages. Like knowing all that is possible, but it's not something that just happens overnight. This is something that happens with time. As you interact with teams more, you understand the services more. This is definitely a time based activity. I mean you could try and speed run it by not work, you know, doing any other work for nine months, you know, a half a year and just trying to absorb the information. But that's not. Well, it's not sensible or indeed practical. So it's definitely time and over time, as I've understood more, that helps and that's helped some of the initial conversations. I don't know how you. I don't know. I don't think there is a way to get around that. When there's lots of complexity, it, some of it just takes time and it's acknowledging in the conversations where you might be asked a question, you're like, hang on, this is week two. I, I don't know the answer to that yet.

No. But I have been distracted with many of the shop, unfortunately.

I think, I think some of that does come with time. And as you said, it makes you feel sometimes a little bit vulnerable or unsure because, like, maybe I should know the answer to this, but then also being realistic because you can't know the answer to everything.

And there are people that I work with that have been in the role for most of the organization's time. Right. So they will know a lot.

Yes.

Delicate. Very much technical detail. And I'm like, wow, how do you know that? I went time mate.

Yeah.

You know, if I'd have been in that role for 18 years, I might know a bit more.

I think that's always useful to, to remember as well. When we're critiquing ourselves. It's like I cannot possibly have the memory of someone who has lived in the business.

I think depending on your role, I. I'm looking after two teams in my role, which are two different, completely different domains. Not much over a little bit, but not much. So I really struggle to get into the detail of every single thing in that system. But at least knowing who the expert in that area. Right, I'm on it. Let me go and find out.

Yeah, definitely. I have noticed throughout throughout my career when it's involved leadership, there are some. Some conversations that don't matter if you. Let's just say if you have a. A engineering leader. I've been in a number of companies now where leaders may not have come from the domain that they represent. It's quite common, actually. So you might have a engineering manager who's not been an engineer, or you might have a head of product who has not done any product work, for instance. And I think some of the conversations at that level are perfectly fine because you're talking about people and process and quite common principles. I think when you get into a little bit more detail, it's sometimes hard to. Or you need to get into more detail or more understanding to articulate maybe something you're trying to drive forward or change. Having a little bit of grounding can make, I've seen, can make a big difference. And maybe that just means making sure you have the right people in the room and acknowledging when that needs to be the case. But I've certainly seen that throughout sort.

Of leadership career, the art of knowing the right people to be in that room because you don't want to overload a meeting room with just pointless people or not pointless but excessive. Let's say I'd rather go well who's the best person to know this? That I definitely need and ideally someone I want to learn about this with them who have got the potential because that's the other angle for me as the engineering manager. If I don't know it, but I know someone who does know it, how do they share that? Not just to me because I don't want to be the only person that understands this. I'm probably going to be one of many who don't. And do I need to invite some juniors across or some other department dependent dependent me people as well to sort of go home? You know that system?

Yeah.

Do you know how it interacts with that system when. No, I'll leave them to it. Should we invite them to the conversation just to make sure they're comfortable with what we're trying to do here. And that's again knowing the right time to bring that in without being overwhelming for everyone.

True. Give me think about something now. And that is back to your original statement with hands on. Can an engineering manager be from a career path that has not involved engineering has never written any code, Is that possible?

So I know quite a few engineering managers that have got zero contributor background but they are good people people, they are good coordination people, they are organized, they've got the right mindset and, and that's what I mean. Being in the industry you realize there are variations of this and my previous version of being an EM was literally just being a people person. You know, line managing growth, coordination, communities of practice, all that fun stuff. I'd say that was my sole responsibility. And the others around me were very similar. They're like I've never touched code in my life. Sorry, am I at my depth? I was like dude, I ain't touched any backend code ever. So don't worry about it. I'm looking after people that look after backend services. Some of the most high risk systems on the planet. Let's be honest, I don't know what they're writing but I trust him and you could probably do the same.

I think there becomes a point certainly with not all roles and I've certainly seen for instance.

Startups are very, can be very common in this place where multi skilled and multi hats and actually having an engineering environment if there's one team and there's five of you then being able to contribute in some form to what might be Happening is important. I think as maybe as that scales it gets a little bit different but I've certainly, I certainly wouldn't prefer one over the other. I, I tend to look at the value and the experiences and the contributions people can make and sort of use that and I do think it can be appropriate. No, actually it definitely. I like a mix and we've. What I've liked about where I work at the moment is it's open to any discipline. So software engineers, quality coaches, people from product or delivery. It's open and it's around the sort of the uniqueness that you can bring to a, to the sort of pool of engineering management. We now have a quite large resource of sort of technical capabilities across us all which works really well when you need help and support.

Yeah, you've made a point about the scale part as well. I think like you say in some startup environments or smaller environments, you probably going to have to be more hands on than you would be. I think organization where you've got multiple teams doing a thing because at that point it's too much for one person to do anyway. You're going to need a coordinator more than a doer. But as you say, every scenario is different. And I like your point as well that it's good to have a good mix of people. You know, I'm surrounded by some really technical engineering managers and some really great culture people, really good organizers. I'm like, we just a big group of people that have got a range of skills and I think that's what our leaders have been looking for is like we don't want clones of engineering managers that can all write code and fix stuff. We want them to bounce off each other and pull each other in if you need it. And again that's another. We're lucky to have that situation I guess in our scale. Not many organizations get that, you know, that availability. But this is why I think it's a really interesting conversation to have with anyone that's in our sort of level of role. And are they happy in that role? Because the reason I wanted to bring this conversation up with you when I was in that people mode, I missed being hands on in a sense. I missed the detail of what teams were doing. I missed some of the code access and the visibility of dashboards and stuff like that. So I looked for a role where it was a bit more hands on but not necessarily writing the code. Thank you.

Yeah, I think I would be very similar if I was only doing one thing. I think I'd. I Might find that difficult. I like to ask questions about what people are doing from a technical point of view, especially if it involves. It's like observability or pipelines or anything to do with that. Like I actually want to know. I have an opinion and rightly or wrongly, I have experience as well that at least I can ask even more so if a team is in the very early stage of their maturity journey with this, I can think, well, I might not know all the details now, but I've gone through this and I can tell you what good might look like and I can help you get to that point. So yeah, I, I definitely like to be involved in those. I think it, it's where I get my excitement as well. But I'm not then writing the code.

Yeah, I think there's a little bit of that with me as well. I like that I can bring some advice or some thoughts. I don't want to come in with all of them. But say, do you want to hear my opinions from experience? Why are you spending time on this when it could be that. Have you considered X, Y, Z? And when you're talking about scalability and reliability and all the other ilities that we tend to butt kit into non functional requirements in our world, they're not functional but they're bloody important. Can we make sure they're high priority? A lot of engineering teams don't worry about that, especially in their early days. When you talk about maturity, it's very much like build a thing, ship it, build a thing, ship it, build a thing, ship it. What about your tech debt? What do you mean don't worry about it? I'm like, where's your dashboards? Ah, we don't need them. We've got alerts. Oh, we've got so much to learn, haven't we?

Yeah, very much so. I was curious, I feud. I had a little look around, it's a bit around engineering manager archetypes and I had a. I found some details and this prompted. We're hiring at the moment, we're interviewing and I was chatting to a candidate. Not even the interview Sarah, but just about. They're more curious and I think their first question is what style of engineering management do you have? And I was like, of course. Because it's so varied.

And when I had a little look there was definitely the, the technical, let's just say engineering manager. So broad range of expertise, hands on as well as writing code, technical discussions, maybe, maybe from a principal or staff background, that type of architectural decision making and Then you've got the team sort of archetype grows a team, high performance team. So it's about spending time, it's the recruiting activities, it's the retention and the growth, that environment of psychological safety. And then there's process sort of orientated, which is that I say bureaucracy but maybe not so much. It's like the management style of things, navigating outcomes, organizational stuff. And then there's the product focus, which is an interesting one, not one that's considered so much. And that's. That was around like the why and the what rather than the how, which is the team sort of answer. And that's. And then. And this variant spends much more time on like the customer research, market building. And you could argue that, oh, is that the role of a product manager and. Or a product owner. And in many cases the answer would be yes. But also I've seen it shaped that total technical aspect, design, market research shaped into an engineering manager role as well. So there's certainly a lot of different definitions out there and when I look at them I say there's parts of technical or hands on in all of them, but described very differently.

Yeah. What we'll do, we'll get the link in the show notes for this as well. For anyone that is following along because I think just to read it in your own way and maybe do an assessment. So I go, where do you think you are if you're in an engineering manager role? I feel like you say I'm in a lot of those categories, unfortunately just a product because I'm lucky to have a product manager. Not all of them, but there's elements of each of them that I do. And I think to your point, in job specs you tend to get a lot of this stuff. But then when you go into the interview you're sort of going, which bit is most important? All of it. I went, okay, which was most important? Because you can't go, I've everything. Oh, I need someone to be all over everything. Okay. You're not going to get good contributors that are also firefighting, you know, stakeholders, whatever it might be. I like the variety though. I think it's what I want to get a point here. I like to be able to do a lot of that stuff, maybe some of the products as well. Because like you say, it's not something I tend to do, but I like the idea of why are we doing this? Yes. Bringing some ideas to the table. As an engineering manager, it might be a product solution, but it definitely be a technical Engineering solution that would improve the product for the future. You know, I've worked in a. I think we called it like the AB team or the MVT team. That was phenomenal stuff to do. But the technical. Technical implementation was not the best. So I had to zoom out a layer go, right, how do we design this better so that others can do this? How do we roll this out for other platforms to start using it? Because at the moment it's one team doing everything. So I like the fact that gave me that accountability, I guess to come up some ideas.

Yeah, I like that as well. That's very neat.

Where do you find you sit in that archetype.

Oh, that's great. I don't know. Largely because I. I struggle with putting myself in a box. I don't like it.

I like doing boxes.

Yeah, I don't.

Nobody puts baby in a corner.

Boxes aren't fun. Fun for cats.

Let's sit down and lie across all of them.

My cat loves a box. She would. Yeah, she would be in a box all day. The. How do I say it? Just thinking about it.

Where's your preference out of them?

Okay, preference. That's a good question. So I'm always drawn to the people side. I think that is a. A focus that doesn't necessarily mean line managing. It might mean creating an environment for people to be successful and so it is around people. I cannot stop.

Being involved in like process. And by process I mean helping the team develop and mature rather than sort of bureaucratic process. Let's be continuous. Yeah, continuous improvement. That's a much better. I sounded like I love spreadsheets, which is not what I process me the. I think a bit that I've. I've got a lot of fun with in the past, but not one that I've had a great deal experience is. Is leaning towards the product side largely because we've had excellent and supported by product people. But when. When we haven't or when the business hasn't. Leaning into that as an engineering manager can be really interesting. It's a. Definitely a different side. It wouldn't be where I would naturally gravitate towards. So I think for me, if I lost some of the skills that I've developed, I think that would be detrimental to who I am because I'd love learning and it would feel like there's a. So learning all the time is important. So I guess it's. I would sit in more around the team focus stuff and the technical. So team technical would probably be my sort of gravitation If I had to. If I had to pick. And the team means people.

Yeah. And I think I feel safely in that zone. Like the people and team part, a little bit. The process part. And that's why I like the idea of product. I just. Because, like you say, we're very lucky to be surrounded by amazing product people. Anyway, I don't need to. But when there are times where they go, they're busy, they're stuck out. Can you help? Cool. Give me a chance.

Yeah.

I love this.

Go. Yeah.

Yeah.

And would it. Would I feel the same if that was all the time? I don't know. Maybe. Maybe, Maybe not. I have a feel. Probably not, but I do. Like, I think it's just as we talked about in the learning. The learning episode. It was just around that. Exploring new things and being able to contribute and. And being able to have a voice and an opinion and experience to share as well.

Two angles for that. For me. Yeah, two. One is a different thought process because I have my process and I'm sure it's completely different to someone else. And when you see other product managers or owners that are wired differently, but amazingly, I'm like, oh, I need to try that. I'll see if I can get my head around it to start with. But then there's also the fact of the. I don't need to do this. I could lean on these people to find out how they do it. They are the experts of their craft. I'm. I'm apparently good at what I do, so learn from me if you want, but it's just like, can we partner up a bit more and do these things together? So it's not like there's a single point of success. We can actually share that out a bit more and make sure that we've got co pilots in a way. You know, we're doing this together.

So with thinking of sort of the people aspect and like, career progression as it was, how does that look like for you? Let's just. What is the highest. Highest level is the wrong word, but do you have staff engineers, principal engineers? What's that sort of top tier before you get to, I guess, like the management side of things or the leadership side of things.

Yeah. So most of the time it's principal engineers. That's the last touching points to be actually on the contributing mode.

Would they be. Would they be on the same sort of peer level as engineering managers?

So some would say yes and some would say, I don't know, actually, because I've always found this is the cut point for lead engineers that I know or senior twos potentially is like you either go down the principal route or the engineering manager. Yeah, that feels conventional route for them. But then we're also talking about squiggly careers the other day and went what about doing something completely randomly different? That's fine. And I've also seen well, you're really strong at back end. What about full stack? What about front end? What about qa? What about platforms? Whatever. There's, it's, it feels like we're getting to that place in the world now where yes, unfortunately it's principal staff em or something completely different. That's it.

I'm, I'm curious because thinking of the hands on part, have you had any, any of your most senior engineers who have wanted to go into engineering management as a, as a squiggly sideways or upwards, whatever the auction structure is, be worried or concerned or have questions around what they might lose and what they might need? I'm chill.

Not in my current role but previously I've definitely experienced this a lot and I, I feel, feel like they even get to a ceiling at some point. They're in. I don't really want to lose access to the code and the contributor. I want to be in it. So can I just stay there and go wider instead? You know, I don't want to just limit myself from the domain I know now I want to go and try another domain instead. And I think it's because they don't want to be pulled into all the pointless meetings and all the bureaucracy and the people stuff. That is not necessarily their strong point or their happy place if I'm honest. They don't mind it. They'll do it if they have to and they definitely love their people. But putting in development plans for their individuals checkpoints every one or two weeks, that's not what they want to do. They love writing code.

Yeah, I, I said this is, this is what I was wondering Link, especially referring to the engineering managers. Is there, there will be some people who, you know their career started with a love of code and that may never go away. That's what they want, that's what they get a lot of value out delivering value to customers, end users and building products and writing code and then if that's less so with management and leadership, is that a change in focus for some individuals? And I guess the answer is yes. But I'm just really curious about with that especially if I can't imagine the answer is.

Everyone just wants to still keep Writing code, otherwise you wouldn't have people in leadership position. But I also wonder if people sometimes feel that that's their only next option and maybe not as enjoy it as much.

I remember when I changed from engineering to management and my boss at the time said congratulations to size promotion, to the whole Slack channel, whatever it was. And someone went, is it a promotion? I went, oh. And they were right to ask it because I've got to change my complete skill set. You know, these are whole new. I'm starting from fresh almost. I just got some technical grounding to understand what's going on. I was like, it's an interesting analogy where managers aren't necessarily better than engineers, let's say, because they've got other skills.

Definitely not.

So no. And I, I'd always challenge that. I know I'm not, that's for sure. But there's some people have that kind of perception that went, oh well, I'm so strong engineering now. I want to be a manager. I'm like, okay, you do realize they're completely different skills, right?

Yeah. And I'm just curious because like we're talking about do we want to still remain hands on, but we're also, I guess by that answer is we're also asking are we okay not being so hands on and by doing so, what new things do we need to learn? So we're dropping a little bit of one to give us space to learn a little bit of another and, and being okay.

And that's where I'm conscious of that point is, for example, I want to go and learn a new piece of the tech that we're actually using. The engineers know this stuff inside out great. Or generally do. But I want to understand what they're talking about. Going back to some of the stuff we were talking about earlier. If we're talking about, oh, we have a real problem with this dependency, this package, blah, blah, blah, might, what are you on about? Right. Give me an hour. I want to go and watch some YouTube videos or something just to understand what you're talking about. Then I can come back with a bit more prep and understanding of what you're talking about. But I don't need to go and do it. I just want to understand what you're talking about. And I think I quite like being that space. I can just go, I know how to find out about this. I know where I have to to ask. And I don't need to get into the detail to fix it. I just need to enable those people to be solving the Problems quicker or more efficiently.

So my last role I was, I chose to be an individual contributor. Unfortunately after a period of time I then had a leisure role but I chose to be an individual contributor and the role before, before that was, was leadership. So it sort of went leadership. I see leadership.

You bounced around.

Yeah, bounced around a bit. And so it's, I think it's very fair to say that I joined that role and was very confident with certainly the discipline I joined. But also there was lots of new stuff. Not too familiar with some of the cloud architecture, not too comfortable with some of the pipeline work and I had to really learn and then own it and do it and be very comfortable with it certainly around observability for instance. Building up that knowledge set was very new to me and I found it really valuable because I can take that in that examples and experience into my next role which is a bit more leadership and apply that to teams. And I wonder if I hadn't had that IC role in between the two, how would I have learned it? I could have read about it, I could have maybe done some work with the team but I don't feel I would have had as deeper knowledge. And I don't know where I'm going with this, but I have enjoyed the leadership, IC leadership because it's enabled me to skill up a bit in a way that I don't think would have been so achievable if I'd kept with the leadership roles. I'm not sure I'm suggesting to everyone listening that's what they do, but maybe it's around if you're, if you want to stay a little bit more hands on. It's about finding opportunities and ways of working more closely with the team to be able to do so.

Also, don't limit yourself to your job, your day job. I, I find a lot of technical learning I do is in my side hustles. I'm, I'm building an app right now for the whole Pell stuff. Right. And I wouldn't know where to start with Django and you know, all that sort of stuff but luckily I've got a few peers I can reach out to and going how do you do that? Okay, cool, all right, I'm going to work it out or ask GPT if I have to, just to support me. But yeah, it's, it's knowing that how do I learn this with real world examples? It doesn't have to be a profitable product or anything. It's just like meh, I want to build A thing and see if it works.

You clearly have more time than me. Cypher side hustles.

I don't know about that. I just get distracted too quickly.

That's a really great point though. It doesn't. I was focusing very much on work and it doesn't have to be. Yeah like you can be hands on, you can remain hands on and it doesn't have to be in your job or your day job.

And you could also just sort of go look, can I shadow you or reverse mentor someone in your organization to understand what they do on a day to day basis to give you a bit more understanding. It's, it's not taking you away from your main job but if you can find like half a day, a fortnight or something to kind of go, kind of come and shadow what you're doing so I understand what the hell it is. I'm sure they'll be of course. You sure? Yes. Yeah. I really want to understand and learn your stuff.

That's a great point as well and a good, good thing to take away. I might, I might give that some thought.

It might be an interesting question to pose to an engineer. Like can I just watch what you do? I love it without judgment.

Why do you want to know? Because I am a geek at heart.

Yeah, I guess it could feel a bit weird but I think with the best intention could be well received. Nice. I like that.

And I drive to a lot of my engineers to do similar. If you want to learn a thing, just ask someone who does know it and I'm sure they'll be happy to share.

I'm gonna segue ever so subtly into the last episode so I and it will be related to today. And then as I mentioned I was going to Agile Cambridge and it was very excited. I was mentioned about, I think you said, are you interested? Like who are you excited to go and see? And I said yeah. Simon Wardley. He did a keynote. I've seen lots of his works but I knew it was going to be cool. I didn't realize just how quite good it was going to be. And I'll share you a link to the video and the audience if they're interested. But I had a aha moment throughout it just towards the end and that was the difference between learning and excitement. So there are some things I learn I need to learn. I'm okay with learning and I'm happy that I've learned them. There's some things I learned that truly excite me. And there was a point in the talk where it just spot loads of ideas and I could feel my brain being very energized. Not just learning but it, but excited. And I wonder if that's also when we're thinking about like the technical things. Are we, when we say are we miss the hands on stuff, could we actually be saying I miss the things that excited me? Like is that also.

I like that point. Yeah. And I think that's what got me to tech in the first place. I like the excitement of making a thing go live. And I, I have distanced myself from the intricacies of how that works now, but I still love being part of that big switch on and just seeing everyone going, oh my God, oh my God, it's gonna work. It looks like it's working. Oh my God, it works. It's like, don't be too surprised. But I know what it's like and that that energy, it sucks out of you, it comes back and the glimmer in the rise. And I think you're right. It's just I missed that part. I think that's why I get back into the more delivery minded tool of being in that role.

And I've only just on this conversation made that connection, which is why I love having these chats with you and because it, it's an opportunity to reflect. But I wonder when I might have people who say, I miss, you know, I want to be more hands on. I want to still be. I miss that. It's like, what do you, what do you miss? Is it the memory of the excitement about what you did and is it related to the thing that you think now is missing or was it something else? Like. And the answer may be I miss coding. And that's the. But it might actually be something else. It might be, you know, that the feeling of the work breaking things. Yeah.

It doesn't matter what it is, but I think it's a great question to ask anyone whether you feel like they've lost that oomph, that excitement, you know, what do you miss from your day job? What would you like to do more of? And if they kind of say, oh, I don't know, I want to write more code, I went, go on then I'm not going to stop you. If you know how to do it, try it.

Yeah. And that's. Yeah, especially that, that I want to be more technical is definitely, I think a, a question we ask ourselves, ask each other. People ask of themselves as well in terms of what that might look like, especially as our roles change. That's A good question to ask questions.

You ask yourself, not just the people around you. I think definitely, yeah. Go on then. What's the one thing you remembered from today that you think, oh, yep, that's my next action.

That's a good one. I think it's so for me it's going to be thinking through the conversation that we've had around hands on and technical and seeing if I can distill that in a way that I could articulate it to others because it is a conversation that, that I have and have had and will continue to have with the people who I look after. And I think, I think I've been able to formalize my thoughts a little bit more with you today. Now clearly I could just send them our podcast, but I don't, I think that's, I, I don't think that would work. So yeah, my action is just to, is just to, is to go through some of the conversations that we had today and take that. And also take that reflection back in terms of what do you love and is it hands on technical work? What's that look like now? Does that change? And I think that is going to be some of the conversations and actions I might, might take away from this. I might even go and write some code. Sigh.

I can give you some stuff to play with if you want. What about yourself Unfinished. So there's a couple of things for me. One is I'm going to look into the archetypes thing a bit.

Okay, cool.

See how I fit in that nice five factor thing. I love five as you remember. Well, no, and I also, I want to ask myself what do I miss? What excites me and have a good think about it because sometimes it is just, I just miss breaking things and so fixing things obviously. But the fact I've tried something, it didn't work. Work out why and not get AI to do it for me because I think that's the track now is like help me fix this problem. Nope, I'm doing it myself.

And I'll, I'll add a follow on to that. Question is, and how much of that do I need? Because I, when I did the, the testing of the app, did an hour, loved it. Do I need to do that as a day job all the time now? No. Did I get immense amount of enjoyment that will keep me going for a while for that hour? Yes. So I think that's a good follow up question as well to yourself. It's like how much, how much do I need? Yeah. Because sometimes people think I'M not you in particular, but I. I know myself. I could imagine that. I love doing that. Back to my previous example, I loved unicycling. Do I need to do that as frequency as I used to? No. Do I need to pull it out of the shed and have a ride after this chat? Probably yes. So, like, just as a reminder, I think sometimes you. It's just small parts can often be enough. Right.

Just totally. And just little bits of joy, you know, when I'm not gonna get deep. But I think just having moments, being that was fun, that's what I want to be doing more of.

Nice. I will send you a picture of.

The nice cycle after this and we will definitely get that out there somewhere. That might be the artwork.

There we are. That's. That's the. That's the image for episode three, A unicycle.

Oh, I love that. Really enjoyed that, mate. So what I'll do, I'll. I think what we'll do, we'll ask our listeners for some feedback what they think and get some thoughts from them. They can reach out to us on LinkedIn. You are Neil Younger. I am Sideshowling. You should be able to find us. And we want to keep this conversation going. We want to make sure that it didn't stop with us. We want to get other people in the community talking about this. So if you've got some thoughts, share it. Tell a friend, ask them what they think and just get in touch. We'd love to hear what you think. Yeah.

We're just two people. Some views. Views, some. And some of those views will be wrong and different to other people. So I. Yeah, I think just as. As I've sparked in my brain and sparked ideas just chatting to you. Sigh. I hope that we might spark in other people but also from that feedback that we might be able to like adapt but also generate more ideas for future sessions.

Absolutely. And if you've got any thoughts on how we can make this podcast any better, love it. Bring it. Yeah, I mean do our own reflections next time.

Don't have the podcast cast. It would be a difficult, a difficult piece of feedback to see.

But we will, we will be open to the feedback and we are in all the obvious apps, Spotify, Apple, YouTube, blah. I'm not going to go down that route, mate. Been pleasure as always. Look forward to the next one.

Yeah, thank you so much appreciated. It's a good one today. Oh, my turn next time.

I know.