Todd Williams was our special guest.
His Twitter: @BackFromRed
Transcript
[00:00] Yegor: Hello everybody. This is Shift-M podcast episode 34. We have a special guest today, Todd Williams, and I will ask him to introduce himself.
[00:11] Todd: Hello everyone. I’m Todd Williams, I’m a project manager has been in the field for a number of decades. I don’t think I want to admit how many, I have written a couple of books, rescued the problem project most recently from the execution gaps which talks about how projects can have problems and how to get around those problems. The types of problems we have to deal with. Many times people think it’s all technology and more often than not it’s people. Even then quite often it’s not the people on the project, so there’s a whole area of things that I would like to explore and work with. I continue to consult people and with people and companies around the world. Enjoy being here. Thank you very much.
[00:59] Yegor: Thanks a lot. And the subject of this podcast will be about respect in project management, which is something we never talked about on the last 33 episodes and it’s quite interesting today to bring it up because in my experience like you said the problems are always on the people side most cases, not the technical side. So what do you think in general do we need this sort of thinking in project management in general or it’s something personal which we shouldn’t discuss in serious project management books and articles. Respect, I mean.
[01:34] Todd: Well, respect is extremely important and probably people first stumble on the fact that they don’t respect the capabilities of the project manager, because maybe the project manager is not a technical person, maybe you’re on a technical project, so you’re dealing with a whole bunch of people who are developing a brand new they have all the best bells and whistles. They know everything about them. Maybe they even help develop those, and a product manager comes along of course, that person be it male or female doesn’t know nearly as much about the technology, as the people who are building it and so there tends to be this “Well why should I listen to you”, at the same time it goes the other direction where the project manager is looking at the people that are working on the project and say “But you don’t understand how this works, you need to follow this, you need to do that” and there doesn’t seem to be a respect in the other direction. To make matters worse, there’s the people around the project. Maybe the Project Management Office or the executives, or the customer, who is frustrated with the overall project or wants to see it better there and there, may be losing respect of the team. So it’s in many-many directions.
[02:55] Yegor: You know what happened to me yesterday, I was at the meetup for programmers, there were like 150 people in the room and they were all programmers, and I asked them a question “Who of you think that project managers actually want to do things right and they care about the quality of the software we develop?” and maybe 10 people raised their hands and then everybody else in the room started to say that the project managers want just things to happen faster. They don’t care about quality. That’s the perception, that’s the opinion programmers have about project managers. What can you comment on that?
[03:30] Todd: Well I can see where that perception comes around. I mean the project managers kind of in this bind of trying to make things right versus make things inexpensive, right? They have a budget, they have to [inaudible voice 3:52] they have timelines after a year or two and we can strive for perfection. And I think most of us know that if we strive for perfection, I have a hard time saying that, if we strive for perfection, we will probably never get the project done. So there’s this continual balance that has to go on. There is a company out there, a small company that somebody probably heard of before called Microsoft and they really made it by not looking for perfection. They really did make it by understanding what was good enough and getting that released and most of us hated that. And those of us who are old enough to remember things like Windows 1 and that sort of things were really frustrated because this seemed like a product release and it would just be bug-laden, that they couldn’t go for perfection. They realized that they had to get things out, they had to get to the top, I don’t know 90 percent of it working, and no work on the other 10 percent later. So quite a few of us to this day still won’t load new operating systems until new versions until Service Pack 1 or 2 comes out, still have age just a little bit like a fine wine. They got quite a bit better. So there is this balance that has to go on that creates a huge amount of technical debt. In a software project or even a hardware project they can easily be turned around and fixed later, that needs to be understood. And I will say pretty clearly that I don’t think many project managers fully understand technical debt and I am most certain that most businesses don’t fully understand the technical debt and what that means and allotting the time to go back and actually make things right. So the challenge to the project manager now is to work not with the team as much as with the customers and the executives and saying “Okay, we can get it out fast, but we have to have this other time to be able to go back and clean things up and get technical debt out of this software.” So there is a battle there. So I am surprised that there were as many people saying that there was no concern about quality. I think that there is a balance that we have to do where we figure out what the MVP, the minimal viable product is and be able to get that delivered. You know I think that’s really where things need to go. People need to be talking the same language.
[06:33] Yegor: You’re absolutely right about mentioning technical debt, actually the meet up yesterday was titled “What to do with the technical debts?” So you hit exactly the point which we discussed yesterday. But my question now is why it’s happening, why all of you, well everything you’ve just described is happening. Project managers are stupid or programmers are stupid? So who’s making the mistake?
[06:48] Todd: I don’t think anybody’s stupid. I think that’s the wrong way to look at it. I’m sorry for you if you turn around and look at people’s focus and what people really want to do and their drive. They have a focus on certain things, right? If you have kids you realize now and then the kids focus on something and maybe it’s a toy or maybe it’s getting in trouble or whatever. And you as a parent want them to go some other direction. Quite a few times that doesn’t work very well. So you have to as a parent come in and try to get that person coaxed into another direction, right? And you have to lure them over and maybe you actually can become heavy handed but in most cases you can lure them over and leave them in the right direction. And I think that if you are as a project manager more open minded, then you can educate you team on what needs to be done. I think the communication is very poor in most organizations in trying to understand what the objectives are and what a minimal viable product is. I mean I don’t hear a lot of the companies using minimal viable products in the realm that I work. I don’t use that term a lot. I try to get things narrowed down to where we’re delivering that minimal viable product because I need to get that respect by the people so as a project manager I’m always trying to get harmony going on inside the organization. And that usually takes a significant amount of communication. And I probably spend 60 or 70 percent of my initial work on a project at that level working on both sides with the executives, the customers, the general stakeholders and the project team trying to get them to understand one another and communicate. And I’m basically a facilitator in that process trying to make things work. I’m not the conduit, I’m the facilitator.
[09:13] Yegor: Don’t you think that programmers are not disclosing the full information about the technical debt to their managers, because they don’t trust or maybe slash don’t respect those managers and they just don’t want to disclose that information to make it visible so they just, you know, because they think the project managers anyway will not do any good, because they only care about the speed of delivery only about, so maybe it’s better to keep that information to ourselves and just deal with that somehow and never tell the managers that, maybe it’s a problem of respect and trust in management layer and technical layer.
[09:41] Todd: Well again I don’t want to put blame on any one person. Is that a piece of the puzzle? I would agree that that’s a piece of a puzzle. Nobody wants to go out and tell their boss “Hey you know I did a really bad job on this thing.” It works but it’s really sloppy that it doesn’t go over well. People don’t want to say that. So there is that tendency to hide that information. At the same time there is people over on the business side who don’t want to admit that they don’t understand what technical debt is, they don’t understand that there’s things that need to be fixed later. I usually try to take for the executives, stakeholders, customers, whoever and use a more physical example of building something and saying “Hey, you know, you build a house, you want to have five rooms in the house, but you got room in the money for three. So you build two or three rooms that you can afford and you put in a stud wall that just kind of shields things so that in the future you can put those in other rooms and at some point you’re going to go, have to go back and fix it. Or maybe you don’t put in the best flooring that you want in the house and you want to go back in the year and put in the new flooring. You have to still budget for that. You still have to do a lot for that. But it’ll live with the downgraded flooring or the least, the lesser fancy appliances and you’ll come back and you’ll put those nicer ones in later. Well that’s what we’re trying to do with the software, is we can get it times quicker and cheaper with this inexpensive method, but it’s not going to last for years. It’s not going to be as robust as you want. Now let’s go back in and a lot of the time and schedule the time and budget the time to fix it. That doesn’t happen with just me talking on one side or the other. I have all the groups together so I have the stakeholder who is me, the customer, whoever and the developers in the same room together so they hear it. If I act as a shuttle going back and forth between these two groups, I end up creating distrust because people will say “Well what did you really tell them? Well what did you really say to them and what other sleight of hand is you up to?” So why keep it open where everyone can see what’s going on. That starts to build respect, not just of myself, but of the other party, because you’re starting to hear things and I will help interpret when someone starts talking technobabble that executives not gonna understand. Then I translate that down so that the executive can understand, when the executive starts talking about their ebitdas and every other business term that they want to talk about, I will turn around and say “Hey wait a minute guys, don’t you understand there has to be some sort of earnings here that goes on”, so that you know the company looks profitable, that shareholders, stakeholders, testers are happy. And so, how can we meet in the middle? So I’m working that together as a facilitator to make things happen. Does it make sense?
[13:13] Yegor: Yes, it makes sense. I’m trying to think about what is the… So it seems that being the facilitator and being a good facilitator is something which I if I’m a programmer will respect my project manager.
[13:41] Todd: I would hope so. It works for me.
[13:43] Yegor: Because that person doesn’t have any technical… I’m trying to put myself in the shoes of the programmer, thinking about like abstract project manager, and that person is telling me some stories about deadlines and risk analysis and there’s a [inaudible voice] you mentioned, but my language is completely different.
[13:58] Todd: Exactly.
[13:59] Yegor: Well how am I going to respect that person talking some gibberish you know which I don’t even understand? So I need to somehow believe that he or she makes sense.
[14:10] Todd: So that’s part of that whole translation. That’s why everybody’s in the same room. They see the translation going on. You see somebody saying something they really don’t understand. They don’t want to say they don’t understand it. And that comes from both sides. I mean executors not gonna say they don’t understand technical that just like a programmers’ not going to unnecessarily say they don’t understand ebitda. And so when you’re sitting in the middle you’re translating that stuff, people see that you’re being honest, straightforward, they can correct you if they want to, you translate something, some term and they know that’s exactly what it is, they think they can straighten that out. And so they feel like they’re part of that. So you start earning that respect and be able to make that happen. They also respect you as a project manager because of the fact that you do understand both sides of the problem. You may not understand how to solve some technical problems, you may not understand how to increase all of the actions that are going to increase the earnings per share or something like that, but they do respect the fact that you understand what the concept is and that you’re understanding that you are part of that. It is an interesting factor that also goes on in that and that is that the person especially the technical people are lower level people in the company that are to be technical. What could be happening in any project - the people who are lower level down in the organization generally don’t understand how what they’re working on specifically benefits the company. And so now all of a sudden they’re starting to see that connection. And quite often we’ll see them come up with a different idea and say “Well why are we doing it this way? Why don’t we do it another way because if we did it this way then you actually get to these problems solved instead of the way you told me to solve it which is not necessarily the best way to solve it.” So there’s really quite a few things that can go on. Usually this takes a couple of weeks to get things kind of moving because you have to… So let’s back up a second. You got to remember I come into projects that are in general in real trouble and they’re failing. So it’s not just there is no respect. There’s distrust. People are finger pointing and they’re blaming one another. So I have to kill that. And quite often I do that by starting not with the project team that I’m assigned to manage, but with the customer or executive in trying to understand what their problems are, because if I can get them to understand some trust and get some trust in the team, then I can get the team to do something to earn your trust and then I start getting a snowball effect, right? But I’ll work with both teams for maybe a couple of days by themselves know start doing merge meetings where I am trying to attack some of these problems in more of a forum, than me doing shuttle diplomacy. So it takes some time. It doesn’t take a huge amount of time, but there’s a real process since you can go through to build that respect, and minimal viable product or just try to get somebody from a technical team to deliver a demo of even the simplest thing to show that there’s progress is huge. I mean I was an advocate of agile long before it had that name back in the late 90s and early 2000s I was continually saying “Ok let’s just give me three weeks to get you something and I’ll show you what it looks like” and I work with the team and say “Ok let’s get a prototype up, let’s get something, a wire for… I don’t care what it is. Give me something that we can demo to show them how things work. There doesn’t have to be anything behind it just that ferment and then we’ll help them work through getting the stuff done.” After and I got a lot of pushback for that people on both sides, would come back and say “Wait a minute this is useless.” No, they were trying to build trust and respect. The product maybe is useless, this may just be hollow. It’s something they could see and touch and feel. And that’s where most customers have problems and technical projects is they want something they can see and touch and feel. That’s why agile is so valuable.
[18:40] Yegor: Well it does make sense. But I want to get back a little bit to something you said about resolving the problem when there is no respect. Well I remember a situation where I was in the project and we lost the project manager, so he just quit. And you know he was hired by another company, and we got another person, another dude who became project manager. But we loved the previous guy. We’ve been working with him for over a year. So we loved the management style he had, he had enough respect from us. And then you, guy, didn’t have anything. Not disrespect, but not respect as well. And there was nothing we didn’t know him. So I remember how he started to build that respect and it was mostly through sort of authoritative message to us. He started to you know tell us what to do in a very direct way. And then and now I want to ask you to compare the two styles of management. I know there is a management by respect so-called, but there is another management style which is more you know which we inherited from the military where people are just being told what to do. And there is no need of respect. I already have respect since I’m a manager. There are two different styles of management, so what do you think, which one should be applied when there is no respect so far and it has to be earned?
[20:03] Todd: Well I’m not much for management. I’m a little more along the leadership style so the directive authoritative style of management or leadership for that matter is something I shy away from, except for very specific cases. From what you just described, I’m surprised it worked if it did because generally if a team is moving along and there was respect, and there aren’t major problems which I’m from the way you described it, it doesn’t sound like there were major problems, coming in with an authoritative directive style, generally doesn’t work. You want to come in and be much more associative meaning that you’re saying “Ok I have this team that does great. This team does great. This team is great and this team does great how that’s assess them and figure out?” If asked for them, get information from them on where the holes are and where I can come and help fill and move forward. That would be my approach. And of course we’re talking about styles at this point. If something were to go wrong. So like I say I come in quite a few times to projects that are in trouble. I generally do start out in very directive mode in those because there are things that have to be fixed. There are major problems I figure what this problems are, I generally hire to fix you know three things. There’s usually 20, but are going to start attacking those three things and I do become very directive in that situation. That last for maybe four or six weeks if need be, because what I want to do is get into that directive situation to solve the problem, figure out who can handle those problems and then hand that issue off to them for them to fix it, for me to support them fixing it. You walk into your drive down the road and all of a sudden two cars collide ahead of you and you’re the first one on the scene. You get to the accident scene the very first thing you do is to look to make sure that there’s no fire. You make sure that if there’s no fire that you make sure that we know who’s the worst person there that needs help and you don’t turn to the second person who shows up at the scene and say “Here I think it would be a good deal, a good idea to call the police and get some help here.” You look at that person, you say “Call the police”, you give them a very-very directive order you don’t have a discussion about it. You tell them what to do as you move or you start figure out what the situation is you have fires put out, maybe some help comes along, maybe you stop the person from leading. You get people in a safe location. Now it might be a situation where you back off and ask for opinions. So if you’re in a location the ambulances or police haven’t showed up, you get everybody out of the car because sitting off to the side of the road you say “Ok we’ve got two other people here. What do you think should we get these guys into a car, should we move them or leave them sitting here? Which one do you think is safer for the person? And now you start soliciting information because you’ve got everyone kind of in a stable situation, right?” So I think that walking into a what you described as a stable situation all of a sudden being directive would not be the best way to handle. I mean I think I will go as far to say I think a blow up idea. I think that you would end up getting pushed aside say “Well who is this person and why she or he told me what to do with that. We’ve been running just fine.” And I’ve seen that happen in quite a few places where new bosses come in and they start trying to lie their mess on top of things, you have to come in a little softer than that into a situation as well.
[24:10] Yegor: Well you’re absolutely right about exactly what happened. We lost like 30 percent of the team, because the best people actually have left, some of them you know for the previous project manager and just that they were hired by the new company and some of them just quit because they didn’t like the new management style. But you know in the way they describe what happened, they said “We didn’t like the message”, so they were not educated enough to explain that. I like the previous management based on respect. And now the management is based on power and I don’t like it. That’s why I quit”, they just said “I don’t like this dude. The previous one was better, I’m leaving, I’m going somewhere else.” That’s what happened. But I can explain why that new person was doing that. As far as I understand, I never asked them that, but I think that he was afraid that the team which was doing pretty fine, you said it right, the team was quite stable and it included quite senior and experienced people which knew what they were doing for a few years and he’s coming to a stranger. So he had to somehow get the power into his hands and in order to get that power, he understood that he can do it, he can earn the respect because of his successful operations in the area facilitation, in the area of successful projects that will take like half a year, but he needs power because otherwise the power will be in the hands of the developers and then he will lose everything including the respect, that it will take some kind of urgent operation to get the power in the hands, maybe even at the cost of losing some part of the team. I think so.
[25:49] Todd: Yeah, but I don’t think that works. I’ll be really honest. You get far more power by me investing power into the team. If I can get my team to be powerful and I have my developers my QA, my designers, all the different groups that I have and I give them the power to be able to do things, I absorb that power. I end up being extremely powerful because I have a team that is extremely reactive or can react to situations, they are not reactive, that’s the wrong word to use. They’re able to react to situations, they are very predictive. They can see what’s going on. They can sense the pulse and we’re I now gain that power because I go back to the executives, the customers, whomever and they say “Oh my gosh we made a mistake, or we want to go this direction” or whatever reason they want to change direction. I can go back to a team or say “Okay, customers out again. How can we do this?” And the team with their power comes back and says “Well we can do this. We could do that. We could do this with four or five different directions, get everybody in a room and we solve it” and all of a sudden the people who are the executives, the people with the money, the people who control the time and everything else go “Wow you are great.” I love it and I end up with this huge amount of power because I’m not trying to do the developers’ job and I am trying to leverage their power to give me the power that I need. Back to the very first thing you said was also that project managers want is on time and on budget. That’s not really a project managers’ shtick. That’s really the customers’ and executives’ desire, right? That’s what they want and so what we’re trying to do is project managers facilitate that, if I now have the power to move that around so “Hey that’s going to take another week, consumers as well.” If that’s going to take on a weekday so be it. It’s gonna take grant, okay. That’s what it’s going to take. If I can get to that point with the executives where we go back with a request and I get more time, more money, however it is then all of a sudden now to the team, I have an immense amount of power. If I could do that because they don’t ever see it right they don’t see project managers doing that. But if I try to take the power away from a developer who says “We need to do it ABC” and say “Well no, I want it ACB.” I’m not going to gain respect. We’re not going to move fast and I’m just playing in our trench. I need to play to the strengths of what I should be doing which is trying to act as this facilitator to keep things moving forward and efficiently. I need to be a leader, I need to maybe be a stronger leader than the people who are supposed to be leading this in the executive role. So that’s I get more power by having a powerful team and by allocating that stuff out. If we’re in an urgent situation, yes, I will definitely jump in, I’ll be very-very directive, you know, and tell people very draconian things like “I’m sorry but you’re not going to talk to the customer, it’s only me who talks to the customer.” You know I cut off communication just so I can get all the communication, so I know what’s being said. So I will have my team being dragged around, so I’ll do very-very directive things initially that those don’t last very long. I pull off real fast. I’m just trying to get a handle of what’s going on. I would never do that in a situation where the project is running well.
[29:52] Yegor: Yeah. It definitely makes sense but I think we’re understanding the word power from different angles. What I mean by power is sort of the way you can rely on your people, like in your example about who’s talking to the customer, when the new manager joins the team, he doesn’t know what’s going to happen with these people and how and where they are ready to betray him. I’m using this word, you know maybe it’s too strong, but still it may happen. So times you join the team and you say “Hey guys I’m your new manager. My goal is to make the team successful blah blah blah”, but there are 50 percent of people who hate you personally because they don’t know and they are ready to betray you in any possible way. They are ready for example to go around you and talk to the customer, because they know that customer, and you don’t know the customer, so they just go there, say something unconsciously, but something wrong and bad about you, which will seriously damage and jeopardize your position in the company. And then tomorrow you will be fired by your upper management for the reasons you didn’t even expect, because your people were not under your control, your people didn’t trust you. Your people didn’t even expect to trust you because they didn’t know you. They never wanted to be loyal to you. So they may do things which will damage your personal position. And that’s why I think so. That’s why the manager I had that example wanted to get the control over the team and he was ready to lose some people, even good programmers, even good developers. But those people who are not loyal to him and he wasn’t able to rely on them. And that’s why he started to do this directive authoritative management style.
[31:33] Todd: Ok so you’re telling me that situation, now that I understand what you’re saying here. I think a little bit better you’re talking about what I would call subversion and that is where someone on the team is intentionally trying to subvert what you’re doing, and go around behind your back and that is a different situation. So if I find out about any of that, then I become very directive with that person. That’s a situation that has to be solved. One of the problems I do have and I have had numerous times is the what I call the prima donna syndrome where there is someone who is a developer who thinks that he or she is better than everyone else, needs to be the center of attention and everything has to go through them. That is the antithesis of a team, that’s actually destructive of a team. And if I see anybody who is doing team destructive behavior, then they see a side of me that they probably really don’t care to see, because I’ll be very-very negative on that. I will do everything I can to shut that down, including in regards to who the person first asking them to leave the team. I’ve taken a couple of people that are truly destructive to the team and moved them off the team. If they’re destructive toward me, that’s not necessarily a reason to go after them because they’ll destroy themselves, but if they’re actually destroying the team and in creating a situation where the team’s not functioning as a team, or the group of people isn’t functioning as a team, better said, then I will actively work to get rid of them off, I’ll get them off the project, yes.
[33:32] Yegor: There you go. That’s what I wanted to hear, so we cannot just be friends to everybody just because we want to be friends, it’s case by case.
[33:43] Todd: That’s part of being a leader, in the same time let’s again, I don’t want to just point out the project team, right, and the technical people, because I’ve also had customers and executives be in that same realm where they don’t want you know I’ll end up with a room of five stakeholders and I’ve got four who want the product and other one who wants to kill a project. And they’re adamant about killing the project. They’re derogatory toward people and I will do whatever I can to get themselves removed from the project. If needed, right, there’s always time whenever you want to have somebody who has an opposing view on the team, because he thinks in check, they can be bringing a level of reality. But if those people are turning around and being negative to people, doing personal attacks of the team members, all worked to get them removed from the team and I’ve gone 3 or 4 levels above me to get people removed from the stakeholder team, that were negative in a negative way. If that makes sense. You know there’s a way to say “No” and not say “Hey it’s all your fault” and finger pointing. There is a way to do that and say “No” and be constructive at the same time, and I don’t mind that. But if people are being destructive from the executive ranks, then I will turn around and do what I can to quelch that, and get get rid of that as quickly as possible.
[35:33] Yegor: It sounds like it’s a very thin line in a grey area between somebody being negative and ready to be fired and somebody who is just trying to respect you more and trying to trust you more, but in order to do that, he has to challenge you a little bit more. So he needs more information, see more results of you because he doesn’t know you yet. So he’s trying to. But how would you define where is the border between somebody who definitely has to be discharged and somebody who is just trying to understand who is who and that’s why asking questions, including negative questions, including challenging questions?
[36:13] Todd: I don’t know if you can define a specific line and say if you say is versus was said and that makes it that way. It’s a continued behavior. You know there are people who are truly destructive. And I’ve had a couple of situations where I’m dealing with somebody who’s truly destructive and they destroy themselves either because of the fact that they make someone else mad and someone else says “Ok you’re out of here” or they leave the company or organisation and move on, which is fine with me. There are other people who just have personalities that are rough and you just work with that person and say “I know you’re trying to do the right thing and I can see what you’re trying to do. But can you be a little softer about it?” and you may have to work with people, to try to soften those, you know, how those people interact. Sometimes you maybe have to kind of push them out of some of the meetings so that they don’t ruffle feathers in the meetings, there’s a slew of different things that you can do to make that happen. I prefer trying to keep people in the meetings and try to keep them active and try to get them to to bring their tone down and make a change. But there is a line that I cannot define as a line that if you cross that you know he repeated native statements, statements behind people’s backs, that’s a big word, if you start making statements behind people’s backs and then it doesn’t take long before I start working to find an alternate solution, right? Because that’s just destructive to the team. Man I have team members, three or four team members coming back and saying to me “Hey I can’t work with this person, then why is that person in the team?”
[38:14] Yegor: You know I totally agree and you know I’ve read some statistics about why startups and IT projects and software projects fail. And one of the reasons, all the top reasons is personal conflicts between people, but let’s think about trust between team members. Between programmers for example, respect, not trust, respect. So let’s say you’re a manager and you see the problem, you see that one person doesn’t go along with another person, even though they are good programmers, both of them. They do a good job. They work, they produce good result. They are technically competent but they have different personalities and they constantly fight in the office. And because of that the whole office’s constantly in stress. So what do you do and maybe you can give some examples of a real situation?
[39:06] Todd: Well, so you know in situations you sit down and talk with the people and say “Hey knock it off.” I think that whenever you make a move to remove somebody from a project, quite often you end up gaining more respect from other people, than you would do and you would expect. So an example I did have a person who was fairly well respected when I first came onto the project. And people always talked about this person. It was a number of years ago so let me make up a name here. We’ll call this person Shawn. Ok? And people would look at this person and say Shawn was a team player, he did things for people, there’s a variety of things we may always talk fairly positive about him. And I kept seeing things that weren’t quite in line with that, and I would get a lot of pushback from him, a lot of negative, and I’d start hearing undercurrents, before too long I ended up finding that he would do favors for people depending on where they worked and what they did in those favors were all of a sudden really kind of making other people in the team upset. So maybe he’d open a part in a firewall for somebody, so they could watch something on their computer, that nobody else could watch. They would order stuff. In fact I actually had a POS is the one that tipped the case on this one is they actually got a purchase order across my desk and the part number and the description didn’t quite make sense to me, so I called up the vendor and found out that he had changed the description of the part he was buying, so that it would look more suitable for the company but he was really buying something that was significantly different than what was on the purchase order. The description was just changed to make it go through the system better. And I got rid of that person, and I got rid of him very quickly. And the minute I did, I had about ten people come back to me and say “Thank you. He was destructive.” Even though on the outside he looked very positive. He got along with everybody because of the favoritism in this way, he would trade things back and forth. Nobody trusted that he would do the right thing. But they weren’t going to say that because everybody else said oh what a nice guy he was. And so all of a sudden getting rid of him and he’s gone, I had a whole bunch of people come back to me and say wow it’s so much easier to work here now, because I don’t have to worry about him stabbing me in the back. I was really quite surprised. I felt really get a reaction and totally the opposite direction. Another one I had a very highly specialized developer working with one tool that everyone said “Oh this is the only person who could ever do this tool” and this person was nothing but argumentative. Every time we were in a meeting, he would tell the customer they were wrong. He wouldn’t compromise. He was always very stern. And finally I had to let him go. And what I found was that I had five other people in the organization, each of them knew about 25 percent of what this guy knew and also had to do now instead of giving him the specific task of working with this product, I would just break it up between these five people and they had all the experience I needed to cover that, ok? And now all of sudden I took those people and basically raised them up a notch, because they were all working with this product which they wanted to work with anyway. But this guy was always sitting on top of it saying “This is my territory, you can’t have it.” And this is the pre-bid on the complex. And so he was artificially making himself the prima donna by verbally shutting down anybody else on what they had to talk about, what they had to say. And once I got these four people together to actually, or five people together to actually cover that area, it moved a lot faster because there was a lot more conversation. People started talking back and forth about “Well if we do this what will happen, if we do that what will happen”. And we ended up with a better solution because it was better thought out and more integrated. It was very much better solution and a lot of people were upset with me, whenever I got rid of that person. And then it took about a month and a half or two months and finally people said “That’s the best thing that ever happened to this project, because it made us a team. It made a stronger product. It moved things forward.”
[44:42] Yegor: It sounds like letting people go is a good recipe to earn respect in the team, isn’t it?
[44:50] Todd: Well I wouldn’t go that far. I don’t think it’s a tool to earn respect, I mean I don’t go in and say “Hey let’s get rid of somebody” so they’ll respect me. That is definitely not the direction I go. I go in there and say “If there’s a rotten apple in here we need to get rid of the rotten apple.” But I would not prescribe that as a tool for everybody to use every time they walk into a project, just to fire two people that [inaudible voice] very quick, right? So I mean I don’t always do that, those are a couple of examples over time. What I want to stress though is that there’s a lot of consternation when you do get rid of someone, especially if you think that there’s highly specialized person that you know, the whole project is going to fall apart and that’s not necessarily the outcome. I’ve never had a project fall apart because I’ve got rid of somebody or somebody has left. I have generally the team that’s got even stronger when that’s happened. Even when somebody leaves on their own. I mean we’ve had to struggle a little bit but then that gives people a rally point they come back and they say “Ok, Susie’s left. She was the only one who knew how this specific aspect worked, how are we going to cover that?” And sometimes we end up bringing in a contractor to help or sometimes we end up saying “Hey we could fill the team with our existing people and we’ll rely on them and they come to the rescue and when you say “Hey can you help me, can you solve this problem?” and you put trust in someone, you make yourself vulnerable that “If this fails I’m going to look like crap. Can you help me out?” You earn respect pretty quick that way. Because people realise that you trust them Ok, yeah. You don’t get trust in laws. In my opinion you don’t get trust unless you trust somebody first.
[46:57] Yegor: And that makes sense. Let me get back to the prima donna problem which you mentioned a few times. Well again who do you blame on that, the managers or those primadonna people who are just by design prima donnas? So who makes the mistake when that happens?
[47:14] Todd: Well there’s two different realms, I think most of the time it’s the person and the person gets too big on themselves, they think too much of themselves and that they’re too valuable. I think that’s probably most of the time, but I have been in at least two organizations where that was required by management and management fostered that if you weren’t specialized in something that you weren’t valuable, people got raises based on how they specialized, they got recognition in various ways shapes and form because they were so highly specialized that they could do whatever needed to be done. And it was the management that actually created that whole concept and drive, that was not good. That was probably the hardest organization to work in where everybody was pitted against our two organizations. One of them was worse than the other, where everyone was basically pitted against one another and they were supposed to compete with each other, which was obviously it’s not a team, you’re trying to show that I’m better at this than the next person. I really have two projects running in parallel building the same product with two different sets of tools. And whoever made the best tool, one so to speak, using the same shared resources in IT and so ITs all of a sudden turn because they have to request to do two opposite things or vie for people. It was a really ugly situation and everyone became very highly specialized and nobody talked to one another. It was ugly, that was a very challenging company, a startup which by the way didn’t succeed.
[49:12] Yegor: So it sounds like the company and the management, the top management of the company, according to your warrants and according to my experience, I totally agree with that. They are shooting themselves in the foot, because on one side they want people to be super skilled, very specialized and they reward them for knowing something that nobody else knows. And then those people don’t become a problem for a company and in the best case they get fired, and in the worst case they cause problems for company. [49:45] Todd: Yeah you breed your own problem, and this is not just a way in a business or two businesses go out and take a look at any advice board out there. You know even going to college and you go to school. People say specialize, specialize, specialize, you know, don’t just specialize on a software product, specialize in a specific aspect of that software product. I mean the more specialized you are, the more valuable you are. So people become so narrow and extremely deep, so narrow that I think people start losing the picture of what they’re really trying to get done and this is a bigger problem than project management, a bigger problem than software development. This is a problem in our businesses where people are really becoming very-very super specialized and can’t see past their level walls. And so you end up with people building the wrong thing or not understanding where the project is, where the product of the company is going.
[50:57] Yegor: And what is the solution?
[51:00] Todd: My opinion, my solution is this is very self-serving as being more of a generalist, because if you listen to what I just have been saying in here is one of the things that I do as a project manager, I don’t just manage IT projects, I manage IT projects, I’d be managed software, new product development, you know, physical product development. I’ve actually been over managing marketing projects, lots of different projects. I’m more of a generalist. And I understand how these whole [inaudible voice] things work in a variety of different situations. So through that generalization, that’s where I’ve been able to make my niche. So like I say, it’s a bit of a self-serving statement, I find that that’s very-very important. I think that people need to be specialized in an area but they need to be also broad so be it three or four inches deep, a mile wide in everything and then take something that’s three inches wide and go a mile deep. But you better have that broader understanding of what’s going on. You know that’s an issue, the attitude that I’m the best at something and no one else can do it. I think it’s destructive for our companies, our teams and it’s not the right direction to go. But especially here, in North America, I can’t speak too much outside of North America, I haven’t been doing international projects for about 10-15 years. It’s hard for people to do that in today’s society. It’s very me-oriented.
[52:54] Yegor: Yeah, sounds like there is no obvious solution for a programmer who is… If I am a programmer, I’m trying to think about my real experience, real examples and I remember where people are companies and my employers, they were trying to turn me into a prima donna. They were trying to give me a very narrow niche where I’m supposed to be the extra, you know, that extremely specialized and skilled person just in one niche, which potentially could lead to turning me into a replaceable source of the company. And what would you recommend to a programmer to do in that case? Is it like the right way to ask to be moved to another project or given more tasks or what?
[53:40] Todd: So you know as programmers, so far I haven’t met too many programmers who have stuck with one tool and never moved off that tool. Ok, there are some global programmers out there who are making millions right now because the fact that that’s all they know, and they know it very well. But those are more rare. I mean most people have worked their way up to various programming languages and they know a series of them. They may know one better than another. But there’s something new that comes out. They move off to that and they kind of move around and learn and experience new things. And I think they understand the power of that. So I think I mean in my experience I think most programmers, technical people in general and know and love this idea of new things coming out and understanding how to crack open the box, understand how it works and really dive in and understand, how that tool works. I think the harder problem for that developer is to see outside of that box. And I think it is true for all of us to see outside of our boxes and see what’s really going on with the organization. Even me as a project manager, I mean I used to be a developer who wrote C and C++ and Java and all that stuff. And as I moved into the ranks of being more managing those people, and keeping away from the actual coding, what I found is there was this whole world or stuff I didn’t know about. Now all of a sudden how did these pieces fit together. And I think that that’s important for a developer is if I’m writing some app for a phone, for computer, for whatever, or just a module, okay, even software for a router or whatever it is, how does that actually play into the bigger picture, into the world of business. How does it actually get to earnings? How does it actually get to my paycheck? How does that actually make life better? And so if people start stepping up to that level of understanding that, I think that’s pretty important. I think that’s also an argument that if they want to move on and move around, that’s the argument you make to the executives who are saying “I want you to specialize, specialize and specialize. You know I would be better if I knew more about how everything works. I had an experience a number of years ago I’ve written about 12 years ago. I’ve written about a fair amount that’s sort of for my wife had some medical problems and took her to the hospital. He said she had a heart attack, she was having a heart attack and there was a series of things that indicated that there was more going on, but the minute she got labeled as having a heart attack we got a specialist called a cardiologist come in and this cardiologist sat on top of her and she you know took care of everything and I kept trying to tell him that there was other stuff going on and he kept saying “No, that’s not possible. You know I am heart doctor. I know what’s going on” I said “But when you did this and this, other thing happened.” - “No that can’t happen. That just doesn’t make sense.” Well the problem was that he was overlooking the fact that simultaneously or very close to simultaneous with a week of having heart attack. She’d had a stroke. And so what he was looking at was the heart. And he was not the type of person who would be looking at for a cerebral stroke. And so what we do is bring in another specialist who’s a cerebral thing, and then we had to bring in another specialist, who did the vascular thing and by the time we got everybody involved, that had to handle the capture of those three people, then I had to sit again as a project manager in the middle of that, trying to get these three people to talk to one another because they were so focused on their little aspect of the human body that they couldn’t see that there was an actual person there, they didn’t see it at all. And that was the key to my wife still being alive in the other room, is that we were able to get people to look at that integrated system by just looking at one piece. You’re missing what’s going on everywhere else.
[58:30] Yegor: It’s a really good example, it is relevant to project managers as well or only programmers?
[58:36] Todd: No, no, no, it is relevant to a project manager, it is to a developer. Because project managers run one project, or maybe two projects, or three projects. But let’s take the extreme and say they’re running one project. How did they know where their project sits, in the importance of the overall scheme? I’m maybe working on a project that is going to bring in 500 customers to a company. And so from my standpoint go “Wow this is a grouping of 500 paying customers. This is just fantastic.” And so I’m working on that project, it’s leading edge, it’s using the greatest and greatest tools. Everything is just the cat’s pajamas in this thing. I mean it’s just the sexiest project in the world. And all of a sudden its priority gets bumped and it’s way down the list, and they all go “Why?” Well come to find out maybe there’s another project that is a compliance project and we all love compliance projects, right. And we have to comply with some federal regulation, or some customers, new EDI, needs or whatever. And this low-tech, ridiculous “Why are we doing this project” is all of a sudden taking priority of mine. That’s because it’s a compliance project. If I don’t comply with that, I will lose a segment of my business, right? So the project manager needs to see all the projects, how they all fit together. So whenever someone comes to them and says “Hey I need a resource of yours, I need some time”, that you’re able to actually say “Okay where am I on the priority list? How can I fit in? How can I help so that I say ”Hey there’s 20 other projects going on there higher priority than mine. Why are we doing mine? Why don’t we put this on hold for a little bit. Take my resources, get those other projects done and then we’ll come back to this project in six months”, that I’ve actually done a project and it came as quite a shock that the people heard me say that but then when they got done they got that makes perfect sense. And so we did just that we took my team, we dispersed among the other projects to get the projects done six months later, we started up my project again and boom! we got it all done. But we would have just lumbered along and everything would have gone slower, had we not done that. And so as a project manager, we need to see even more about what’s going on in the company and how things are working, how everything fits together, so that we know where we fit in that machine. So that’s a very-very important concept for both programmers, developers, anybody like that and project managers.
[1:01:21] Yegor: Sounds reasonable to me. And my last question to you, a little bit personal. Do you love to be project manager or just doing it because it pays?
[1:01:33] Todd: I love it.
[1:01:37] Yegor: Because you know, it is our interest in the software business and in most cases, in the majority of cases people become project managers just because they were successful programmers, they were experienced there were on successful projects and then one time the management suggests them and offers them to become a leader of the group or a manager and then a hire manager. So they just happened to become managers. They never dreamed to be managers, just an accidental project manager and executive, so that’s why I’m asking, so what do you think about yourself first of all, what’s your position, and what would you recommend in general for those situations. Should people accept those offers and say “Ok I was a Java developer I’m a good person. Why not?” Or maybe we should clearly segregate those two professions. Programming is programming, management is management.
[1:02:29] Todd: So I’m an accidental project manager, so I don’t have a degree in project management and didn’t get any bachelor’s, and didn’t get a Ph.D. in Project Management. I’ve come up from the ranks of “Hey I’m a developer in this project and I’m telling everyone what to do, I am supposed to you know lead. I’m honored about what you do and also I’m the manager of everybody and I’m telling them what to do” and I don’t even remember moving up the ranks and doing that. It just happened. I just started getting more and more people coming to me and all the sudden I realized the fact I’m project manager and had no clue of what I was doing. I liked the idea that I could organize things and get the organization together to make it so we could get the complete product out. And that was a really exciting thing. And that’s what really got me into project management. The second project that I was also the project manager on, a slightly different story. Then I realized because I didn’t earn my way to the top, I was put at the top that I didn’t have the respect. I didn’t know how to deal with people. I was still dealing with this on a very mechanical code-like manner. And why wouldn’t somebody do that. I didn’t understand and I did not have the grasp of how to deal with people that I needed. So if someone is in the midst of getting into that mode of moving up it’s kind of the I guess the question would be as you’re developer, you’re kind of in control of your own little planet and you create a problem or you run into an issue where two things don’t talk to one another correctly, or something’s not behaving the way they want to, it’s up to you to solve it and what you’re dealing with is a piece of software that you’re fighting with. Okay, you’re trying to make that piece of software, do what you want it to do. That’s very different than when all of a sudden because software really doesn’t talk back, and it’s really different then whenever you’re dealing with a person and that person doesn’t do what you want them to do. Now you have to use a completely different style, right? And so it’s not just a here’s a programming syntax or whatever. Now it’s say a style you have to develop and nurture various styles and strategies, so that you can get people to do what you want them to do, as if they wanted to do it to begin with. And that’s a challenge. So if you’re getting into that realm, you have to say who do I like better, do I like software better or do I like people better? Am I a people person? Do I get along with people? Do I feel that I have a knack to be able to get people to do what I want them to do? Do I mind it whenever the people that come to me are acting more like kids than they are adults? Does that annoy me? Because if it does that could it be good at this. And so there is a you have to ask you the self that question, how much of a people person am I? And try it out if you don’t like it, don’t be ashamed. Just step back into my role as a project as a programmer and love it, okay? But be open about it, if your manager says, “Hey I’ll try it out. But you know if I don’t like it, I’ll want my old job back.” And don’t feel like you’re being downgraded. Feel like you’ve made the right decision in your life.
[1:06:24] Yegor: Sounds like a very good advice. I thank you very much. We spent all the time for today and it was really interesting conversation..
[1:06:29] Todd: Excellent. Well, thank you very much. I’ve really enjoyed this.
[1:06:32] Yegor: Ok. Bye bye.
[1:06:34] Todd: Ok, take care. Bye bye.
