I have had my fair share of strife when managing teams of people. I have attended various training courses etc... and the one thing that they never explain is how to tell people what not to do.
Its easy enough to tell people what to do. You have a project with some goals, and requirements, and so you start by reviewing the goals and requirements with the team. In your head everything is crystal clear, and after the 1-2 hour discussion, it seems that the team members are content with the project definition. Then, everyone smiles, nods and agrees that this project, is simple, clear, and will easily be accomplished within the given time frame.
3 weeks later its a mess...
Why didn't you tell the programmer not to write that huge new data structure to mirror the existing perfectly useful structure.
Why didn't you tell the artist not to put all the assets in one monolithic file.
Why didn't you tell the engineer not to fragment that 1 page C++ function into multiple micro functions distributed across multiple source files, all relying on scary side effects and carefully organised calling sequence.
I realize this is all simply about communication, and experience. Something that I believed was obvious, and didn't need to be said, wasn't obvious to the team members. The solution isn't to micro-manage and tell people exactly what to do and exactly how to do it. Everybody wants to contribute to the project, and add something of themselves.
But, how, oh how do you guide a project through and avoid the incredible tangents that junior members are guaranteed to do, just to inject a part of their inexperience into the project. In some cases, you just can't afford to let people learn the hard way.
I had a long day....
Friday, October 16, 2009
Subscribe to:
Posts (Atom)
