I’ve started re-reading “Rapid Development” by Steve McConnell. This was the first project management book I read and remains the best one so far. It’s pretty hefty at 680 pages, but if you thought project-related problems could be solved in a 30 page pamphlet, think again.
McConnell writes about four factors that can influence a projects success: people, process, product, and technology. Today I’m going to write about the first:
People
It’s all been said before. People are the heart of any organization. Nice platitude, but one which doesn’t seem to stick. Even organizations that use this as a mantra seem to forget it when push comes to shove.
The people that make up your project are intimately linked to the success of the project. If you keep your people happy, they’ll be motivated to do the best work possible. They’ll take pride of ownership of the project and do what they can to make it a success. They’ll provide suggestions for improving the development process. They’ll spend their time doing their job instead of browsing monster. Happy people make for happy projects.
Keep people motivated and avoid doing things that will de-motivate them. Motivation has many faces. Different people are motivated by different things. Try to match the people on your team to the task that will motivate them the most. Give people the tools and resources they need to work optimally. Eliminate policies and procedures that exist for reasons other than improving productivity and performance. If you identify a source of de-motivation, do what you can to eliminate it.
Treating people poorly will definitely demotivate them. Running your developers into the ground might pull your butt out of the frying pan on today’s project, but what about the next project? Your top guns start leaving for better pastures. Developers with top skills know they can go out and get a better job without too much trouble. You burn them once, shame on you. They’re not about to sit around waiting for you to do it to them again. The ‘code-like-hell’ mentality will put a major drain on your talent pool.
Other sources of de-motivation?
“Do as I say, not as I do” – if you ask people to work the weekend, you better damn well show up yourself. If you come in Monday talking about how great the sailing was while everyone else was in the office working away, it’s a sign you just don’t get it. If the project is as far behind as you imply then there should be plenty of work for you. In the unlikely event you don’t have anything to work on, find out what else you can do for your team.
“Death from above” – if you tell your team the project is critical and important, make sure senior management doesn’t got about implying the project should be canceled. The last thing someone wants to hear is that senior management thinks the project they’re working is a joke. If the project can be canceled at a whim, what motivates someone have to do their best work?
“Just be happy” – with all the reports of outsourcing and exporting development jobs overseas, it’s easy to imply people should simply be happy to hold a job. Don’t do it. There is no easier way to make people feel bad about their jobs than to imply they’re disposable.
If you are going to outsource your development, don’t make those that lost their jobs train their replacements. It’s one thing to see coworkers getting fired, it’s another to see them humiliated. There is not reason to treat people this poorly, so use some common sense and show compassion.
These are just examples. I’m sure you can think of any number of additional ways you can ruin the motivation of your team.
So do what you can to keep people happy. You can’t keep everyone happy all the time, but if you put out an honest effort it will be recognized. Doing otherwise is a sure way to drive your best employees elsewhere, leaving you with a pool of average and poor performers. McConnell sites several studies that conclude top performers are up to 10x more productive than average ones. Don’t shoot yourself in the foot.