This week in pmclinic: Mutiny
This week in the pm-clinic discussion forum– Mutiny:
MutinyThis is one for the history books – I have quite the situation on my hands. I’m the PM for a 15 person team. My peer is the lead developer, who manages 6 programmers (of the 15). We disagreed on a major project decision, brought it to the VP, and he went my way. But since then, the lead developer has stopped talking to me. I mean, he won’t even answer my questions.Whenever possible he tries to backfill the decision, directing his team towards the outcome he wanted, despite the VP directive. At first this was just frustrating (for me and the team), but now it makes me look incompetent and puts the project at risk. Morale is dropping, as we’re like a family where the parents have stopped talking to each other and programmers are taking sides.Help?
I can tell what’s wrong here. I’m no vet but this is textbook stuff if I’m not wrong. This place is not consensus driven and neither are decisions taken by the persons who have the most knowledge about the matters.
Dispute resolution involving only the affected parties is the way to go in any development shop. Any decision thrust from above usually results in a deathmarch.
So the answer might lie in a lengthy meeting involving the 2 Sr. developers putting all their points across and then arriving at a mutually acceptable solution. It may take a day or two but nothing’s better than making eventual progress to the common goal of project realization.
There is a great book “leadership – the Sopranos style”.
Yes, it uses the TV series “the Sopranos” to teach about leadership. No, you do not need a gun to solve this issue…
Since this person is clearly undermining your authority, as well as behaving disruptive for the success of the project, tell him clearly that as a result of the “sit down” the decision was made in your favor, and he should from now on support this decision and do whatever it takes to make it work. Be careful to concentrate on the behaviour (he doesn’t communicate any more) and the results of that behaviour (project problems, morale going down, …), and not on the person who may actually be a great guy.
Since you are the PM of the 15 person team, and the other person is the lead of 6 persons of those 15, explain him that you respect his opinion, but ultimately it is your decision, and that decision has been taken. Period. End of discussion.
If the behaviour continues, find out where your limits are with respect to corrective actions (in my opinion, it is better to ditch a problem person than to live with the problem).
I strongly disagree with mr Reynolds when he wants to involve 2 other senior developers. It puts those people in the frontline and forces them to take sides in a battle that is not their battle. They may have a long history of pub visits ;-) with the lead developer.
P.S. make it a habit of seeing your developers regularly outside your work environment, e.g. go out to lunch with them, have a pizza, have a beer, and build trust. Next time when there is a dispute, people might disagree, but will actually accept your decision.
Seems like we have quite a discussion left.
I would like to clarify a few things – I did not advocate for any external developers to take sides. I’m taking about the same people again – the PM and the lead developer.
And then, we havent heard both sides of the story. How can we trust that the right decision has been made and that everyone must follow it without any discussions?
There will always be disagreements. The more there are, the bitter is the struglle to the common goal. IMHO PM is more about building consensus and not about decision imposition. I’ve never seen decision imposition to work. Especially when Scott has just pointed us about the victimization and empowerment ratios.
Cant this be the case of the wrong decision being made by the PM and VP, while the lead developer struggles to steer the project in the right direction?
Unless we hear both sides of the story we cant be pointing fingers at who’s wrong and who’s right.
And as I would repeat for most of these kinds of issues – the person with the most knowledge makes the decision. He ‘owns’ that territory and in my view this is a case of territorial overlap or even infringement.
Finally, I dont think that disposing off a lead dev in a team of 15 is going to contribute to project progress . What are the costs and chances of hiring someone with similar or better abilities? And what if the project ultimately fails because of this?
PS:I’ve got a very strong feeling that our dear Scott is calling himself Guy and writing in the third person. Apologies to the real Guy if he exists.
Vineet, we would indeed have a lot to discuss about.
Let me start by saying I am not the real Scott… so do not take my opinion as the one that Scott advocates in his marvelous book. PM is about people, and getting them to do what is necessary for the project to succeed.
In my opinion, a concensus driven environment is sometimes the best solution.
However, having worked as well in internet start-up companies as for government institutions, I have found that for me the best aproach that seems to work is to be a sort of benign benevolent despote. Listen to the people that have the most experience, but do not simply discard the opinions of someone who is new (read: fresh) on the job. Communicate and discuss a lot with everyone on your team, not just the so-called lead developper (this is where the pizza en beer helps to create a more informal atmosphere).
Show them that you really respect their opinion, and when you thank them for something they have done do not make the mistake of simply going through the motions. Mean it when you thank someone. And mean it when you are angry with someone who doesn’t do what has to be done.
In our world (IT, PM) people do not simply respect you because you have a title. They only respect you when you do not treat them like complete idiots, when you are competent in your area of expertise and listen to those competent in theirs.
And they will accept that the final decision is yours to make. After all, you are the PM, the one whose head may roll as a result of a failed project. You, as the PM, are the leader of the band, the lead singer, the one in the spotlights of management.
Yes, they will understand, when they feel respected as individuals and when they see competence in you (and not just umbrella techniques), that you may have a different opinion, and that the ultimate dicision is yours and yours alone.
A good PM should feel secured enough to have regular “what the f*ck are we doing” meeting with his or her people. Such discussions will reveal quickly potential problems, and will show your people that you are really willing to listen to other sounds than your own voice. Personally, I tell my people that a world where everyone has the same opinion would be very boring indeed, and that it is the clash of opinions that push the world forward.
Returning to the problem at hand, I believe it is ultimately better to get rid of a disturbing lead developer (and face a possible set-back) than to let the problem feed on itself and become larger than life. Because the one dissident voice may become the de facto leader of a mutiny. And that is far worse than any fear of a potential set-back.
My experience teaches me that a good talk with such a problem person most of the time solves the problembehaviour. But not always!
To be a PM means to be the Leader with capital L .
So, go forth and Lead !
Guy, after reading your reply I found that we agree on most of the issues raised here.
There is just thorny issue left – do you get a VP to make a decision whenever there is a disagreement between 2 people, or do you get the 2 persons to sort it out themselves ?
In my opinion, getting the VP to make the decision is like asking him to take sides in a fight. It is always better to let the two behemoths fight it out and come to a consensus; probably the only right thing to do until a lot of time has passed by to raise an alert.
Most often it takes ‘courage’ to stop a project in it’s track, resolve an outstanding issue in the interest of the project before moving along.
The advice that I would offer, however newbie it might sound, would be to backtrack the VP’s decision (assuming that the VP is cooperative); get back to the issue, analyze it at a ‘higher resolution’ under a microscope and then agree to a common goal to resolve the issue.
It is only now that I would advocate a tough measure if the lead dev continues to adopt a different approach to the project.
BTW this article by Joel Spolsky is usually what I cite when it comes decisions made by people outside the problems’ scope – http://www.joelonsoftware.com/articles/fog0000000072.html
The part about MSFT managers not playing a judicial role in decision making is almost always a self fulfilling prophesy.
I agree that the VP shouldn’t have been involved at first sight.
Because, when it is cristalclear that the PM decides in the end, it wouldn’t have been necessary.
This doesn’t mean that the person asking the question is not a capable PM. But the fact that the issue was brought to the VP for conclusion tells me more about the company “spirit” than about the PM.
In my opinion, the main reasons to bring an issue to the next level in the company hierarchy are:
– the issue blocks work for the current project milestone
– the issue may have security implications and therefore requires a resolution at a higher level in the company
– the issue may have company-wide implications, and therefore requires a resolution at a higher level in the company
– the issue = a behaviour problem between your people, or between you and one or more of your people
However, a difference of opinion – expecially a techincal discussion – should simply be resolved by the PM. When the PM is the one having the different opinion, so be it.
P.S. Vineet, thanks for your feedback. I appreciate the time you took to read my response and to formulate a follow-up.
Aye! No probs. I like talking.
Holy cow!!
I think Guy was Mr. Guy Kawasaki.
Aww, too late. :(