Oh my heavens, you're a bright shiny new manager, you've been given a glorious new project to lead and what's this? You can't even go to the can without the janitor giving you advice on what you are doing wrong and how to fix it. How ever did the world turn into such a cruel, callous place? Just wait, it gets better. There was never a product launched nor a project completed if only the person-in-change hadn't been such a bullhead and not listen to the advice of those around him or her who knew better.. why this reminds of me of that blockhead...Blah, blah, blah.
As you may have guessed by now, an essential skill-set that is acquired by the rookie project manager in any middlin' to large organization is ability to respond to and/or ignore criticism. Most PMs learn to block it out. Some don't, and return to being engineers or technicians. Some become PM in name only, choosing projects that are in maintenance mode and avoid dealing with criticism that way. Which is a shame, because if there is one thing that is sweeter in seeing a project completed to success, it's seeing a project succeed against a chorus of naysayers.
Of course, some PMs learn to block out not only criticism but good constructive advice, acquiring a siege mentality and tunnel vision which leads the whole team to disaster which could have been easily avoided. So blocking out everything that is said about your project is not a great approach either. It can be a real quandary: On a hot project, you can have so much criticism/advice coming your way that you can spend all your time dealing with the advice-givers and validating/disproving their comments. And lots of time the advice-givers are those higher up in the food-chain whereby ignoring them is perhaps not the best way to enhance your career prospects in that particular organization. So what to do?
It is important to realize that not all criticism is the same, and to differentiate your response to each one of the flavors. In my opinion, there are four types of criticism: Noise, constructive, delaying, and blocking. I will deal with each in turn.
Noise is an e-mail or a hallway conversation, or even an off-hand remark in a staff meeting about your project that is critical. Noise is criticism given without much thought or consideration, and is also hard to validate without considerable expenditure of resources. The last part is important. Every once in awhile, you can have a hallway conversation with somebody who throws off an off-hand remark that is really pertinent and is actually a really useful bit of advice. Or they suggest a different way of doing something that is more economical or quicker than the way you are doing it at present. But of course, a lot of time noise is just that, noise. You can really determine the value of the criticism by actually visualizing a plan of action if you were to actually take the advice: Re-write the entire code base in C # instead of Visual Basic even you though you have a drop-dead date for shipping next week? NOISE.However, you should never duck noise because it might not be noise, it might be a beautiful piece of music that you need to hear at just the right time. Another equally good reason why you should never duck noise is because you want people to bitch to your face, not behind your back or worse yet, to members of your team whose morale you are responsible for. I mean, that's one of the basic responsibilities of a PM, taking arrows in the bum that were meant for your team.
Constructive criticism is entirely different: It's feedback given in a controlled environment according a reasonably clear set of guidelines. A code review or product milestone meeting should give up a reasonable amount of constructive criticism. BTW, none is not a reasonable amount, unless you are some sort of genius (which is doubtful). More likely, if you present at one of these meetings and you receive zero feedback, it most likely means that nobody cares about your project (this is bad). So let's assume the best and that you do receive criticism/advice/feedback at these meetings, what to do? The best response is to just acknowledge the criticism and move on. If the critic (who often times is the chair) demands an answer, then you should respond as best you can at the present time, and negotiate a reasonable time period as to when you can provide a full and complete answer. But always make sure you know the guidelines of the meeting. They are usually there to make sure that no impasse will occur, which usually embarrasses everyone. But note at some of these meetings, you are expect to show a certain amount of grace under pressure, so you need to do your homework and prep for the ritual ball-busting if that is the usual ceremony. It actually doesn't hurt sometimes to admit that you were wrong in whatever the topic of the conversation is, especially if the critic is somebody who has vastly more experience than you in such matters.. And gees, if you are wrong, you should admit it. There is nothing more pathetic at these meetings than somebody who loses control of their ego and desperately clings to one side of an argument that has been abandoned by everybody else at the meeting.
Delaying and blocking criticism can appear to be quite similar on the surface but actually spring from two very different base motives. Delaying criticism occurs when the critic isn't quite prepared to support you in whatever marvellous endeavor you are undertaking. Of course you should only care if the critic has resources that you need (which is about 99% of the time). For me personally, it's absolutely amazing how often delaying criticism can be handled successfully by just giving the critic a reasonable amount of time to think things over. For example, suppose you need a developer to write a patch in their code branch to make your component work successfully. If it's more than a trivial amount of work, there is most likely going to be more criticism about your need than agreement that the patch needs to be created, at the first meeting. However, give it 24 hours or a couple of days, most likely you'll get your patch, especially if you stay pleasant and calm through the whole negotiating period.
Blocking criticism is a whole different ballgame in that you can wait until the Maple Leafs win the Stanley Cup, and you still may not get that stupid patch. However, the script of the blocking critic is oftentime similar to the delaying critic, so you need to really analyze the interaction between the critic and yourself and determine which type it is (Note: There is presumption here that you need resources from the critic. If you don't need anything from this person, you are free to file the criticism in the mental file folder labeled: Noise). If you are stomping around on their tuff, you are most likely to encounter blocking criticism. If they get theological on you (like Unix versus Windows, or C # versus Java), then it's a block. You are then faced with a series of choices: 1) Proceed without the resources of the critic. 2) Get somebody in authority to beat on their stubborn heads. 3)Ask them what has to change for them to drop their criticism, and decide if you can live with their changes. Option # 3 is usually the best if you can swing it. Option #1 is the fallback if #3 is impossible, and a lot of times the critic will capitulate if they see you have a chance of success without their contributions. I don't ever recommend #2 unless you are in some sort of weird authoritarian organization like the KGB or if your executive sponsor has a very clear mandate to push stuff through a dysfunctional organization. Even then, I wouldn't be banking on collecting a pension at the place if #2 becomes a standard part of your PM toolkit.
Final bits of advice: Get a sense of humor. Don't take it personally. And remember that organizations have incredibly short attention spans. You may be in hurricane of criticism one week and think that it will never end, and the gossip next Monday at the office is not you but the manager in the next building who was caught fooling around with the marketing communication officer in the storeroom.
And what will you feel? A bit of resentment that you are not the center of attention anymore. Such is the emotional silliness of a human being.
Hmmm. I've seen managers with incredibly long memories of perceived downfalls of team members. And this type of person would pull out a laundry list of these problems whenever the need to criticize came up. Short memory of orgs? Don't I wish