Latest / Complexity Cogitators Podcast / #011 - WTF is an Engineering Manager
Transcript
- Joakim von Prónay: What does an engineering manager actually do? As it is a very common role in organizations, should it not be relatively easy to create a role definition and a role description? In this episode, we will at least give it a try. And that is what we are talking about today on complexity cogitators. My name is Joakim von Brånaen and together with Marko Ahumada-Juntunen, we try to make sense of organizational behavior. Michael. Thank you for listening to the whole episode. If you enjoyed the conversation, please consider leaving a review and sharing the episode with at least one other person who you believe will also enjoy it. It truly helps us reach more people. And if you don't follow us already, please consider subscribing to our Substack on complexitycogitators.substack.com. And if you have a topic that you want us to talk about, drop us a message. We are more than happy to receive suggestions. Marco: You're welcome. Joakim von Prónay: Good to see you. Feels like it's been a while. Marco: Yeah, we've had a bit of a break, haven't we? Joakim von Prónay: Yes, life came in the way. Marco: tends to do. Joakim von Prónay: It does. It does. But a few weeks ago, you actually dropped an interesting question. I don't want to click the explicit button on the, when upload the episode. So I'm going to say, what the hell is an engineering manager? Was a question you post because you were in some interesting conversations at the time. And this question at least lingered in the back of my head. Bye for now. Marco: you Joakim von Prónay: So why not talk about it today? And we actually put three things together each and we brought those. Do you wanna start to share your three things? Marco: Yeah, I can do that. And then let's talk a little bit about context. three things that I brought are... ⁓ engineering manager or managing engineer. you will find in organizations that they think differently about this role. And why is that and how does that? And the second point I brought is role fetishism. Why are we so concerned with role definitions? And do we expect them to be portable between organizations when it clearly seems to trip us up? And finally, something for the practitioner that ⁓ I've used in multiple locations, kind dynamically or systemically defining a role based on the individual and their understanding of their environment. So I have a little or framework or whatever you want to call it for doing that, that I could share. Joakim von Prónay: Yeah, that's quite interesting. the three things I was that the manager is the first layer of accountability for other people's work. And... Furthermore, engineering manager is no longer the expert. And the third thing, the engineering manager is a people person. Maybe perhaps a hidden question mark in the end there. Marco: The punctuation is important. Joakim von Prónay: Exactly. ⁓ ⁓ of us, ⁓ have quite a lot of experience working ⁓ different engineering managers in many organizations. So I find it quite interesting to start with what said, the whole engineering manager or managing engineer. Because the role is viewed so differently in different organizations. Marco: so that's a segue ⁓ me to take over, right? So smooth. I feel very smooth right now. So yeah, one of the observations ⁓ I've in this topic is that you will in different organizations that senior developers have been promoted into some kind of engineering manager position. is... Joakim von Prónay: Yes, that was a segue. Marco: a lot of formal management ⁓ terms of bureaucracy and administration, which is very different from engineering work. In other organizations, you recruit for a management profile or background to manage an group of engineers, Given that these two individuals would have different backgrounds, they would approach this role differently, but also have a different kind of empathy, I guess is the for the of the team. then. ⁓ I called the former a managing engineer. who's been promoted on the basis of being a good engineer into role of responsibility and the engineering ⁓ manager. managerial disposition to group of engineers. Joakim von Prónay: Yeah. And I realized now when you, when you give this explanation, because I share your experience here, right? I've seen, I've seen both. And realized that all the three points that I brought can be summarized by your, statement engineering manager managing engineer. I am of the opinion that it should lean more towards the engineering manager side of things. because the managing engineer is still the expert. The managing engineer is still incredibly uncomfortable in being accountable for other people's work because they are also doing that work themselves and are still an expert. well, I'm not to draw any... large brushstrokes here and say that the managing engineers that I've come across in general are not people person, people people. So I'm going to leave that unsaid. But But is ⁓ the case? Why so many technical organizations tend towards promoting managing engineers? Essentially, it's the Peter principle, right? You promote people into incompetence, which was written as a joke. ⁓ I remember when, but a long time ago. Marco: It's an excellent little book. is. the Peter principle was the first thing that went through my mind as well. in lot of organizations, like, isn't the stereotypical ⁓ career path organizations? You do the operational work and If you're proficient enough in it, then you would make sense to have as a manager of other people doing that work. in a way ignores that effective management or leadership requires a different kind of disposition probably than someone who's been doing work for a long time. So I think part of it is tradition, right? So if you've been doing this work for long enough, you, in some organizations probably are perceived to deserve such a And others, maybe there's a lack of other developmental paths ⁓ within that sort of Joakim von Prónay: Yeah, no, I agree. I agree. Marco: And I'm certain there are cases where growing up to be a senior contributor in such an organization requires developing your leadership skills. So I'm certain there are ⁓ where that transition works well and makes sense. just to be nuanced and stuff. Joakim von Prónay: Yeah, absolutely. and one the points here that I want to emphasize is that I ⁓ see engineering manager or essentially the ⁓ first of middle management as the first layer of accountability for other people's work. And I think this is where one of the hard parts, I would go so far as to say, this is one of the most difficult of being a middle manager. in any organization, because you have to be accountable for the work of other people. What is your take on that? Marco: I think I like to have you elaborate on that first, because... Yeah, I want to hear more about your thoughts on that first. It resonates, but I need some more seeds. Joakim von Prónay: Okay, how do I elaborate? Maybe my brief take on the difference between responsibility and accountability. of the things is ⁓ can be delegated. You can give someone the responsibility of doing certain thing. That's perfectly fine. You cannot delegate accountability. Whatever the result and whatever the outcome is, it's still on you. you are the accountable party. So that's one thing that the engineering manager or middle managers have accountability that they cannot delegate away. And I think I would need some infusion from your side here to continue to elaborate my thoughts. Marco: Yeah, because you're on an interesting track here. The age-old the semantical battle of is responsibility and what is accountability. We'll find different ways of ⁓ defining that. Maybe I'll share my interpretation of what those words mean and then we'll see that's enough to ⁓ of how close we are. ⁓ so to accountability is well, head going to roll if this goes to not as intended, right? Joakim von Prónay: Yeah, yeah, let's do that. Exactly, the single ringable neck. Marco: Yeah, the single ringable neck, that's good. Or the buck stops is that phrase as well. And I see accountability as something that is given. I think that accountability can be transferred if it's made formally and explicitly. I assume what you have ⁓ bureaucratic hierarchies to delegate power and culpability. then responsibility is something, so if accountability is something that you give, then is something that you take. So ⁓ it a response that is more or less responsible to your to work context. So if you observe a problem, then you might act on it, take responsibility. so respond to a problem that you observe. accountability and responsibility overlap, but generally. I assume that development teams are responsible for solving problems within their domains, keeping their up and But if it's not, then going to sort of get the formal blame for it? That's kind of Simply put, the way I look at those two things. Joakim von Prónay: No, I think we are somewhat aligned. And I know it was brave of me to bring up semantics when I have Marco the word guy in front of me. But no, that's helpful. Absolutely. Marco: I know. So how did you put it? The first level of accountability. Joakim von Prónay: Yeah, the first level of accountability for other people's work. Marco: which is the engineering manager or the middle manager. Joakim von Prónay: In this, well, in this sense, we started this conversation talking about engineering managers, but in general, middle management. Yeah. So I, then I see the engineering manager as the first, the first level of meaningful middle management. Marco: Is it middle management? I'm not sure I think it's middle manager or I misunderstand the term. ⁓ Joakim von Prónay: Is that, is that, is that fair to say? Middle manage... Okay. So when I speak of middle management, I essentially mean everyone in between the executive board and the individual contributors. That to me from just from a conversational point of view, that is middle management. Marco: OK, I've always thought of it as a middle manager is someone who manages managers. So a grand manager, if you will. But maybe I've completely misunderstood the term. possible. Joakim von Prónay: It might be that I'm using it completely wrong as well, but for the sake of our conversation, I say middle management, I include the first ⁓ of a person ⁓ individual contributors as well, when I say middle management. Marco: Okay, well then the statement is less surprising to me. Joakim von Prónay: Yep. Okay. Marco: if ⁓ I some energy that statement then per your request, the question engineering manager and managing engineer becomes a lot more interesting if you start embedding accountability into that role because suddenly you have someone who is both a contributor and accountable for around them, the or sort of the work those around them within the team. And that creates interesting power dynamic. ⁓ and suddenly we're about What kind of effect does that have on what that group produces if one of the, if the manager is writing code and even reviewing that of others ⁓ whatnot. And what kind of pressure does that put on the managers of being also an effective contributor in that context? Not an simple ⁓ question, which makes me lean into preferring. engineering managers not to have an IC responsibility as well. Joakim von Prónay: Yeah, I agree. I agree. This is also why I view the managing engineer type of role so, so difficult in organizations. Because it requires very particular people to do that well. Marco: I mean, the successful examples, if I can use that word, the examples that I like from my own observations is there are like individuals who have been senior engineers and promoted, but been freed from any sort of operational engineering work. They might be involved in problem solving on a high level, but in general, they're free to do the management stuff. primarily, or that's the expectation of them. Joakim von Prónay: Yep, I agree. I agree. But as you said, as you said as well, organizations have a borderline fetish of over defining or defining roles through intricate role descriptions. And when that is the case, especially when the are more towards the managing engineer or the first level team lead or like some sort of expert with management responsibilities. then those are the situations where I've seen it. work less than optimal. Marco: general, there are exceptions, I consider the managing engineer to be an anti-pattern. So less than optimal. Joakim von Prónay: Yeah, yeah, I'm nodding in agreement here. Marco: ⁓ yes, the audible note. Joakim von Prónay: Yes. Marco: let's a quick bit of context because the reason I brought topic up was I was at Network Coffee with good old colleagues and we discussed all of stuff in tech Stockholm stuff. And of the topics that up was phrased something like, how do you do engineering managers in your organization? Because we can't find a single way describe what it is they do in organization. And it was a very interesting conversation where... of the ⁓ conversation was around what does an engineering do? Why is there such a width of interpretations? My feeling after that was why do we focus so much on trying to describe this role upfront? This is a pattern that we do generally. So seems to be a perception that the role engineering manager exists in so many organizations that is kind of a standard and thus it should be well understood, but it's not. What an engineering manager does varies a lot between organizations. and even within organizations. the response to that seems to be to narrow it down to a role description. Sometimes thinking that, okay, so this same role description, if we can make it apply across our organization, then why is it not portable across organizations? ⁓ And I think that kind of thinking is bit of a mistake. more harm. It us up more it helps us. Joakim von Prónay: No, I agree. And I think the difficult part here is because the we to think is through deductive reasoning. Right? Especially engineers. If you have an engineering background, ⁓ that's you like to do. And then you should create rules that simply apply and then you should execute things in order and then the results will happen. So that's essentially the logic that you're... you're describing here. We should be able to define a role, what the responsibilities and accountabilities are, what they're supposed to do. then when they do that, they should be successful in executing their role and their responsibilities. but as you share. When you talk to people and what we see in different organizations is that the engineering manager role is never performed one way. It's always performed in as many ways as there are individuals with the title, essentially. because well then I can use the fancy words I recently wrote down in my little notebook as well because it is also much more about inductive reasoning and abductive reasoning because things are not so linear and straightforward. need to... Well essentially we go back to strategy here, right? Marco: Mm-hmm. Joakim von Prónay: What are people doing? ⁓ bring people together to do roughly the same thing at roughly the same time for roughly the same reason? And so on and so forth. That skill is not... ⁓ It's very hard to pre-define the role that is supposed to do that. Marco: And why do you think it's hard? Joakim von Prónay: Well, because the world is It's not predictable. It's the same old and much better to the other way around, To ⁓ the outcomes. What do we want to achieve? And then you work backwards from there. I think that's a much better way to define an engineering manager role. Your role is to reach these results to the best of your ability. How you do that is completely up to you. And also, if you are unable to achieve those results, which is very, very likely, then you need to also engage the organization in a dialogue on what results can be achieved and why those are better results and so on and so forth. If that makes sense. Marco: I mean, it does, and it's very similar to third point, which is the I like to... make sense of roles, it is through a similar process. So what are the desired outcomes? What is this role meant to achieve, not what is it meant to do? But refresh my memory ⁓ abductive thinking and inductive. How ⁓ does play in here? Because these sound like fancy words that I would like to use more. Joakim von Prónay: Let me down. Yes. reasoning is essentially you start with a general rule such as if A equals B and B equals C, therefore A must equal C. ⁓ that's deductive That's what we train in when we ⁓ become essentially. lot of deductive reasoning. We deduce what to do based on general rules. And this is also Marco: Mm-hmm. Joakim von Prónay: This is also similar to a general framework approach. So if you have a framework, then you try to fit the organization or fit the practices into the framework and then you follow the steps and then you should get the results that are indicated by the framework. That's simple linear and deductive reasoning approach. ⁓ reasoning starts with a specific observation and then Marco: you Joakim von Prónay: finds a pattern to create a general rule. So essentially goes backwards. And here the interesting thing inductive is that whatever general rule you create based on your observations know that it's not the whole truth. It's going to be wrong and you will have to adjust. But that's very similar to how I work with organizations. You come in ⁓ You're in a new environment. You start making observations and you see how are people doing things here. And then you try to make some sense of it and try to apply the general rules that you create out of these observations and see if it applies in the next situation. If it does, good, good, cool. You're onto something. If not, what tweaks do need to make? Marco: you Joakim von Prónay: So it's based on individual observations and then you try to create, you try to extract the general from the particular. And deductive reasoning is the opposite. try to ⁓ the particular from the general. And thirdly, then you can comment. thirdly, abductive reasoning starts with ⁓ effect or an outcome or a result. And then you work your way backwards to try to explain why happened. And this is the same thing. You're not going to find one ⁓ single truth like, this is exactly the reason why things happened the way they did. Which is also an interesting point that I thought about earlier when it comes to complexity. Because I recently shared some feedback that I don't see in a complex environment, you can never deduce cause and effect. Even in retrospect. But what you can do is you can abduce it. You can use abductive reasoning to come up with a reasonable explanation to why the cause and effect pattern is the way you think it is. But this is the same thing. You know that it's not going to be the whole truth. It's going to be the most reasonable explanation that you can find. Marco: So kind of, we look at this chain of events, we can identify some dominant factors maybe, or some significant factors to why this happened in the way that it did. But... Joakim von Prónay: Yes, exactly. And in the end, you can say it's very likely that these are the explanations to what we just saw. Marco: Yeah, we also accept that this is not going to be the whole truth. Yeah, okay. Joakim von Prónay: And this then, to connect it back, these skills are incredibly valuable when it comes to navigating organizational complexity and executing strategy, and especially for engineering managers or middle management. Because it's very unlikely that you're going to get the desired results simply performing a set of predefined tasks or duties or responsibilities. Marco: With that little library of ⁓ different kinds of, of reasonings. Would you like for to walk through how ⁓ I work with these and the context in which I've used this little practitioners toolbox. Joakim von Prónay: Yeah, please. That would be nice wrap up. Marco: So roughly this is the process and the context I use it you I've used this in is that I've coached Consultants on their ⁓ and IT and ⁓ they're not engineering managers some of them ⁓ this is me or product managers and that kind of stuff. So I've applied this Different context to different people the way I ⁓ out usually is... Here's the thing, there's an interesting tension between a formal role description. So we try to define upfront what this role is supposed to be doing. And then we plop that person down the organization and expect them to be doing these things ⁓ reaching these results. The way to go about, ⁓ if look at the other extreme end is we take this individual based on their perspectives and... ⁓ predisposition and we plop them into the organization and see what do they do how they understand this responsibility or accountability. So they have a mission or a frame and then they sort that out for themselves. Now this of course is a theoretical case and it's not likely to happen but... Let's accept that for a bit. way that happens usually is ⁓ see problems ⁓ and in ⁓ my context in my unique way based on my experience. And I choose how to act on them if I have the mandate or expectation to do so. a lot of these things are hard to define upfront. So we like to leave it up to individuals to try to identify these things for themselves and sort of kind autonomously do the things that they're good at and assume that this is for the best of the organization. the way I try to ⁓ this process up is I take the individual, the consultant, I've done this for myself as well and I ask them, okay so ⁓ what is your purpose in this role? Why do you think that you have this and what does it give you? And then I put after that I ask so what do you think the expectation of the organization is on this role? So I kind of take the internal motivation and put it next to the external expectation and motivation. And then okay so and the next step is to try to figure out beneficiaries. So who benefits from your work? So these are the relations around this individual and their role. And then for each of these I try to have state so, and what is your delivery to them? How do they benefit? So what are your goals in this context? And the next part, I asked them, okay, so what makes it difficult for you right now to achieve these goals? are the constraints of this organization What can you observe right now that makes your job harder to reach the goals that you've explained? And then based on that, and who can help you with that? So what is your support system? What functions in the organization do you benefit from? And that way I draw out a map of relations and where kind of energy and influence goes. And this is usually a pretty helpful way of trying to figure out. So what is it that I should be doing or what do I need from others? Joakim von Prónay: Yeah, no, that sounds very, very useful. But then it's hard to contrast that against the the formal role description that exists in organizations. Marco: Well, you can ⁓ take parts of the role description and put them into framework, because they after all, expectations on what you're supposed to achieve, hopefully, and not just what you're supposed to be doing. Joakim von Prónay: Hopefully. Marco: and ⁓ it's a lot more visual than can make it sound ⁓ here. Maybe I'll put it down somewhere and give a link. Joakim von Prónay: I that's generally a good statement. It's hard that things are usually more visual than you can make them sound. So Marco, have we answered the question, what the hell is an engineering manager? Marco: I think we have. think the answer is it depends. Joakim von Prónay: I think so too. Marco: app that we don't think that it's a managing engineer that should be doing that. Joakim von Prónay: Yep, absolutely. And as I like to say, it's better to be roughly right than precisely wrong. Also applies to role descriptions. Marco: It's very good mantra. Joakim von Prónay: Cool! Michael, I think we are ready to round off. Marco: to seem that way. Joakim von Prónay: Thank you for the conversation. Marco: Thank you and until next time. Joakim von Prónay: Until next time, ciao. Marco: too.