My theory on why our worklogs work for us

March 29, 2010

I mentioned in the last entry that 'worklogs', email reports of what we've done on our systems, work for my current job here at the university but did not really work for my previous job, to the extent that we fell out of the habit of writing them. As it happens, I have some theories on why this happened; in fact, I think that there are two important contributing factors, one technical and one cultural.

The first is that we have an official search interface (and private on-web archive) of our worklogs. This makes them actively useful; they are not rarely consulted, essentially make-work history, they are live reference documentation that other people can and will actively use. This creates a strong cultural pressure to keep writing them.

(It also makes it easy to refer to previous worklog messages, since each has an archive URL, and in fact it's common for worklog messages to refer to previous ones for context or fuller explanation of procedures or whatever.)

The other reason is that worklogs are a communication method between members of the group and this communication is necessary because we are not siloed into little independent areas and projects; we all work on pretty much all areas of our systems. This is very definitely a cultural issue because my previous job wound up being relatively strongly siloed, where each person had their distinct speciality that only they worked on.

(My current job is culturally anti-silo, in fact, in that people actively try to become familiar with areas that others are working on and are uncomfortable with one person being, say, the email specialist. This doesn't mean that we always achieve perfect parity of knowledge and capabilities (and I'm not sure it's even possible), but we do try to make gestures that way.)

Comments on this page:

From at 2010-03-29 07:10:32:

Sounds like the sysadmin equivalent of collective code ownership.

Aristotle Pagaltzis

By cks at 2010-04-05 11:53:57:

(Department of belated comment replies:)

I think that collective code ownership is a good analogy, and I wouldn't be surprised if many of the forces pushing back and forth for 'collective system ownership' are the same as for collective code ownership.

Written on 29 March 2010.
« The evolution of checklists in my work
More signs of Oracle's view of Solaris »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Mon Mar 29 02:00:43 2010
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.