Managing Team Conflicts and Growth

Welcome to Building Better Developers, the Develop and Work Podcast, where we work on getting better step by step, professionally and personally. Let's get started. Well, hello and welcome back. We are continuing our season where we're talking about mistakes we've made, failures, missteps, and how to grow or learn from, or how they were stepping stones for a future success. This episode is going to seem maybe a little different because it's going to probably feel like this was not a mistake I made. It was more like I was a victim of a mistake. But I want to highlight through this that there were mistakes that I made, that it was not, you know, I wasn't at the whim of somebody else, a manager in this case, and that there were things that I could have done that would have improved that. And it did teach me quite a bit moving forward, even if you could say that part of it was from a mistake of others. This episode is about, it's a professional mistake, I guess we'll say. And it has to do not so much with technical, but with team building and management and roles and responsibilities and things of that nature. So a little background on this is, this is, in the past I was in this group that we were the software architects group. There was, at the time when I first started there were two of us and we had a chief, I think it was called the chief architect that managed us. And we knew we wanted to grow the team. So the two of us that were there, and we had, we probably went a few months at least where it was just chief architect, myself and the one other architect. And we got to know each other, we knew how each other worked, we knew what the work was, what the focus was, what the needs were. And we started going through some interviews. And we ended up, we had two positions that were available, so we ended up going through a bunch of interviews. And we ended up hiring two extra architects, two other architects. Now in doing so, both of them had the kind of background that you would expect. And when they joined us initially, they turned out to be a pretty good fit. It was, it was not a, they weren't exactly the same as us. And that was sort of by design, which is maybe something that we'll talk about another time, is how to match strengths and weaknesses within a team. So there's some things that myself and the other architect maybe weren't as strong on, but we found those in the ones that we added. And then there were some things where those new people were maybe weak, but we already had those skills, so it wasn't an issue. And we ended up as a team melding pretty well. We moved forward, we had several months or a year, however long it was, that we were working, we were cranking through projects, we were doing stuff, we got into a really nice rhythm. And it got to a point where it was decided that there's, the chief architect was really moving, trying to move towards more outwards facing stuff, selling projects internally, but also selling products to customers where he couldn't really manage the team as much. So we needed a manager. The challenge here, and something to think about if you run into those kinds of things, whether you are part of the team or you are elevating out of the team, I will say, you know, I'm creating a manager out of the group, is that the hardest, one of the hardest things that you run into is when all of the people basically have what it takes, then now you have to pick one where there's, we'll call it roughly, there's some equivalencies there. Well, the decision was made in discussion, the decision was made by the chief architect to make me the manager of the group. And he pulled me aside in one of our conversations and said, hey, I want you to be the manager, but I'm not going to tell the rest of the team, I'm not going to give you a manager title or anything, but I think you're the guy to lead the team and I want you to just start acting that way, act like you're the manager, act like you're the lead, and they will fall in line. This is where we highlight the mistake, is that a position like that where there is value in growing into a position, there is a lot of challenge that comes from growing into that position and being effectively treated as that position without anybody else really knowing it, sort of doing it in stealth mode. In particular, this one caused problems with one of those new hires because he always thought that he was the best of us, that he was going to be the manager. And actually, three of the four of us felt like we could easily be manager and had always sort of been pushing towards that. And out of the three, one of them decided he was also, he was manager based and he had sort of just put it in his mind that he was the best, he was manager. The other one was not, he knew he could be and was just vying for it and he thought he was just competing with me for it. We really didn't expect that third one to be a manager. And I'm digressing a little bit but trying to give a little bit of the context around this and some of the underlying things that were going on because that's what matters or that's what ends up becoming the problem. And you start moving forward and I did as I was asked. That was my mistake is that if I tell you do manager things and act like a manager, that's a really generic and general kind of request. And that's what I was given. And although I had worked with this guy for a while and I had a sense of what he expected, my expectations were probably not going to be 100% in line with his and I didn't stop and ask questions and say, okay, well, what does that mean? How does that really work? How am I going to, how's it going to change what I do right now? And this is, I've seen other issues with this and we'll probably come up with some others along the way in this season, but it is really easy to have a generalized request or a generalized goal, a generalized discussion even. And you think you're clear. You're talking to that other person and you think you're on the same page but you're not. It should be almost like a red flag, some sort of warning sign. When you have a generalized discussion and you're going to turn around and act on that, because if you're not clear, if there's something where you're not on the same page, if you're not in agreement with that other person on what that general thing is, then you could go off and go 180 degrees from where you need to be. This is why when we do requirements gathering, we ask questions. We don't just start with, I mean, we may start with somebody says, hey, I want to make a site like PayPal. Great. Then we start asking questions. Because there's a billion ways you could make a site like PayPal and it has nothing to do with what that person really wants. So you have to dig into that question. You have to say, well, what do you mean a site like PayPal? What are the features or the traits of it that you want to reproduce? And then with that, you can say, well, do you want to reproduce them in the same way? Do they need to be branded? And the question should start to flow. Now, with a product and knowing that we have to build this, that we have to have enough information to create some design or blueprint, it can be easier for us to look at it and say, oh, here's gaps in knowledge. These are things that we need to clarify. These are questions we need to ask. When there are other things like a job, maybe we haven't, we aren't clear on that. We aren't, you know, we don't see that that thing that we're being requested to do is something that we need to ask more about. Entitles and roles do this a lot to us. I think we assign traits and properties to roles and titles within professionally. And they're just certain things that we, each of us individually, see as things that person does, you know, whether it's a CEO, whether it's HR manager or a database developer or a call center rep or whatever it is. There's a picture that you have probably when I say those titles or when I say certain roles that you would have this sort of like, this rough image. There's be something, and there's probably some relativity between what I see when I hear that and what you see when you hear that. But it's not going to be the same from person to person, even when you are in the same organization for a while and you have, like if you're working with someone for 10 years and there's a CEO that's been there for 10 years and you talk about what a CEO does, you will have very similar lists of traits, but you will also have some differences. And those differences could be critical. And in the case of this where it's, hey, go be a manager, go act like a manager, there were things that we, in retrospect, we can look back and say there were things that we agreed upon, but there were things that were different. And what's more important is that there were things that maybe myself and the chief architect agreed upon, but the team did not. They had a different view. And so setting all this up puts us in a situation that ended up being probably one of, in some ways it's a big mistake, but it turned out really well. And so what happened is, we'll call him a disgruntled worker. Actually, we'll give him a name. We'll just call him Bob. So Bob, or we'll call him Dave. Disgruntled Dave, there we go. So Dave also, although was not directed towards it, just decided he was going to be a manager. It would do things like order other people around and try to plan meetings and talk about scheduling stuff. What's probably worse is he would push back when other people scheduled things. So when I had a, I think we did like once a week, we had some sort of regular white status meeting, and we'd go into that and I would start running the meeting, he would sort of decide he was going to take over and he would start talking. He would start running through the thing. If I put an agenda together, then he would come with his own agenda. Initially it was, I think, just lack of, maybe a lack of communication. It wasn't made clear enough when we would walk into such things. But pretty soon it became obvious that he was directly in conflict with me over these things or vice versa. I mean, I guess it depends on what your point of view was. Which would be his point of view, was that I was in conflict with what he was trying to do and to him it was, he thought I was just completely disrespectful of him. And I don't remember if he came up with a reason for it, but he just decided that I didn't like him for whatever reason. And this becomes a problem because now he's really bristling against working with me because he thinks that I don't respect his abilities. And yet now I'm still in a position where I'm supposed to be managing him, but I'm not his manager and he hasn't even been told I don't think that I'm his manager. And we did get to a point where I had discussions with the chief architect and we got to a point where I said, look, this is not working. I'm trying to do these things and I'm getting a lot of pushback because I don't officially have the ability to plan these meetings and to run these things and to have these discussions. It's still for everybody else's point of view, this should be a team thing. I should not be leading and running this. Because they see, and this is sort of the interesting thing, is they would see me take a step that was a quote managerial step and they would say, oh, I need to do that if I'm going to be vying for the manager. Because they saw that as me, which I guess is very logical, they saw that as me trying to position myself to be a manager. So it became a, I will say, it's almost like a one-upmanship. If you see somebody else vying for a position, doing something that is going to promote them as being that position or able to get that, you're going to do something the same. You're going to do that plus more to try to position yourself better. So while this may look like some blame and some other stuff, it really made a lot of sense that it would turn out the way it did. If you have very competitive people and you put them in a position that sort of allows them to be competitive or pushes them to be competitive, they will be competitive. And that doesn't mean they won't work together, but that does mean that they will compete. And in this case, it became a challenge because there were things that, there was not a referee, I guess. So we're competing against each other. And without that chief architect to sort of step in and say, oh no, this is how, the direction we need to take, it really became all of us sort of taking, stating our own position and holding our ground and not being able to get enough consensus to move forward. And eventually it became something where the, what we call Dave, where Dave decided that it was something that he wanted to take to HR. And he complained to them and said he wasn't being respected on the team and that he wasn't being treated right. And that became a huge issue because now the, to me at least, I go back to the chief architect and said, look, now if he's got this complaint that I don't respect him and suddenly I get made his manager, that's probably going to cause issues. HR is going to complain. They're going to say, hey, how did, you know, this probably isn't right. And it put us in quite a challenge because it almost blocked me from taking that manager position. And in my position, my thoughts were that it did because I said, you can't promote me into something over that person because it's going to look like you're now disrespecting and just completely disregarding their thoughts and feelings and professional skills. And so what we ended up doing during this time, the other guy that was competing had moved on a few months before, had moved on to another position because he realized that he wasn't, you know, he realized he wasn't the one made a manager. He wanted to go to a spot where he could become a manager, which made sense from his professional development. He was, he sort of needed to go where he could be promoted into manager in a role. So he went to another job and he wasn't manager there, but he was in a situation where that was, that was definitely a career option for him. And so he was gone. We were looking for some other people to bring in and now I'm in a situation where I'm sort of blocked. Now we were all still connected and friendly and everything with the guy that had left. And so this is where the beneficial step came in out of it. Things were going south at this point. The teams started to fall apart. We're struggling. Dave was just completely useless as a team. He was complete poison to the team at this point because he was just doing everything he could to try to take his horn to horn and not really worry about getting stuff done as much as he was worried about finding a way to get praise for himself. And so, yes, this is negative towards him, but if you were there, you would also probably agree with the negative side, even though that's like a sort of a side thing. Because what we ended up doing is I said, look, I'm blocked from this. This is this poisonous thing is something where Dave's not going to leave. And so I think I need to leave for the good of all of us because otherwise we're all just going to end up crashing and burning within this group. However, they still needed a manager. So what we came up with is went back and talked to what we'll call out great a out that had gone on to another company. And we talked to Alan said, hey, how about we bring you back as the manager? So now he's gone away. So it's sort of an excuse to bring him in or maybe like something's a little more acceptable that now he's being rehired as a manager. And we all knew that it was something he could do. So now instead of the grow into it approach, it's the come in and be the manager. And that was a discussion I had with the chief architect extensively as I said, he has to be clearly the manager coming in. He can deal with this and that way it puts the right label on everybody. Everybody knows where they stand. And then what ended up happening is I was able to swap with Al. So Al came in and took the manager role, the actual now titled manager role where we were at. And I did Al's job in the other company, which turned out awesome for everybody. So while we had this poison pill in the group basically, what ended up happening is Al got the manager role that he wanted and really was at the point where he needed it. And it was a stepping stool. He went on and did a lot of great stuff, continues to do so. Dave ended up being sort of pushed aside. He continued to balk and continued to try to find a way to finagle himself back into a position which he was now pretty much locked out of. Eventually they found another team for him to get moved to. It was a small team where it was mostly just him doing his own thing. And I don't even know if he left or quit or what happened, but he sort of just got pushed aside. It was almost literally, if you think of the office space, the guy that was still there, they never fired him and he still just kept showing up and they kept pushing him into worse and worse offices. And I think actually the last time I saw where Dave was at, he was like literally in a basement office without windows and doing his thing. But he was sort of close about it and did what he did. Myself, that turned out to be great to be able to go to that other company. It was a good experience, got to meet a lot of people. And it positioned me very well for the next, especially stage of my career because this was about the time that I went into a much heavier consulting role that eventually really pushed me to be full time running my own company and things like that. And I don't think if that, I think if those things had happened differently, I would not be in the situation I was. Effectively, that mistake blocked me from being sort of more upwardly mobile within that company. I probably would have stayed with that company. They got sold a couple of years later and my career path would have been very, very different. And since I'm pretty happy with the one I have, which also introduced me to sort of the path that created Develop-a-Nor. So it probably worked out well for you as well because we have the podcasts and all of the other things that we have that really would not have happened had that mistake not been made. And it was, I don't want to downplay it, it was rough during that time. I was glossed over it. But when you have months of tension and struggles and you've got a lot of, we had a very rough schedule. We were working minimum 50, 60 hours a week. We had a lot of press, a lot of pressure, a lot of stress on us to get things done. There was, we were doing a lot of research, new kinds of things. So this wasn't a menial task. This was stuff that was pushing us. So I get to the end of a week and I was mentally, physically, emotionally exhausted. So we were doing all that and we had all of the interpersonal stuff. So it was not a fun time. It was quite a challenge. But I can look at just about everybody except for Dave and look at everybody else on that team and they grew out of it, learned a lot and have progressed very well in their careers. So even if you're in the deepest, darkest valley of death on some horrible project, it may be that that light at the end of the tunnel is a really awesome light for you to walk into and it's not a trend. It's that you're going to be able to step out of that into a great career advancement, great opportunity to learn, to use what you learned during that time and don't ever write yourself off or those around you. And then one of the stories is go ahead and own your decision though. If you're going to make a manager, if you're going to be a manager or if you're going into a role where they said this is what we want you to do, push back, which was my mistake, is push back and get clarification and say, you know, I need to make sure that I have the tools to be able to do that job. I need to have maybe either the position or the respect or something that if I'm going to go get others to do things for me, I have to have enough clout or weight or whatever to be able to do that, to not have them just say, no, I don't want to. You've got to be able to somehow make that happen. And the original thing is don't step into a job just with or in its job, task, whatever or role and just go by like a simple label. Labels are helpful but also useless. They cause us a lot of pain because we don't dig into what that label means to the person that's making the request. So if you're hired for a senior developer job, ask them in that interview, make sure you ask, what is this actually going to entail? What is my day-to-day job going to look like? Because those are the things that are far more valuable than a title or a role or something like that. That being said, we can wrap this one up. So go out there and have yourself a great day, a great week, and we will talk to you. Thank you for listening to Building Better Developers, the Develop-a-Noor Podcast. You can subscribe on Apple Podcasts, Stitcher, Amazon, anywhere that you can find podcasts. We are there. And remember, just a little bit of effort every day ends up adding into great momentum and great success. Hi, this is Rob from Building Better Developers, the Develop-a-Noor Podcast. We're excited to be on Alexa now. You can enable us by simply saying, Alexa, enable Building Better Developers. And we will be there ready for you every time you want to listen to your now favorite podcast. Whether we are your favorite podcast or not, we would love to hear from you. So please leave a review on Amazon. Now back to the show.