One of the reasons why I love Dilbert so much is because Scott Adams really feels the pulse of the typical IT organization. How many times have you seen the above situation? In one project, the whole world (including me, and I was not even a part of the project) knew that the project was burning, except the people who really needed to know — the managers and stakeholders — had no clue as to the real state of the project.
Why does this happen?
Most manager-developer problems in a software company are caused by one thing: trust, or rather, a lack of trust. Managers do not trust the developers to do any work. They believe that the developers have to be pushed, otherwise nothing will get done. Developers in turn do not trust the management to cover their back. They believe that the managers will screw them when things go wrong. As a result, instead of working together as one team, they become two teams, each defending their turf from outside attack.
Once that happens the project is as good as dead. Communication across the border will virtually stop.
Back to the above cartoon:
Dilbert is comfortable telling Wally the real situation of the project because he knows Wally will support him. After all they are in the same 'team'. When he tells the PHB that the project is fine, he doesn't really mean that its fine. He knows if he brings up any issue, the PHB will blame the team. What he is really communicating is "I don't want to talk to you. I'll say fine so that you go away quickly."
If you are a manager, be sure that you cultivate trust with the development team. What better way to do that then to show that you are on their side. When the team asks for more RAM for their computers, do you get it or do you say that its out of budget? When the team says that the schedule is too short, do you tell that to the customer and try to find a solution or do you ask the team to work weekends?
This is one reason why I like agile processes and the Scrummaster role in particular. Scrum tries hard to make the Scrummaster fit in with the team, to support the team, to enable the team to perform. In exchange, when things go wrong, the team is often more open in bringing up issues because they are all one team, working together in the same direction. They know that the Scrummaster will help in solving the problem rather than blaming the team.
10 comments:
That's very true. However, trust between management and developers are hard to build, and it can easily break if one party doesn't keep their promises.
Building trust should be good fodder for a series of posts. How about that Sidharta? IMHO It is on the same level as earning respect. Easy to say but very tough to do and most often neglected part of team building in teams I have seen.
Good points. Trust is very hard to cultivate, especially when both sides start off with mistrust. That's why I feel that it is important for the manager to take the initiative and demosntrate to the team that he is on the same team.
Though knowing Wally from other strips, I doubt he's got Dilbert's back any more than PHB ;p
heh :)
>> They believe that the developers have to be pushed, otherwise
>> nothing will get done. Developers in turn do not trust the
>> management to cover their back
Siddhi, some developers really need to be "pushed", otherwise they would focus more on their priority than the project's priority. (Parkinson's Law has its place sometime.) For these particular cases, the manager's job is to make reconcile the both the developer's personal priority and that of the project. However, the "push" is to make sure the project priority is paid attention to, not to force developers to do more than what they really can (it's the quality which is sacrificed for this kind of "push"). Of course, if the managers cannot do this, he should be fired.
As a manager, I agree with Buu Nguyen.
As a _technical_ manager, I usually check and review a lot of low level stuff on the project, in order to ensure not to have the 'FINE' fake answer when I check for the project status.
Needless to say, when I particularly trust some developers, I don't need to check low level issues...
Good post, by the way
Well, yes, sometimes the developers are really not doing work. Thats something to be taken on a case by case basis. I don't think that you should therefore suspect all the developers.
The real solution to this problem is increasing project visibility, so that everyone knows the project status.
Lack of trust re-inforces itself, so the developers react and things go quickly downhill from there.
You are right. Visibility and Trust make projects (and teams) far better.
Stumbled upon the post while looking for wikicamp post. Good one!
Keep the insights flowing.
-Balaji S.
Post a Comment