Re: (OT)Employee Status Reports or Shameless self-promoting

[dws]

I always have felt that such reports are only required when your boss is too stupid and/or lazy to understand what you do, let alone remember what they asked you to do in the first place!

Having been a boss several times, let me offer up the other side of this. Status reports serve several purposes. First, they provide a uniform way of gathering some of the information that goes into annual reviews. (A boss should be taking notes along the way, anyway.) Think of this as a record of what happened. You might write something like

"I reworked the vendor's example script, breaking out useful parts so that we could reuse them, and adapting the script to provide two command-line tools that use our database."

Second, status reports provide a way for a boss to verify that you're doing what they expect. It's a poor way, but it's a way. You'd think it would be a simple matter of wandering around and looking, except that takes a lot of time, and bosses are often just as starved for time as you are. (There's often nuttiness going on at a higher level that you see very little of.)

Third, status reports provide weekly time for you to step out of your rut and reflect on what you've been doing. Most good developers will do this on your own, but requiring the status report is a way to stick this opportunity in everyone's face.

Fourth, reports are a way to gather input from people who might otherwise sit on it. Many of the managers I've worked for have asked for a "Problems/Suggestions" section on each report. In your case, a reasonable thing to note (assuming you haven't done this already) is

"I have concerns about the quality of the work we're getting from our vendor. The example they provided was poorly written."

And fifth, there's the possibility that your boss is also under a requirement to provide a status report. Asking his/her staff for reports provides raw material, making his/her job somewhat easier.

[hv]

I once worked for Electronic Arts, and they added one feature to the weekly status report that helped to make it seem less of a useless chore: the status reports were all collated and re-summarised as they passed up the chain, but the resulting document was then annotated during discussion at the board meeting, and that then passed back down the chain for everyone to see.

It really focuses your mind when your name appears in the top level report, and the chairman of the company has scrawled a 'good job', or maybe a 'why is this bozo still working for us?' against it. :)

Hugo

[Aristotle]

Forth reports are a way to gather input

FORTH for reports? Perl is excellent at them, too. :)

Makeshifts last the longest.

[adrianh]

And fifth, there's the possibility that your boss is also under a requirement to provide a status report

Indeed. Having a good status reporting system and a solid paper trail can save an enormous amount of legal hassles when it comes to contract disputes. You often find that requests for these sort of papertrails start in a legal department (or after a costly dispute ;-)

I found the best way to do them was to waste a lot of time writing a bunch of perl scripts to help me keep my timesheets and produce appropriate summary reports ;)