Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things
 
PerlMonks  

Re: On programmer schedules and productivity

by footpad (Monsignor)
on May 11, 2001 at 03:32 UTC ( #79608=note: print w/replies, xml ) Need Help??


in reply to On programmer schedules and productivity

A few (somewhat) random thoughts come to mind:

  • Since you're getting static from other managers, you may be able to quiet them a bit by showing them the amount of hours your people are logging against a project, assuming that you're tracking time. (If not, that may be another metric, one perhaps more appropriate than lines of code produced).

    clemburg posted some good ideas in this node. If you're tracking time, then it shouldn't be any trouble to draw up some pretty graphs for your "counterparts." Also, if you're using a VCS, you might consider analyzing the change log to see if there's an improvement to the number of changes checked in under your "flextime" experiment, as opposed to "normal working hours." Similarly, compare the bug database statistics under the "flextime" arrangment to the statistics under a more "traditional" one. I suspect you'll find the former provides better numbers.

  • Don't ding people because they don't put in the extreme hours. For example, I'm a parent. You're not going to get me to give up my weekends with my daughter very easily--if at all.

    This doesn't mean that I'm disloyal to your project, just that I'm not willing to give up my personal time as easily as I was when I was ten years younger, single, and less mathematically experienced.

    Keep this in mind when evaluating your people and the amounts of time they give you. Different people have different priorities.

  • If you reward the hardest workers, e.g. the ones logging the most hours, make sure you don't overlook others who don't put in extreme amounts of time.

    Remember, employment is a two-way contract, one best managed with mutual respect. Treat your people as adults, give them reasonable expectations, communicate those expectations, and then track how well they meet your expectations. Do not judge one employee's performance against that of another.

  • Don't expect extreme accomplishments. Regardless of how far beyond your expectations a person goes on a given project, problem, or process, each situation is unique and you need to judge your people by the same yardstick, even the superheroes.

  • Finally, there's the old "I trust my people; don't you trust yours?" argument. As long as you and your team are doing what you're asked to do and producing things to the satisfaction of your sponsors and the person you report to, the opinion of the other managers doesn't really matter.

    Please note that it's a very fine line to walk, one that must be handled with diplomacy. I'm not a terribly diplomatic person, but I will defend the arrangements I make with my direct reports, provided I can defend their efforts.

    Perhaps you might spin it as an investment or something more appealing to a bean counter. I'll leave that to your imagination.

I would definitely discuss this with your boss and with your people. See if you can find (or negotiate) a compromise that satisfies everyone. Granted, you won't always be able to do so. But, I have found an active approach is better than a passive one. At the very least, it's worth a shot.

--f

  • Comment on Re: On programmer schedules and productivity

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://79608]
help
Chatterbox?
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others musing on the Monastery: (8)
As of 2018-07-20 20:55 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    It has been suggested to rename Perl 6 in order to boost its marketing potential. Which name would you prefer?















    Results (441 votes). Check out past polls.

    Notices?