Making Decisions and Moving Forward

Welcome to Building Better Developers, the Developer Nord podcast, where we work on getting better step by step, professionally and personally. Let's get started. Well, hello and welcome back. We are Continue Our Season where we talk about mistakes and missteps and how to learn from a moment how they may have been stepping stones to advancements and improvements and things of that nature. This episode is really, unfortunately, focused more on some of that I've worked with and a mistake they made. And I've probably made, I'm sure I've made some more mistakes, but this one just highlights it so well. It really hits on it and it's not, there's really not any subtlety in it, which is what makes it really what you know, a mistake in an era I want to cover in order to talk about the key aspect of this lesson. In this job or in this situation, and this was a professional one, we had a team. This is one that was a team that I managed and we had, I can't remember the exact number, I think we had about a half dozen of us overall that were part of the team. We had, we're sort of a newly formed team. We had, they'd had a single developer maybe, well they had a developer with a couple contractors. The contractors had rolled off, that developer had left and then come back and along the way I had been a contractor there and then brought in and then was advanced up to a manager of the group as we were shifting around responsibilities and roles. So it was sort of a, well it was a team and software, or it was a department and it was software and products that had been around for several years and we had some of the team members had been involved in it for quite a while. It was also sort of a, it was one of these things that was a good time to maybe do some reviews and retrospectives and change maybe how we did stuff. Because we had enough new people, we had a little bit of a change in our focus. While we still had all of this, what we call legacy stuff to deal with, we were also in a position where if we were going to make any changes, this was a time to do so. Now one of the things that is the key story here, one of the things we looked at was version control. This was a time where a CBS and Subversion were still pretty heavily used, but there were things like Git and Mercurial and some of these other newer tools, the distributed version control tools that were out there. And what we did is we said let's take some time and look at the strengths and weaknesses of these various tools and see if this is a good time to change our version control tool. And we looked at, there were some other ones, I'm just naming a few off the top of the head because I think we also looked at, I think Microsoft had their one like SourceSafe, I think is what it was called, was the earlier version but there was also eventually I think Microsoft version control, something like that. That's really not as important. What happened is we as a team, we went out and we evaluated these different things. We spent, I don't know, maybe a month looking at these various tools, doing some research on them and then came back as a group and had a couple of meetings where we discussed the pros and cons of all of these tools. Other than this getting into a technical discussion, I'll sort of fast forward through that. And we came to the decision that, I think at the time we used subversion and we came to the conclusion that we needed to stick with subversion and a lot of it just had to do with we decided that Git was a better tool. I think as a team we all decided, we agreed that that was a better tool. But in looking at it, the loss of history that would come from converting over and the general pain and suffering of converting over, not to mention the fact that subversion is server-based whereas Git meant we would have used up more space on clients to do all the local repositories. Those factors combined to us realizing that really even though we wanted to move to that, to get into newer tools, we saw a lot of value there. We realized it was going to be too painful, the loss was going to be too much and we were sort of, for lack of a better term, we were stuck with what we had. And it just wasn't something that we were willing to take on the amount of work for what the benefit would be. We basically as a group decided to table the discussion and say, you know what, this is something we would love to move to at some point in the future but for now we need to stick with this. Well this is where we come to the error. One of the guys on the team decided that nope, that was not his... He was not going to agree with the decision. He was considering it the lone dissenting voice. Even though we generally all agreed on stuff, we came to the decision that we were going to move forward with what we had and he disagreed. And he continued to disagree even after the decision was made. That is where the mistake was made. We as teams, as groups, even as individuals, we make decisions all the time and we have to make a decision and move forward from it. Otherwise we end up with analysis paralysis or something along those lines where we are blocked from moving forward because we fail to really make that decision. And we can keep reanalyzing, reviewing, analyze, and review and never make a decision and it ends up in effect making a decision of just stopping where you're at. We weren't in a position to do so. We had stuff to do where version control was not... It was not worth it for us to just stop everything and figure that out. And we also had a person who was basically outnumbered. We had all sat there and discussed that, yep, the approach that he wanted was technically the best. If we were starting from scratch, we all agreed that's the direction we would go. The disagreement was that we had to stick with what we had. This became a recurring theme for him is that in just about every meeting we had moving forward, he wanted to refight that battle. As he would come back and he would just, once again, he would start finding some excuse to talk about why we really needed to be using Git, we needed to get off of the system we had and would just rail against where we were at and try to argue that no, we need to move forward. Eventually, he even got to the point where he complained to... I was the manager of this group, he complained to my manager who really, probably to his credit said, no, you have no say in this. This is what Rob decided as a manager. This is the direction the team's going. Basically it's that way or the highway. Basically it's one of those sorts. You have no choice. You have to go with the team decision. That's just part of working with the team. It's not necessarily... I am not at all going to argue that that was the best approach or anything, but it was in our situation we decided this is the path we have to take. Right or wrong, which is really not the point of this discussion, right or wrong, we made that decision. Now it's one of those where once you make the decision you need to move with that. Otherwise you're pretty much just hampering yourself with no real reason other than trying to go back and refight that battle. Sometimes you have to take the L, take the loss and move on because otherwise that past loss can anchor you to something and keep you from moving forward. That was a mistake that was made here is that he ended up... He's a good developer, was personable, was the kind of person you want on your team. It's one of those that you probably don't want two of him on your team, but you definitely want one of them on every team. It's just not two because if they ever butt heads and it's just sort of as this thing shows you end up getting blockers. He was a great member of the team so he really wanted there. It was one of those my manager initially was like, just go ahead and fire the guy. I was like, no, that's not... Just because he disagrees and he was sort of new. He wasn't as seasoned as he could have been. I said, this is just something that's growing pains. We'll figure it out. And eventually we did, but it took multiple times of saying, look, done, stop. Don't have this conversation. We've made a decision and we're moving forward. You will not win. All you're doing is wasting your breath and wasting our time. And there were a couple of times it had to be pretty blatant of basically like he would start into something. He was like, no, stop. Don't go any further. That's not our discussion. This is what we're talking about. Don't even mention... I think I was like, don't even mention get. Don't let the word leave your mouth. Because it was just, it got to be that almost tense through it. He was like, no, this is the direction I'm going. Sorry. And it was very difficult, I think, for him to hear it because we would say, we agree with every point you're making except we have to go this other route because we are not willing to invest the time, the money, whatever it is in making that change. And so the mistake he made was not accepting a decision and then going back and questioning it and whether this is a team thing or what's probably more likely to happen and really drag us down as in our personal life where we make a decision but we don't really make the decision. And halfway doing things is a huge drain on us because we're doing it but we're not being as productive as we could have. And so there's like an extra cost that we're adding on top of that thing that we wouldn't need to. It'd be like if you were going to try to stop smoking but as part of it you're just like, well, I'm not really... I'm going to stop smoking but maybe I won't smoke today but then next morning you get up and like, I'm going to go ahead and smoke and I'll just sort of work on smoking less or something like that and you just keep going back to it. Or if you're trying to train for something physically and some days you train and some days you're just like, I don't really feel like it and what ends up happening is those days that you say, I don't feel like it, you have to sort of make up for it that next day or the next time you do because you didn't improve yesterday. You may have even gone backwards a little bit yesterday so now you've got to make up that lost progress and try to progress again. So you could get into something where it's always one step forward, one step back, one step forward, one step back as opposed to one step forward, one step forward, one step forward. This is why we talk about incremental progress so often and momentum and just continuing to make forward progress on your goals and your objectives. Because if you halfway do it or if you decide but then don't really decide and keep questioning your decision, you're going to be wasting effort on refighting that battle that at some point you already decided what the result was. You can't just, if you want to keep going back, politics are a great way to look at it, is it doesn't matter what your view of an election is. There is a little bit of time after an election if somebody wants to dispute it that they can but if they continue to do so, there becomes a time where just about everybody says, look, that's just, the decision was made whether your arguments are valid or not, we're all ready to move on. All you're doing is trying to refight that battle that somewhere was declared loss. And we'll see this with people that are stuck in the past all the time. It is putting current effort into the past where it's pretty much already useless, it's already wasted effort. I'm going to keep this one a little bit shortish because that's really the goal and I don't want to belabor the pain point much more than I already have. So maybe just think about it, that's sort of like a rare of this season challenge maybe is, is there something that you decided but now are questioning and it is maybe dragging you down or holding you back. But other than that, go out there and have yourself a great day, a great week and we will talk to you next week. 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. There are two things I want to mention to help you get a little further along in your embracing of the content of Develop-a-Noor. One is the book, The Source Code of Happiness. You can find links to it on our page out on the Develop-a-Noor site. You can also find it on Amazon, search for Rob Brodhead or Source Code of Happiness. You can get it on Kindle. If you're an Amazon Prime member, you can read it free. A lot of good information there. That'll be a lot easier than trying to dig through all of our past blog posts. The other thing is our mastermind slash mentor group. We meet roughly every other week and this is an opportunity to meet with some other people from a lot of different areas of IT. We have a presentation every time. We talk about some cool tools and features and things that we've come across, things that we've learned, things that you can use to advance your career today. Just shoot us an email at info at develop-a-noor.com if you would like more information. Now go out there and have yourself a great one.