|
|
Back to UserFriendly Strip Comments Index
|
I did something stupid yesterday. | by Khaar | 2007-05-18 04:48:33 |
| For a title I'd suggest cat herder |
by kambrose |
2007-05-18 06:18:30 |
But seriously, the main things to keep in mind I'd say are:
Have enough meetings to keep track of things, and not too much more. Consider meeting with the developers in smaller groups so they don't have to hear about all the other projects. Take it upon yourself to summarize the other groups projects to each group. If developers have to sit through the other developers status reports on unrelated projects each week, I think they'll start zoning out.
Remember you're in charge which means you make the decisions, but you're responsible for that decision. (This is much easier if you have good support from above). It's a good idea to gather input and suggestions from the developers, but you get to make the decision. As far as the responsibility goes, in my experience no one works well for someone who makes a decision based on subordinates' input, but then blames the subordinates if it doesn't work out.
Self evaluations can be useful (I always hate filling out mine though.) As far as peer-evaluations, you'll want to put a little effort into making sure that there's some level of confidentiality to them, or you probably won't get an honest response from most people.
Getting developers to cooperate can be tough. Look for people in the first few meetings who seem more interested in the changes that can help them. These people are more likely to help you make the changes. Any changes that require extra work on the part of the developers, even something as simple as status reports or a project summary slide for a meeting, will meet with less resistance from people who are interested in change.
One last thing that can be tough. In order to make developers work as a team you need a balance between individual and team responsibility. For example if the person working on the database triggers for a project is running behind, don't just ask them what the problem is and what can be done to catch up, ask the other developers in the meeting as well. Sometimes things don't go well even for good developers, and you may want to have the other developers share the work to help get past the problem. This makes the group at least somewhat responsible for dealing with problems. When you do this though you do need to keep an eye out for developers who consistently needs help. Once the developers know that they'll have to do extra work to help another developer catch up, the peer evaluations will probably start to show who isn't pulling their weight.
Well that's a lot of rambling and run on sentences. I hope some of this might be useful to you.
Good luck. |
|
[ Reply ] |
|
|
[Todays Cartoon Discussion]
[News Index]
|
|
