¶ Intro
Hi, everyone. My name is Patrick you, and if you want to be a tech lead or engineering manager, keep listening, we cover the responsibilities, the accountabilities, all the abilities, and even how you can grow into that position from a developer or software engineer position. Joining me today is Patrick, wha who's been in the industry for about 20 plus years in various roles CTO consultant and even Tech lead? And he focuses now on mentorship coaching and trainings, which is
really cool. After all his links to socials in the description below. He also has a newsletter Other which I follow level up, it's there, check him out. And with that being said, enjoy the episode. I was wondering because I was going to go through this with regards to the trainings that I did because you and I met about
¶ Different problems in coaching CTOs
a year ago and I followed one of your Tech lead trainings. But since you also have that coach role for ctOS, is there kind of a commonality in the problems that they face or are struggling with that? You've noticed kind of a trend throughout not so much. So a lot of this has to do with the scope and roll. So, you know, a lot of the technical leadership challenges will be the same. But a CTO is going to have very different sort of challenges.
A lot of it has to do with sort of organizational things, right? So, like, teams, this might be about hiring restructuring, or, you know, about more senior leadership roles, what type of skill sets or, you know, maybe they've got somebody, but it's not quite what they need and like trying to navigate through that. It's often about the relationship with product and their CEO. So quite different products, quite different set of problems
and because it's like ctOS. I also do VP of engineering. So depends on the company, but the VP or CTO will typically take things like org structure process. Yeah. But sometimes with the CTO, then it's also about things like, you know, if you're acquiring another company, like how do you deal with? Like different technology stacks and due diligence, lots of different things? Things. Very interesting very much. I think context-dependent then
¶ Problems when it comes to team structure
for kind of the the vp's in the ctOS in that way is that there's a lot more variety. That's correct. Yeah, exactly. I mean I would save at A Team level it's like there are still variety. Yeah. But I think the types of problems are very consistent what would be an example of like the types of problems that are like rampant in there when it comes to team structure? Like splitting teams like how big you know we were. Is this actually the podcast or is this? Like just warm up?
I don't know. I usually check after like, when were editing what a good one to start would be all right. Okay. I do, I kind of assumed that you'd be like an intro. So there's no I record. The intro. After our conversation, I put that sorry, I should have. I should have said that. All right, I was just like, have we started or is it?
Yeah, I mean there's a lot of different things so you know I think one thing is it's like do decide if you want just a tech lead and therefore, are they going to do the people management so that sadly manager or do you hire two types of roles like a tech lead, an engineering manager because there's going to be some sort of interesting trade-offs for about sort of side in terms of Team structures, and various things
like that. Then it's kind of a question of like Yeah, like, when should you split or how big should teams be? And, you know, it all really depends. I don't, you know, the thing that I do with ctOS is coach not Mentor. Yeah, so a lot of the time I'm just helping them talk through
¶ Coaching aspects
trade-offs and, you know, I expect them to sort of make their decision at the end having taught through some of those trade-offs because they ultimately go to own that position. And if they're going to be successful, they also have To go off and make it happen. Whereas if you know, I think if somebody gives you an answer you're generally not normally so, like committed to it to a certain degree. Exactly.
So it's good to get some different perspectives and that's kind of the things that we have when we have those conversations. But, you know, I'm always going back to. Okay, well, these are all the things that you might sort of do, but like, what do you feel is best like what do you think given all the constraints and you know, they know People better locally and they know the current context and where their organizations going.
So they're going to come up with a better decision that I could, you know, without War context. Exactly. Yeah. And your role is just to basically help them throughout their thought process and putting that on the table, it's kind of a sparring partner for them to make the decision because ultimately, they are responsible, they're accountable and they are in that rule and they know the fixed. Absolutely. I mean, to me, that's a good reminder about coaching.
Is that you? No, coach helps a person find their own solution to solve their own problems. Yeah. And as a technical person, like I still have to do this as well is, you know, it's very natural
to want to solve problems. Yeah, to give advice to say here's how I would do that and I, here's how I think you should do it. But I think part of the art is like, biting my tongue and to a certain degree and like catching yourself before you say like you should do this in this moment and I think that's the real art and skill of coaching. Yeah. Yeah, I agree. I mean it's it's easier to solve the problem or to give advice in that aspect but to allow someone to go through their own process.
Right? From a coaching perspective, it requires a lot of time requires the right questions and allowing for that space for the other person to come to the conclusions. And I might be different than yours but that doesn't matter in the end of the day. Exactly. Yeah. And it's, I think it's a habit. Like I often talk about with both the technical leadership, training and hiring manager, training people who come from that individual. Contributor background that maker to multiplier mindset.
Yeah, and it's hard to turn off that make a habit of. Like I have this problem. I want to solve it, right? So exactly, yeah. I was actually going to hook
¶ The tech lead and engineering manager paths are sidesteps
into that. Look at that, you could be a great podcast host because my assumption would be exactly that. That would be a problem. Yeah, and I think it, I mean, when I followed the training that was also what a lot of people struggled with, right? Because they come from a role of technical excellence and they want to take the next step and usually, that would be like a
tech lead. Roll an engineering manager role or there's various options in there, but they want to take that kind of background in the baggage, that they've built up with them and they have, I mean, I wouldn't say problems with that, but they do struggle with kind of delegating those decisions and allowing the team to own that and not be a bottleneck in that process. At least that's what I feel.
Like, no, I agree and I think, you know, I really believe that everyone's trying to do a good job regardless of whatever they do. Yeah. And I think it's more More naivety or ignorance who lack of knowing what they should be doing. Because most people, I think, you know, both our Tech lead and entering manager. They think. Okay, I'm an engineer, I become senior engineer. Like, what's my next step up? Yeah.
And so, I think, when they go a tech lead or an entry manager, they like, well, it's more of like what I was doing before. So, you know, it's more of like making decisions or solving more complex, technical problems. And the thing I like to remind people of which, Doesn't really happen. When people find themselves in those roles is the expectation. They shouldn't see it as that promotion, but it is actually a very different role and it's a sidestep.
Yeah, so you're going to do different things, you should do different things and you're going to need some new skills, which you may not have built any experience in which means making a lot of assets and that's scary for a lot of people. And I think, you know, when you're doing something new, it's kind of natural to kind of go back to what you're comfortable with. Yeah. Yeah, which then creates this sort of reinforcing cycle.
Exactly, I mean, if I look at those positions, with those roles especially in my past it was interesting because I would see like the pattern of going back to kind of the comfort zone. But to me, if I think of my position, and if I were to take that next step, one of the first
¶ Mismatch in expectations
things I would do is kind of test. What is expected of me and see if that aligns with kind of my my vision of the job of the Ross roles and responsibilities there because I did still think they're kind of cool. It's dependent. But as soon as there's a mismatch in there and it doesn't get addressed or acknowledged, I think that's where it kind of the frustration builds up to a point where you might be too late with that.
Absolutely. Yeah. And I think a lot of people aren't really helps because they you know, whoever puts them there. So I guess from a Consulting perspective, if it's like stuffing or from a sort of product perspective, somebody's manager. Most people you know it's like a quick conversation. Yeah. Do you want to lead this team? Good. Okay, great everybody really sit down. Down and says, here's how you need to behave differently.
Yeah, like nobody has a very careful and that's one of the reasons why I love the, the training support that I can offer people because, you know, I don't get the timing. Like I can't get people like literally in the moment, they start in a new role. Yeah.
But you know, I think most people kind of go through that realization either early on if they've been doing it for a while, they're kind of like, ah, like this is why I've been struggling and I encourage people particular when I do Is private cohorts for companies to also send people who are thinking about doing this in the future?
Yeah, because you know, we talked how a lot of these require new skills and roles and if people are kind of aware of that, they then have an opportunity to actually start finding ways to practice before they find themselves in that role having to use the skill. And so they actually have that sort of earlier chance of actually building some skills and experience without having to fail spectacularly because they're now accountable for those responsibilities.
Yeah. Yeah. Also let's let's zoom in on that because you mentioned the skills
¶ Skills a tech lead requires
that our Tech lead would require that are not normally or that are bit more out there. When it comes to taking that role in. There are different from kind of the maker rolled the traditional developer software engineer. What are the most ones that you see people don't acknowledge or see initially? Yeah. So I'll talk about one that you also mentioned earlier, which is around delegating, right? So I think this is about like
involving other people. And this is also a really hard thing for technical It is because, you know, most people are used to sort of owning a problem, right? Like that's kind of reinforced, by some language from people around individual contribution, it's my thing my contribution, and as a technical leader, you kind of have to give something
away. And you know, the sort of thing that people enjoy often about that process, is kind of like, oh, like I got to learn something by solving this problem or by solving my particular way and You know, both of mindset shift of saying, okay. Well, now, I need to give other people the opportunity, but the difficult part here is also is when you delegate, well, you have to delegate the outcome, and you have to be comfortable.
Somebody may come up with a very different implementation and that makes some people very uncomfortable, right? It took me awhile as well to get to sort of maybe reframe it of like I have the potential also to learn throughout the people, how they Aperture problem very differently, right? That's a good benefit. But initially, it's kind of like, oh, like, no, that's not how I do it.
So it must be wrong, right? And then comes out those tendencies that from other people's perspective, might be considered like, micromanagement of like wanting to get involved in a lot of the detail and that's one of those big challenges of really sort of stepping back and focusing on outcomes of trying to talk about, okay, what needs to be done, what's the right level of quality and being comfortable?
Ooh, somebody will come up with a different implementation and as long as the sort of quality aspects are sort of met it shouldn't matter. So that's that's a real challenge for a lot of technical leaders. Yeah and discussions especially if you're in a big team those discussions can take up so much time, so much overhead of the rest of the team as well. Well, in the end, it doesn't matter who's right, it really does, truly doesn't matter.
We're going to pick with option. A, if option b turns out to be better, we can flip, and if option A is fine, then we'll The you with option A. But I think a lot of people I mean me myself, especially a few years back. I used to describe myself as very stubborn but now I acknowledge that it doesn't make any sense that I'm right. If all everything I'm doing around, it is, is making it worse for the team? Basically. Absolutely. Absolutely.
So maybe another thing that's actually difficult for a lot of
¶ Dealing with people
people transitioning into this and I do double down on this particular for engineering managers, which is dealing with people. Alright, like people, Things are hard because, you know, there's this sort of saying that people are like, snowflakes because snowflakes like unique. Yeah. And that's also about, you know, true about people. And I think, when people step into a leadership or management role, they think, oh, well, you know, everyone's like me. So I will treat them in my own
personal preferences. And this is the hard thing is, you know, when you're dealing with all the different people who each person is like a snowflake, you have to learn how to do things very differently. In sort of accordance or preferences to each of those individuals. And so, that means that as a leader or a manager, you kind of need to be quite flexible in how you do lots of different activities, concrete example. All right, let's say that you need to make a team announcement.
So I know that my personal preference is to write things down because a I think it tends to be, you know, helps me sort of go through that. But also I can read a lot quicker than I can like listen to podcasts or watch videos and Things like that. Yeah. But you know some people will never read emails. Like it annoys me. I understand like, there are some people who are just really bad at reading emails, let alone writing emails and, you know, for them, they they need to be
taught through, right? Maybe their personal preferences, are they need to have that personal conversation and that's okay. But, you know, if you're sort of announcing something that means that you now have to do this, a couple of different ways, it's not just a line to your own personal preference. This, but to the preferences of the team that you're leaving or managing as well.
And so, I think a, it's awareness that there are like different ways more than, like, how you do things and be of trying to sort of tailor and adapt it and, you know, sort of dealing with the wonderful world that is people. Yeah, yeah, I can imagine that. I mean, it's a difficult thing to be aware of the things if you're kind of in your bubble and you're doing your things and you think they're working, I think one of the ways that you can get out of that is truly
just to ask. Back ask feedback and also explain kind of your thought process, right? Like this is the problem or this is what I'm trying to tackle and these are the kind of my options and this is what I've picked because people can then kind of think with you and give you different alternatives for you to grow as a person. You never going to step into that role and do it 100% of the time perfectly. That's never gonna happen
actually. So you have to learn and grow and allow yourself to grow in that way as well. Absolutely. Yeah. And I think that's the thing that you kind of really highlighted there, which is like when you do People and particularly like teams, you know, you never end up with like the right solution. Yeah, there's no, like, right thing that you can say objectively. This is the thing that fits that problem space.
And so I think one of the difficulties is like a lot of technical people, like a lot of certainty. Yeah, but when you're dealing with people and particularly the groups of people in a team you know like sometimes you're going to have to like make decisions or help the team make a decision that not everyone's going to be Be with, all right. And that's a hard thing because then it means that you haven't got that perfect solution and you may not ever have the time
to find it as well. Yeah, I think if you're in a role like that and you are like involving more people and interacting with more people. There's a few different types of conversations that you're going to have delegating is one of them and even saying, no to others is also one of them and making a decision and being like, this is the way for now. Let's see in adapt, along the way is a third one, and I think
that's probably numerous ones. But I think if you're in that position, you need to be flexible enough and also acknowledge which conversations you're good at and which ones you still need to work on because you're just going to have more types of different conversations.
¶ Communication challenges
Absolutely. Yeah. And on top of that talking about conversations this is where I would also add one of the big challenges for technical people stepping to leadership and management roles is communication. It's something that I've had to coach a lot of technical leaders and managers on it's one of the reasons I have a course on communication. Like communicate like a CTO on the tech lead Academy because
it's such a foundational skill. And I think the reason it's important is as technical leader or manager going to be interacting with many other people from different parts of a business. You know people who come from
marketing. I mean product is one that everyone normally sort of works with yeah from like business operations or like you know so CEO or MD and you know if you start talking to all of those, People about like technical implementations like, you know, using, I don't know Java spring and like DACA and kubernetes. And, you know, we have lots of tech debt and you know, I build is really slow, you're going to lose a lot of people right there.
Like, I don't really understand what you're talking about. I understand, what's important. What are you actually trying to communicate? And that's a really hard skill because most people are used to talking to other technical folk. Yeah. And once again it's a very underdeveloped skill for a lot of people that is going to really Lee be necessary when you find yourself in those roles.
Yeah, I agree. I mean we laid out some of the kind of roles and responsibilities which you might not think of. But we you say you need to be kind of comfortable or adequate before you step into that role
¶ When is the right time to step into a leadership position?
or even when is kind of the right step for you or someone in their career to take that step in kind of gained a leadership position or take leadership responsibilities in that way. So I would, I would think about it. So I mean, A firstly, everyone's a little bit different because they all have different experiences and be what I would sort of think about is like what sort of behavior am I already
seeing from people? That will help them be successful technical leaders or managers and one of those behaviors that I particularly look for, is this idea of so proactivity. Yeah, you know of like going, okay, something's not right. So So let me take that problem and let me try to solve it and help. The team get better at that because if I think about like two categories of people, you sometimes have people that go, you know, I want to be a tech lead.
I want to be a manager, you know, like in an individual contributor a long time, I want to have this role, they give you, lots of reasons behind that, but if they don't really demonstrate that proactivity simply giving somebody a title, doesn't turn them into proactive people. Yeah. And you know, when they find themselves in that role, this often going to be lots of things that they don't take care of because they haven't built up
that skill and behavior. Whereas, if you're a sort of proactive, sort of individual, that's what I think about as like demonstrating leadership, a of like, spotting something and improving something that you're already doing, to help multiply people in your team. That's kind of effectively the essence of what you have to do when you're in those leadership
roles, right? So I think about those sort of two categories of, like, you have people that sometimes Seems like point out problems and then they kind of like complain about it, hoping that somebody else will do about it. Yeah, that's not the bright Behavior. It's that's not going to work when you're in a technical leadership or management role because hey, that's now your
responsibility. You actually have to do something about it because, you know, if you have people on teams that already demonstrating that like, chances are they're going to be a lot more successful when they get into that role. Yeah, I really like that you highlight that the role is and the title is just like a hat and anyone can wear that hat. But someone actually needs to
Take on those responsibilities. And even I mean, the accountability kind of comes with that row but you can still take ownership of that as well, and those people will eventually grow into those roles. You don't have to have the role to take ownership and to do those responsibilities. You can already be proactive in that way and do that. But we do also then say, that kind of leadership positions are
¶ Leadership positions are not for everyone
not for everyone. No, no everyone is. Yeah, and some people would like to Simply stay being a maker and that's perfectly fine too you know. I think it's important that we have a lot of people who can focus on getting stuff done, I also see sort of any patterns on it. Everyone wants to become a leader manager, and I would just claim that a little bit is that, you know, I think you can have multiple leaders on a team, but I think it makes sense to have one formal technical leader.
Yeah, because I think it's important to make sure that there is a decision-making sort of tiebreaker effectively, and that needs to be done through a more formal Channel, you know? Do you see with formal or good formal technical leaders? Is that they do try to groom everyone to be a leader.
All right, this is about that proactivity again and you do that by investing in psychological safety, encouraging people to really step up and take ownership of issues, which means as the formal leader, you're not necessarily actively doing everything for the team. The team becomes a bit more like a, what you might describe as a self-empowered team of everyone. Taking care of things. Yeah. And I like to then, think of the formal technically do a bit more of a safety net, right.
Is that sometimes? What sometimes happens is the if everyone owns something, nobody owns it. Yeah and so somebody needs to make sure that everything that is important is getting done and that's why there's, you know, formal technical leaders is there's a sort of level of accountability so but I don't think everyone has to you know, necessarily want to become a formal technical leader because
because of that accountability. Some people don't want to necessarily have that responsibility for other people and that's a scary thing for some people and that's okay if people do want to do that. Yeah, yeah, I agree with that. I like that you highlight that, right? The qualities that are in a leadership role. You can still get and you can still hold on. You don't need to have all the responsibility and the accountability, right? But proactivity.
And that way is the quality and if that is inherent within the members of a team, then it's going to be proactive team and a proactive team is going to pick up things. Things and discover new things that are going to help them along the way and make the end product doesn't really matter what your building but it's going to make the end product and better as a result of that, which is really cool.
Absolutely. And when I think about other good qualities of leaders is that, you know, everyone should be growing the people that are leading. Yeah, but also that's no. Does it exclude other individual contributors from calling other people on the team like we all learn from each other all the time through code reviews or pair programming and through other people's experiences? You do that. Anyway, it's just once again the you're accountable to make sure it happens if you're a technical
leader. Yeah, yeah interesting. I mean for me personally a few weeks back or you know, I think
¶ Learning from others
it was last week I was asked like we're going to split the team and do you want to be a tech leader door? Do you see yourself in that role for that new team then and I had a decision to make and I chose and I still don't know if that's the right choice. But I said there's a person that's better suited for me. So I want to be in that team with them. So I I can learn from them and kind of take those responsibilities, but at the time I wasn't comfortable taking on that role.
Now, discussed it with a few people. Even with my girlfriend and she was like I would have jumped on it probably and then seeing how that went. But I think there's numerous ways to go about that, right? For me, being comfortable in a row and having those responsibilities, I really wanna do honor to that role and the accountability that comes with that.
So I think for me in a Personal Learning Journey, it's better if I see someone that I trust within that position to then learn from, and and kind of pull myself up from, But yeah. You know I think you highlighted an important part here, which is like a understanding what you want to do. Yeah. Because most people don't write most people are like doing it for often, external reasons like it might be pay or compensation or like the I get to call myself
a tech lead. Yeah. Once again they're often a romp reasons to wanna step into that role because most of the time, those people will suck and their team will suffer if they're doing it for the wrong reasons.
And you know, I think yourself, It's a, you know what I heard there is it's like you want to have a good opportunity to learn from somebody else and to to build up that skill and experience that when you find yourself in that role you know you can perhaps be a lot more confident and a lot of the new skills that are necessary which will definitely help improve the experience for a lot of people as well.
So, you know, I think that's a great thing because a it's like self-awareness for you that you know, what you want to do and you know, when you do step into that role You'll end up doing it for the right reasons, which will then translate into a better experience for you in that role as well as for everyone else in that team as well. Yeah. Yeah I hope. I mean I don't really look and past decisions and be like, oh I
regret this. I regret that sometimes I do and I think that's healthy as well because they strives to do better, or allows me to strive, to do better in the future. But for now I'm going to see how that plays out. When I look at my career, I really have kind of two passions, I guess. And a lot has to do with people and a lot has to do with content creation. And that's kind of how the podcast thing got rolling as
well. So I just foresee myself, either moving towards devrel and developer advocacy, or more towards doing more with people, which would be in my view, like engineering manager in that way, Tech lead could be a step just below that. So kind of threat towards that.
¶ Relationship between tech lead and engineering manager
But what is kind of the relationship between a tech lead and an engineering manager at what's the dynamic there? I'm sorry. I mean, I'll say it really depends on the organization because in some places they are one in the same. So When I talk about injuring managers, there are sort of five different archetypes. I talked about and one of them is the template injury manager
and that's basically a person. So we talked previously about sort of playing hats and it's a person who's kind of got both hats on when, which is a tech lead and injuring manager. So, they have to do both roles effectively. Yeah. So that's the lead technical discussions. They're generally a lot more Hands-On, like literally writing code features and they're also So then accountable for all the people management responsibilities, now in some organizations, those two are
split. And so, you know, there might be split because it's just how the organization runs. It might be split because you know, there may be managing a larger team and so it's often hard to be a really good Tech lead manager with a large team particularly on a very complex product to mean. And so if you split them, you know, two people can then spend more time focusing on making sure they do all of their Once police really well.
Yeah, whereas if you try to stick them all in one person that person's probably going to end up burned couch with too much context switching and just too many things to literally do. So, you know, that might be another reason why some organizations split interest, but where you do have that split of a tech lead an interim manager? The typical sort of line that I sort of see is that at lead is yeah. Leading the team.
Technically. So this means, you know, as the team Team is making significant architecture decisions. You know might be about like pulling in a new partner for external dependency that you're going to then be working with for a long time may be a significant change to some of the system design. You know, they're helping to Shepherd the team's choices to make sure the team is making
good choices. And then also trying to make sure that the team continues to remain productive because the tech lead will often, you know, be able to support sort of That slowed him down. Might be a slow CI build process or, you know, they often have a lot more experience so they can help the team. Maybe simplify some parts of the system in order to sort of speed up feedback. So they can continue to evolve a sort of system.
So they're very, very Hands-On from that side, working with the team on technical quality, architecture design topics, this often than means, the interim, manager forms. What I would describe as a team. Lead injury manager, archetype, yeah. And So they can really focus on sort of the people and the sort of Team aspects.
So they'll be doing things. Like 12 ones, they'll be working with each individual to define a personal growth plan to try to find out how they can grow within the sort of environments that the team of the organization can offer them, they'll often be working on, you know, making sure that the team are actually working as a team, and not just a bunch of individuals. Yeah. In that they get along with each other that they giving each
other feedback. Can a healthy way and they deepen that sort of trust amongst the run which often means you know making sure that the team sort of process or flow is working. Well, so that everyone may be having those difficult conversations up front so that it can resolve issues and continue to build good
relationships. They can focus a lot on those sorts of areas and then often also take care of a lot of the what I'd say as organizational, bureaucracy, maybe processes You know, status reporting in a, keeping planning going dealing with budgeting or approval processes for team. So that's often the the set of responsibilities that fall into
that interview mature. And so those two because they're leading the team in different ways, they need to synchronize, you know, they need to keep aligned is that, you know, the tech lead will probably be working maybe with individuals a lot more Hands-On. Yeah. Because there may be literally working with people on a specific feature and the interim manager will be having
conversations. Those people in one to ones as well about worth and life what's holding the back and how they you know, what support they need and the game, they're going to get to the different pictures of how individuals and how the team is working. So they need to synchronize if they're going to keep aligned. And so that's a really important part. If you do split, the sort of rolls, I would also not say it's just those two anyone else. Who's going to be code? Leading the team.
And another common role will be the product manager. Yeah, so those three roles really need to keep synchronized. In order for a team to be effective. Interesting. Yeah, I can really see why the rule would be split, right? Especially if you have multiple teams in a big organization, you would just spit those responsibilities. And each person can then focus on kind of really honing that responsibility and doing honor to that.
But exactly, as you say the engineering manager is going to get a completely different perspective and they do have skin in the game but not within that team and the tech lead would have kind of skin in the game with that team specifically. So the conversation is also going to have kind of a different Malady. There's a different hierarchy and a different responsibility towards that person in that conversation.
So I also think that benefits kind of the end result in helping the people within that team to allow them to grow, right? Because you're going to get different perspectives. Yes you do need to align but you're going to get multiple puzzle pieces of the whole truth I guess which is going to give you something and and what I
¶ Pitfall of splitting tech lead and engineering manager
would say is that you know I keep emphasizing those two roles need to be aligned and synchronized and I want to sort of focus on like one Pitfall or trade off if you do slip them. Yeah. Where people don't get along right? Because I think one of the challenges sometimes you have is sometimes you can get injured in managers who aren't doing people management, like line reporting in some organizations very important to.
And that's often like a organizational decision about Led You people in a team report to its attacked lead. Therefore they're doing like some of the people management and therefore you still have a team lead type person, entering manager, but Not responsible for people manager and then, you know, there's the argument that the interim manager should have this. Because the tech leads going to be spending time with people as well.
Yeah. And sometimes that that Dynamic can turn into an unhealthy Dynamic, right? Because some people are like, well, only way of influencing people is because I'm their manager, right. Like I literally have a say in their review process. Yeah. But you know, if you're working well together, then they should be leading well through influence in through healthy relationships, or trust. Rather than just because I report To you and you're
deciding. If I get a promotion or a review in the future, you know, that can turn into an unhealthy discussion sometimes I can imagine, yeah. I mean, hierarchy does that to the people in a group like my manager sometimes asks like can you be completely transparent with me? I'm like still my manager, so I can say yes, but probably somewhere deep down. I know, not, that's not true, that's them, the truth.
I give him and he respects that. But he also acknowledges that mean hierarchies the thing, right? We've established roles and responsibilities and they do affect the way you You negate with someone and you can do everything to do like everything in your power to kind of break that. But it's always going to be in place in the back of people's minds.
That's alright lately. Yeah, it is it is it can imagine that I mean the roles and responsibilities that can fit with one person but I am assuming if you do split it, there's also going to be a conversation about what, what lies where and it's very much going to be context-dependent. But in my view, what we shouldn't like the goal, is to make the team. Team and the people in that team as effective as possible and allow them to grow and Thrive
within the organization, right? So also, you need to be choose your battles in that way, and it's given take when it comes to your own decisions. Because sometimes it's also, if you have a leadership position I would assume. It's not necessarily about you. It's more. So about the people that you are responsible for and that should then also be your main priority in your main focus.
¶ Conversations about roles and responsibilities
Absolutely. Yeah. And maybe something a little bit practical for some of the people who are listening as well is that you know, you mentioned that yeah you have. You have that conversation around splitter responsibilities. Yeah. And a good mental model. I tend to think of is you have your team, right? You have everyone working the team and then as a cool leadership group you should consider them also as a team.
Yeah. And it could practice with any team is to have conversations around expectations over roles and responsibilities. Yeah, and so that's also something that even if you have a template in entering manager, people might go, yeah, I kind of get a sense about what you are doing. At the beginning of working together, it's healthy to sort of sit down and say like like what level of involvement, like who should own this thing, you know, who's accountable, who's responsible?
What's the, the type of style that would like, to sort of work with each other? And on some of these activities, do you like to do that thing too? I like to do that thing to really make it explicit and deliberate because I think where I see sometimes, a lot of conflict is unnecessary. Yeah. Because most people make assumptions. Oh yeah. Well you know of course they're going to Care of that or of course, that's my thing.
And then either one of two things happen is that the other person is thinking the same thing and something either slips through because they're assuming the other person will take care of it or feels like they're treading on each other's toes because that's like well, that's my responsibility. Oh, that's my activity. Why are they doing it? Yeah, and they're not sort of direct or upfront about having
that discussion. Yeah. So make sure that you do sit down if you are in a sort of power or a A split current leadership role. I think of it as a mini sub team, where you should also think of that. As going through the sort of team formation process and set expectations, agree on, you know what, how you'd like to work together as a mini School leadership team. That's really important to going to building healthy relationships.
Yeah. Yeah. I like that you draw that comparison because those those aspects you were mentioning I was like that really helps forming a team, right? And in kind of a scrum team as an example, you would go through that. Right Through Fire, and probably through a lot of product
development in there. You would learn about what the other person is responsible for takes accountability, for takes ownership of, and you're going to tailor-make kind of your team towards that or your personal approach in there to really come out better as a team. And even if you are in a
¶ Leadership teams
leadership position, you have still people that you collaborate with on a day-to-day basis. So, for me if I'm in a product team and I look at kind of my management layer, I expect them to work together as a team, and it makes me really sad. If I don't see any aspects of that, if someone is just working on their own soil.
Oh, and then don't really communicate and I notice that they don't communicate like it. It, it's not as effective as it should be. And you are a team even though you don't really want to admit in that. Absolutely. And, you know, I think that's the thing which is like you have to invest in building a team. You can't just assume like well, which were people together and work well, but we're teaming up. All right? It's like, it's it takes effort, right?
And energy and time. And if people are making that time, Then you're kind of like hoping. I hope is not necessarily a good strategy for building High performing teams. Exactly. I mean it's an interesting thing because when I'm in a team, one
¶ Who is responsible for team effectiveness?
of the things that really motivates me is of a team is really effective. So even if I know we can be more effective or more efficient, that's usually what I put my focus and effort into. That's also all my stickies on a retrospectives are about like we can do better because of this and then we'll be more effective usually.
But when it comes to the actual responsibilities of Effectiveness is, That like, within a leadership function or, or a position in there, or is that more like ownership of the team? Because I, I feel a high responsibility towards that is because it's more of a personal drive. But I don't know if that responsibility should lie with someone else. So you're a, I think you're I can sense. That sense of like people are focused trying to help the team, be a lot more effective. Yeah.
And you know, I could have mentioned that whoever is a formal leader or manager for your team is very probably happy to have. On the team. I hope so because, you know, you care about like other people and you're helping things work that way, you know. And I think this is where it comes back down. To me, this split between accountability and
responsibility. And the old saying, it depends is that in an Ideal World. If we go back to this idea of like a self-empowered, team, everyone at Team, should be thinking about how they should be improving Effectiveness, like yourself, right? Everyone should be piping up and saying, hey, I think we could do this better. Let's make it better. Let's okay, let's do. This to make it better. And let's all work better at of
improving this that aspect. Yeah. But what happens if it doesn't what happens if people in the team, you know, they're just happy doing individual work but you're not thinking about that, right? And so that's one of the reasons why you have those formal leaders that sort of safety net again, is that, you know, somebody needs to focus on that. If you're going to help the team become a lot more effective. And so that's where the
accountability comes. And this is the trickiness with the leader is that you have to adapt. Your style is that, you know, if we have Team of people like you Patrick me as the former leader. I don't probably need to worry about too much. Right. Is that I can go back to maybe also being an individual contributor because the team is taking care of a lot of different things. But in a different parallel universe, take a different team with different people.
You know that just focused on doing their own thing, not thinking about how to improve their own work environment. That's now on me as a leader to probably drive more of that activity because it's not happening, sort of by default, Fault in a tree and in order to improve the effectiveness of the team, somebody needs to do it, but if nobody is doing it in the team, that's what the sort of accountable leadership role is
therefore to help improve that. And yeah, that's that's kind of the, it depends, but it really depends on the people in the team and what is actually happening?
¶ Pat's favourite role in the past
Yeah. Interesting. When I zoom into your past because you've had like the Rosen responded responsibilities of an engineering manager Tech lead and CTO What was really the position where you were like, God, this was like, really my thing, or I really felt at home with kind of these responsibilities and accountabilities. Well, it's a it's a hard question because people grow. Yeah, right. I think this is the hard thing is that a different parts of my
journey? You know like I wouldn't have probably tried a different role if I didn't want to experiment with something that's a good, you know. I think the human side is I think it's called a hedonic at a hedonic adaptation. Is that, you know, something that brings us happiness. We, if we keep doing it, we kind of get a bit bored because we adapt and, therefore, we need like new things for a lot of people. It's often about like a new type of program, or a new type of
tool to play around with. And if I go back in my career, I remember one conversation with somebody. I had at a pub, like, with all things weren't exactly and he was like, oh, you know, well, I do is basically write something that takes an XML one program and like, spits out XML for another program. I'm kind of like that's kind of all the programming. Really like might be a different thing not XML. It's like Json or like an event and you can do some stuff with it.
Maybe save it away for a while and then you kind of like you know throw it out somewhere else for some of the system to Joe that's got to be a sense of it, all right? And like, you know, for some people like the how to do that is like really interesting and fun but maybe like yourself who kind of like well okay you know what? The people element, that's kind of interesting, right?
Because there's a lot of to learn there and so, you know, depends on the sort of background because people learn and grow. And so to me, I, you know, I'm not generally a long-term plan and I feel like, I think I have some cool things I enjoy doing, right. So, like, I helped enjoying growing people and you can do that as an individual contributor.
You can do this at the tech leaders and interim manager as a CTO what I do now, helping lots of ctOS, helping lots of people through my training and workshops, And you know what, maybe what was less important for me? Was about maybe learning another programming language or another sort of tool set. Yeah, because, you know, once you've learnt a few programming languages, the next one's not
that different, to be honest. Okay, different syntax, different, build tool, different, unit, testing Frameworks, whatever. But like, it's still kind of the same type of thing, right? So, you know, I think it's kind of different, so it's hard for me to answer that one could imagine. Because I think you know, like I
think That growth is nonlinear. It's like you kind of Wonder and can happy for a bit, but because we're people that had Sonic adaptation kicks in it, so I need you, I feel like I need to do something different, right? And you kind of like and so there's probably like snapshots of things like that over my career but it's not like one point where I'm like, I'm frozen and I have like found my spot in the universe for all of life.
Like I kind of try to say Never Say, Never because people change people, learn people grow. Yeah. I align with that a lot actually, I mean I laid out kind of my career options now, and it's devrel and probably engineering manager. But if you were to ask me a year back or even two years back, I would have said scrum master. I'm parked on her because I was all into that and I have, I mean, I'm lucky that I'm in an organization where I get to try
¶ Figuring out what you like and dislike doing
out a lot of things. I think, especially when you are a person that has kind of a broad interest and doesn't exactly know where they want to head out yet, it's the best organization to be in when you can try out like roles and responsibilities with regard to those, Rolls that you kind of aim for that you're interested in because also figuring out what you want to do and figuring out what you don't want to do is just as important because the more you figure out what you
don't want to do is going to get you closer to what you actually do, want to do down the line and if you actually get to do that, it's fine to then move on as well and be like our something new and shiny. Let's let's see what that is.
Absolutely. And it kind of like what you described them particularly about your environment is important thing is that you do have lots of Knees to try different things, but even if people aren't an opportunity where you feel, there's a lot of different things. Well, I find myself repeating quite a lot for people on Career advice. I get a lot of asked about a lot career particularly in Korea. Yeah, is I find it's not so
¶ What do you want to do?
useful to say, what do you want to be? And I'd rather sort of say, you know, what would you like to perhaps do for say the next 6 or 12 months? Yeah. And what I mean by that is like, don't think about the role think about like the skill or experience that Like to grow in and find ways that you can practice, that skill of develop that skill and experience. Because often that skill and experience will sort of you can use that in other roles, just in different ways.
So as an example, you know, very early in my career, one of the reasons I wrote like the retrospective handbook was because I did a lot of facilitation. Okay. Is that for me, it was an interesting thing. I like a, I was really annoyed at like poorly running. Yeah. So like if I help facilitate it, Then we could be a lot more
effective. So there's like a personal selfish reason but also, you know, there's a side benefit in that other people don't have to sit through an effective meetings and I was like, fascinated by that. But I also wasn't like, I want to become well. I mean, I didn't really think about it, but I didn't really think I wouldn't become a full-time facilitator. Yeah, yes. That's a skill and experience. And, you know, when I was leading technical teams, it's
then a skill. I could bring with me, you know, when you're dealing with very highly opinionated, technical limitation is a very good skill. Absolutely. And then similarly in a CTR role it's a great way of like surfacing quite a voices and things like that. And so that's what I find is really useful. You know when you think about what you want to be it feels like a non-reversible decision. Yeah. It's like a decision that used to make it's like fully
committed. Certain Stone. Exactly. And you know I think the thing is if you focus on what you want to do or practice skill and experience wise for a time period, you can change it again in the future and you can probably use that in which have a all you end up doing in the future. Yeah, yeah, you love that. I've learned throughout this podcast. That communication is a life skill. And even though I'm not going to do a technical, I'm not going to have a technical responsibility
throughout all my life. Communication is something that I take with me. So the more life skills you can cultivate, the more you can take with you also to New Opportunities and jobs in there as well.
¶ Growth mindset
Absolutely, I've really enjoyed this conversation. Pat, I'm going to round it off here throughout your journey with regards to leadership roles and even career advice in there as well. Is there anything? We miss that you still would like to share with our audience. I think we've covered quite a lot.
Right? But you know, I think maybe if there was anything, I was to reflect on our conversation today, is it feels and maybe people don't know about these sorts of two different ideas that you have a very strong growth mindset. And so, you know, sometimes there's such Terror of this fixed mindset of like what we are, who we are and the in eight things that were born with.
And, you know, I think the things that I've learned over the career that I felt is reflected a lot in our conversation today is that, you know, by taking this growth mindset, is that we all have ways that we can all grow. You know, there are things that we can tap into that are maybe are innate strengths. But there are also lots of different dimensions that we always have some capacity to grow and learn in as well. So, I love that final words. That's awesome. That's awesome.
Cool. We're going to round it off. Here everyone. I'm going to put all Pat's links in the descriptions pack who are check him out. Let him know you came from our show. And with that being said, thank you for listening. We'll see you on the next one.