Over on the ExperiencedDevs subreddit, a Redditor wanted to know if it's typical that software engineering teams are dysfunctional.
Does this happen everywhere? Is it commonly caused by something?
Let's dive into the conversation!
📄 Auto-Generated Transcript ▾
Transcript is auto-generated and may contain errors.
Hey folks, I am just leaving the office. It is Wednesday evening. Beep beep beep. Um, it's a pretty tight parking spot here cuz someone decided uh I don't need any space, I guess. Pretty cool. Let's get out of here. This parking lot's nuts. All the spaces are compact. Every single one of them. Okay. Um, we're going to experience devs for a topic. Uh, I don't really know. I'm going to navigate this one, but the topic was like, uh, are all software engineering teams as dysfunctional as, you know, the one that this person's talking about? And they said like, do are there actually high performing like software engineering teams? And I did a brief like this was mostly about me being curious and like scrolling through the comments and stuff and a lot of people are like nah man like every place is like totally screwed up and like um this is just the way it is.
So I don't know what I was expecting. Maybe maybe that is what I was expecting. Um I wanted to talk a little bit about you know some some things that come up in the thread. I'll talk about um what I feel like was high performance teams that I worked on. Um the the bias is gonna be like I was managing those teams. Um but I got to move my bag off the seat cuz it thinks that there's a human that's not buckled up. Um but I want to talk about what I think made those teams effective and uh why I try to lead teams the way that I do. And uh obvious you know disclaimer is like I realize that as as I go to talk through this I'm going to be making it sound like oh this is the only way to do it. My way is the best way.
It's not not what I'm trying to say. It's just that based on my experience when I thought things are going really well. I take the things that I was doing during those times and try to apply them in my leadership. Uh not saying I have it all figured out. I don't want to come across that way. Okay, it's not the case. So, before I dive more into this topic, a friendly reminder, this channel is all about answering questions that are submitted. So, if you have questions about software engineering, career development, submit them below. Happy to answer. If you aren't comfortable leaving a public question, you can message Dev Leader on social media. It's also my main YouTube channel where I have C tutorials. I have free resume reviews. If you go check out the channel, you can see how to submit your resume. Uh there's a podcast there as well.
And live streams every Monday at 700 p.m. Pacific. So would love to see you there. Um and yeah, you can message Nick Cosantino on LinkedIn. That's my my name. And yeah, happy to keep you anonymous if you want to message. So for this topic, I think that it is unfortunately very common that uh as and I would argue probably at bigger companies too, more common where we have pretty dysfunctional teams. Um like I said, I don't know exactly how I want to navigate this one. Something that I thought was very interesting that was pointed out was that uh a lot of people I say a lot I mean for the comments that I was scrolling through there were several people that were talking about like uh basically leadership or management being like sort of the root cause for this kind of thing right like people
were saying hey like I've worked with people that you know the engineers that I was working with like the team seemed like they were competent effective engineers but um even in situations where they had that happen once there was like a a person in management or leadership that came in like they've watched it all fall apart. So across a few of these comments, one of the themes being like if you put people like people in charge being shitty, then it all erodess. It all falls apart. You have, you know, dysfunctional teams. You have all these bad things happening. Um, and you've probably heard this saying, right? Like people don't leave, what do they say? I'm going to butcher it even though it's a popular saying. It's like people don't leave jobs, they leave their their uh their managers, right? And so as as an engineering manager, like I I actually, you know, I subscribe to this idea.
Um I have I have lived through periods where people were in sort of like a management or leadership position and dramatically affected like everything below them in negative ways. And my goal like I I don't like making videos where I'm like bashing people or things like that. So that's not my intention. But uh I just want to be able to kind of talk about this kind of stuff openly, right? Like I've been in situations where they bring in someone who oversees the organization and the side effect of that and not like not maliciously, right? It's not like oh like yes now I have full control over the organization. I can screw everything up just like I planned. Like certainly not like that but either through like you know lack of effective leadership, lack of understanding of the domain, lack of like whatever it happens to be, it could be any number of things that the side effect of that is like things start to fall apart below them.
So, one example that comes to mind is like we how do I how do I talk about this without like I don't want to like on anyone. Um I had at some I'll just I'll talk about it very vaguely. At some point in my career, I had um some some leadership changes. And those leadership changes resulted in um sort of this style of leadership where you come into a place and you go, "Oh, like it must be broken. I'll I'll be the fixer." And Sounds good, doesn't it? um they they start trying to make all sorts of changes when the reality is like nothing was actually broken and they start causing a very significant impact in not a good way.
So the in this situation this person was basically like okay well we're going to hire in these other roles because like company's scaling so like we're going to bring in uh we brought in architect roles we brought in like uh documentation writing we start like there were all these things that they tried to go change like boom boom boom boom boom to essentially like to help But they were kind of like unfortunately they were given the reigns to go do it. And I'm not I wish I was making this up. Someone after this this person had departed um someone had dug up like we were following agile or you know agile our own version of it trying to be uh nimble as much as we could as a startup. Um, I'm giving away too much already. Someone had dug up like a velocity chart. Okay. And obviously, I'm not saying these things are totally accurate.
That's not my intention, but like we had on our chart, the velocity literally went down to zero at some point on this chart. Like the impact that this person was having, not not maliciously, right? just like the the effect was that at some point our velocity chart trended to zero. It was extremely negatively impactful. Um now are they the only problem? Like is everything to like are they to blame for everything? No. But like under their leadership this is what happened. And interestingly enough, you remove you change that part. You put better leadership in place. Our velocity graph recovered from zero. I mean, at zero, the bar wasn't set very high, but like the the point is that you can have very dramatic impacts uh through through reorgs, through leadership changes, through managers changing. Um, it doesn't even realistically it doesn't even in my opinion it doesn't have to be a manager or leadership.
If you have like formally if you have someone in a position on a team that people are looking up to like let me know if if you've uh worked with people that are um the stereotypical like intelligent right? And if you're not familiar with this persona, this is the person on a team where they are intelligent, right? Um they they know what's going on. They like they might be very proficient in the tech stack, the programming language, the domain. They are a very intelligent person, but like basically their opinion's the only opinion. Like they'll steamroll conversations. They don't care about you. They don't care about the work you're doing. Basically, they will have full control over things and they're called the intelligent as a persona because they are very smart and they're to work with. These types of individuals are toxic for a team. They will completely destroy the effectiveness of a team because they become the bottleneck for everyone.
And these types of individuals at a team level can have the exact same type of impact where basically everything grinds to a halt. So point being that I think when you have people in a position of influence, let me generalize it to that that based on how much influence they have and sort of how dysfunctional they are, they can spread that negative influence, that impact, you know, to to what they can reach. And again, it's not meant to be malicious. As I talk through this, I don't mean for it to sound that way where it's like, oh, uh, that persona I'm describing or, you know, I think all managers are bad or, you know, I'm just jaded from having crappy leaders at some point. No, I just mean like I don't I'm not trying to say that they mean ill. It's just that through incompetence or some other thing, their personality, their focus, their leadership, they have a really negative impact.
So to the point of this post, like what people were describing was like, hey, in tech, like some big tech companies, uh, and maybe not just like purely big tech, I just mean larger tech companies where you have multiple levels of management and leadership. Someone was saying like, you know, sometimes it seems like people are just reorginging to make it seem like they're important. Like if we don't reorg some at some frequency like what else are we doing right like we don't actually add value we have to keep busy by reorginging now I've not been in I've not been in a company at that level of leadership where um I have a a perspective on that. I would like to think that's not true, especially as like a generalization. That sounds like pretty terrible. Um because I I don't know. I don't like having generalizations like that where the majority of people are just like crap.
I don't like that. Um not my philosophy. Do I think that that might exist? Sure. I don't want to rule that out. I just don't I don't want to believe that it's the majority of people that are like I actually in leadership positions that are thinking I don't actually add value so I might as well periodically reorg so I can be kept busy and look important. Um now this type of thing is super disruptive for sure. So whether like I don't know I've talked about this in other videos if you've had a manager change like that can be insanely disruptive to individuals. It might not be disruptive to a larger organization when when a manager changes depending on how much or how many people like sort of report up to them. It might not be that impactful for a single manager, but their direct reports, sure, that's going to be Even if you have a good manager coming in, like it's disruptive.
It just is. And I say that as an engineering manager who has been brought in to manage teams. I understand that that's disruptive. Um so I I think that when we have a lot of these types of things going on in companies, frequent manager changes, you have reorgs, you have I don't know like all this kind of stuff going on. I can absolutely understand why people would say from my experience when you have a bunch of this kind of stuff happening on a I don't know I want to say semi-regular cadence that could be like from a couple of times a year to you know once every couple of years to me that can be pretty disruptive now maybe not for everyone maybe not in every situation but I think that that can lead to some challenges for Sure.
So, one of the things I wanted to touch on was like like as people that are responsible for for leading teams and I don't just want to say like I don't just want to include engineering managers, right? Yes, that's my role, but I want to be able to include like people in like tech lead and um team lead positions, even senior engineers, right? Like being in a position where you have influence. Let's say the I think one of the most important things that we can do is like remaining connected with people. And I realize that sounds kind of like weird and corny and cheesy and like what does that even mean? But when I reflect on like when I when I feel most effective as someone leading teams um the reason I feel effective is not because I'm looking at numbers on a dashboard being like yes numbers go up on team therefore Nick effective.
It's more like I feel very connected to what people are doing and like their challenges and what they're focused on. All sorts of things. One sec. I got to switch lanes. Oh, it feels so good to be out of that lane. Um, I feel the most effective as an engineering manager when I just have an understanding of what's going on with people as individuals, right? If people are frustrated by if they're really enjoying the work they're doing, like I need to be super connected with the people on my team because that's one of the best ways that I can enable them to do their best work. If there's people that are frustrated with things and it's in my control, then great like let me know like let me like I want to observe it. I want to make sure I understand from people. I want to try driving change in a way that enables them.
If it's outside of my control like I need to make sure that I understand the problems they're facing so that I can bubble it up so that I can get it to the person or group that can help drive change there. But if I'm not connected really well with people, I'm not in tune with them, I'm not doing one-on- ones frequently, you know, don't have good trust, all these things, falls apart. Now, I'm kind of speaking from my own experience, right? where I'm like, hey, this is how I see it as as an engineering manager. But let me tell you that I can also speak about it from, you know, being the person with with the engineering manager that is not doing those things. Now again, not I won't I'm not trying to draw attention to any specific manager, leader, any point in my career, just to generalize it.
I have had managers that stop doing one-on- ons. And I don't just mean with me, I mean with their reports and things start to go south. And I'm not saying that because like the one-on-one is the most important part that glues everything together. Not it's not the implementation. I mean that they start getting disconnected from the team and that way they're not paying attention to things that the team needs. They're not there to support the team. And I would say the same like you know to to kind of lube in tech leads and team leads. If you're not in tune with the people that you're working with that you're trying to lead, like how the hell do you expect to lead them effectively? Cuz if it's like, "Oh, I just tell them what to do." Like, uh, I hate to break it to you, that's just like that's just telling people what to do.
It's not actually leading them in any capacity, right? So if you're trying to lead groups of people, you need people to follow you. Telling people what to do does not mean that they follow you. Right? To be able to lead people means that they trust you, that they are believing in the things that you're saying, they respect you for it. And like one of the side effects of that is that when you need people to do things and you ask them to do them, they're happy to do them or they understand. They might not necessarily be happy, but they understand. So I think like moving on to the next thing like I think one of my strategies for for leading especially like coming into a team cuz this is if we're talking about churn being one of the things that can cause a lot of
dysfunction right leadership management whatever it happens to be churning causing dysfunction um I think that one of the things that I try to focus on is when I join a team, my goal is to observe. It's two parts. One is to get to know every individual on the team. I got to change lanes here. And the next is to observe what's going on. Now, in my career, I've never been brought into a team where the person that hired me said, "This team is falling apart. Like, you're here. You better go change it all." No one's ever said that to me. Right? It's It's always been the exact opposite. Hi, we're the team's awesome. We're scaling the team. Great. Okay. I'm going to get to know and understand everyone. Right? I need to start building trust and respect from day one. It's going to take time. I got to start.
And that means getting to actually know people. Part one. Part two is I'm not changing If someone brings me into a team and they say the team is great, why should I think that I'm coming into this brand new, never working with the team, and I'm going to start making changes? Like absolutely not. So, I go into things like being uh hands on with getting to know people, hands off with process and changes and stuff like that because until I've observed, I'm not in any spot to start making recommendations. It's totally it's not for me. And I say this because I have been burned. Like I already gave you the example earlier. I have been burned by this. I have been on the other end of this where it was so shitty to have someone come in and start trying to change everything and again not maliciously but create all of these problems, create all of these inefficiencies.
And if they would have just stopped when they joined, if they did spent more time observing and then trying to work with people to understand where the challenges were, I think that a lot of those issues would have been avoided. So, so far with my rambling rant, I think the the one thing I just want to re-emphasize is that like I think as people that are in charge of leading other others, um whether that's as a team lead, a manager, someone in a leadership position, I think one of the most important things that you can do is stay in touch with the individuals because I think Once you lose that, you're flying blind. And I generally don't think it's going to turn out very well. You're going to have people that resist the things you're proposing. They're going to they're going to be frustrated by it because you're not actually listening to the things that they need support on.
They don't feel seen. They don't feel heard. you're just kind of telling people to do things. So, um to to kind of again shift gears, like when I think about one of the teams that I I think about being like I don't know, the most effective team that I've worked on uh in this particular case I was working you know as uh both a manager for the team and a like I was writing code with the team as well. I don't think the fact that I was writing code is the thing that made the difference. I think that writing code with the team enabled me to really understand like the challenges that we were working through. But I think what worked so well is that you know meeting regularly with people to understand like what's getting them engaged, what's getting them, you know, upset, where's the friction, what are the things they want to grow and do like I think spending time doing that is uh very underrated.
So doing that a lot, making sure that people had autonomy. Um I I can't stress that one enough. You know, one of the examples in the Reddit thread was about dysfunctional team was teams was like micromanaging. Yeah. when you have when you have people that lead teams and um I don't this is going to sound like I'm I don't know like I don't I don't want to make it sound condescending or putting certain people on pedestals kind of thing but if you're if you're an individual contributor okay and you don't have an interest in leading teams um and it's never been something that's, you know, top of mind for you. How you approach trying to lead groups of people probably follows some patterns and that is it's and I'm saying this like not a you know you got to be careful on the internet. I'm not trying to say everyone is like this.
I'm just trying I have to generalize a little bit. A a common pattern I see like this is that you end up sort of telling people what to do, right? like you're if you're an individual contributor and your first kind of time being able to help organize other people um lead them through something. If you're not experienced at doing it, a very common thing is you start telling people what and how. I've made videos on this before. It's just a common thing to do. And the reason is because you're not used to a couple reasons. you're not used to driving um or gauging your impact as the sum of other people's work. It's part one. You need to be involved. Number two is like you haven't built up trust with these other people and you're responsible for it now. So you it feels more sensible that you're telling people like, "Hey, I'm responsible for this.
Here's how it's got to get done." or people, you know, it might not even be your mindset. It's more like people are coming to you and saying like, "Hey, I need direction. I need help with this." And you go, "Oh, I'll just tell you how to go do it. Go do this." Right? Like these types of things over time, if they're not like thought through or built upon, I strongly believe lead to micromanagement. You get used to telling people what and how to do it. when you have people that lead teams where they have the mindset of an individual contributor that has not grown out of that. So I said I don't mean for it to sound condescending. I'm not saying there's anything wrong with individual contributors. Uh please don't interpret it that way. I'm just saying that if you've not built up the effectiveness and the practice for trying to to lead other people, a lot of the time this leads to micromanagement.
And it's it's like I'm not blaming people for that. Like if that's if that's how you've known to do it, right? Like then that's going to be the thing that you repeat. So autonomy is like ridiculously important because you need to be able to give autonomy to team members, right? If you're a team lead, like you might need to do a little bit more guidance. For some of the more junior people, maybe you do have to kind of tell them what to do because they need they need that much more guidance. But for the people that are more senior, like, and when I say more senior, I just mean more senior than like someone who's just starting in general. Um, you want to make sure they have autonomy. Engagement falls off when your autonomy is gone, right? If people don't feel included in decision-m, if they're not that they don't have ownership over things, engagement will drop off.
You will get results. You'll have dysfunctional teams. Burnout will be higher. Why am I here doing this? Why am I doing it? Someone else already knows what to go do. You go do it. like why am I why am I the one? I don't care. It feels like it's for someone else and that someone else is not the customer. Like that's the shitty part, right? When we're doing work like this, when we're building things, we're building software, we're solving customer issues, we're building platforms to help our partners, like it's awesome to be solving problems for our users. What doesn't feel so great is solving problems that someone just told you to go solve and you feel like you're doing it just because they told you and even worse. They just told you it has to get done and here's how to do it. What's your involvement?
You press the keys on the keyboard. It feels like So I think you got to be connected with your team, right? I said earlier it can't be under uh just can't say it enough like it's it's so critical. You have to keep connected. You need to be able to build the trust with the people that you're working with so that you can give them autonomy. Give them that that safe place to fail. I you know I I think that you know reorgs and stuff like that can be done for for good reasons right like if there's growth in areas and like realigning makes more sense from you know leadership product areas whatever it happens to be like I'm not saying that there's no reason to do whatever um I'm just saying that these can have like rippling consequences that they're not they're not obvious if if you're not working closely with people, right?
So, I'll give you another example, and this isn't me talking It's just like sort of reality. Uh I used to work uh on the deployment team for Microsoft 365. So, I switched teams last year and we had done a reorg and the um the impact of okay let me talk about the impact of the reorg and again this isn't me not talking ill of anyone it's nothing to do with individuals the impact of the reorg that we had one of the consequences of that was that how engineering managers were interacting with product road maps for the engineering teams changed completely except the way that this was done was not actually communicated clearly in my opinion. Again, I'm not saying that's any one person's fault. I wouldn't even know. I can't point a finger cuz I don't even know who to point it at. Like, I'm not saying it's someone's fault.
Um, I'm just saying this is the side effect. Reorg happened. There's different product management groups brought in. We have different engineering leadership. Everything changed around us. So, everyone is just trying to do what they're familiar with. And the side effect of that was that we had uh this this change and in my opinion it made being an engineering manager extremely difficult because seemingly out of nowhere I felt like I didn't really have any influence over the teams that I was managing because all of a sudden I'm like I don't know what work is supposed to be a priority because there's a different group of people with the best intentions that just have different priorities and we're currently not aligned. So again, no individual's fault, nothing like that. Something like a reorg just was extremely disruptive. Okay. So like is this a a particular leader's fault? I don't think so.
Could a could a different leader have done a better job? Maybe. So in this case, I'm not even talking about specific people. I'm just saying the nature of doing the reorg. If this is something that happens at companies at some interval, whether it's fixed or not, um, if it's happening, it's going to cause disruptions or or has the likelihood to cause disruptions. So being able to have I think like highly functional teams uh you need some amount of consistency, right? Like uh if you're going to put a team together, the likelihood of a bunch of, you know, complete strangers working together super effectively right away probably low. I just I don't see that being a very effective thing off the bat.
But I think if everyone involved in that team is understanding how other individuals work, you have a leader in place that is understanding the individuals uh like I was saying earlier that you start to build trust in the team very fast or or faster than you would if you were like I'm just going to basically only focus on the work that's like like what's the coding task in front of me, right? or the manager being like, I'm just going to delegate work. I don't care about the individuals. When you start having more interactions and and understanding the people that you're working with, I think you build trust faster. I think you build respect faster. And then you can start having difficult conversations in the team when there's friction, right? Like, hey, I don't agree with this design pattern. I don't agree with how we do code reviews.
I think our build system sucks and we should try to do something better. We don't even have a build system. We don't even have unit tests. We should start writing those things. I like tabs. You like spaces. Like, you can start having conversations about this stuff and addressing it and improving and working together versus being like, I don't know, man. I don't really know Joe, but he's on the team. He seems to suck. Like, I don't really like him. I don't really talk to Joe, though. I just, you know, kind of in the way when I'm trying to do stuff, but like I'm not going to talk to him. And then you have, you know, leaders that that aren't in tune with that. Like kind of just ignoring what's happening on the team. Like, I mean, some of this stuff probably sounds obvious. I just don't know why people don't invest time into it.
I say this a lot, maybe not as often as I should on this channel. Um, definitely like in my social media posts and stuff. You know, software engineering, you're working with people, man. Like, if you're not thinking about how to be more effective with the people that you're working with, it's going to fall apart. It's not going to be effective. So, especially for people that are in leadership positions of any kind, people first. If you put people first, and you empower them and they're engaged and they know why they're supposed to be doing things, they know what the motivation is, they have the autonomy, right? You have smart people. Give them autonomy. Oh, that's a a good lane change with no signal. I almost went there, too. Give them autonomy, right? Like, they're going to do good the more that you start micromanaging them, taking away their autonomy, not explaining why, being disconnected with them, yeah, it's going to fall apart.
I think to some of the comments, I fully agree that a lot, you know, most sort of dysfunction that comes up with teams is cuz you got managers in place. You got crappy leaders. What I've absolutely had the pleasure of working with people where I felt like our team like you know the mindset like there's nothing our team can't solve, right? being being so motivated by difficult challenges because it's like every time we solve something that seemed like there was no possible solution being like we we did it man like what's the next thing like try try and you know prove us wrong that we can't solve it um being in a state like that is so awesome because it's like a I don't know like a vicious feedback loop where give us a hard problem we're going to we'll figure out a way crush it and we want to keep doing interesting, challenging work.
So, I don't think it's impossible, but I think one of the the main ingredients is like I've said it like a million times in this video. I'm very good at repeating myself if uh if somehow you've made it this far in this video and haven't noticed, but people first. You stop telling people what to do. You stop telling people how to go do it. Exceptions apply for very junior people that need a little bit more structure. Because, by the way, this has bit me before where I've had very junior people and they get kind of stuck because they're like, I actually just really needed some more structure and then you micromanage a little bit for them. So, they get some momentum and they're actually like happy for it. Um, so situational leadership people. But anyway, I think that's I think that's all I got. Um, yeah, it's it's unfortunate that there's more probably statistically more like dysfunctional teams and like highly functioning ones, but put good leaders in place that care about people.
I think uh I think you'll see some differences. But that's it. See you next time.
Frequently Asked Questions
These Q&A summaries are AI-generated from the video transcript and may not reflect my exact wording. Watch the video for the full context.
- How does leadership impact the dysfunctionality of software engineering teams?
- I have observed that leadership or management is often the root cause of dysfunction in software engineering teams. When people in charge are ineffective or lack understanding, it can cause the entire team to fall apart, leading to issues like decreased velocity and low morale. Good leadership that stays connected with the team and supports them can prevent these problems.
- What strategies do I use to lead high-performing software engineering teams?
- When I join a team, I focus on getting to know every individual and observing how the team operates before making any changes. I prioritize building trust and staying connected with team members through regular one-on-ones to understand their challenges and engagement. I also emphasize giving team members autonomy, which helps maintain their motivation and ownership over their work.
- Why is autonomy important for software engineering teams, and how do I balance it with guidance?
- Autonomy is critical because it keeps team members engaged and motivated by giving them ownership over their work. I believe micromanagement often arises when leaders have not grown out of an individual contributor mindset and tend to tell people what and how to do tasks. For more junior team members, some guidance is necessary to help them gain momentum, but for senior members, I strive to provide autonomy while maintaining open communication and support.