Thursday, February 15, 2007
Managers and developers: Are you two teams or one?
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.