Tuesday, June 13, 2017

Tracking Work

Mark Dominus:

The way I have been able to escape this horrible trap is by tracking every piece of work I do, every piece, as a ticket in our ticketing system. People often come to me and ask me to do stuff for them, and I either write up a ticket or I say “sure, write me a ticket”. If they ask why I insist on the ticket (they usually don’t), I say it’s because when self-evaluation time comes around I want to be able to take credit for working on their problem. Everyone seems to find this reasonable.


Instead of thinking “Why didn’t I finish big project X? I must have been goofing off. What a lazy slacker I am” I think “holy cow, I resolved 67 tickets related to big project X! That is great progress! No wonder I got hardly anything else done last fall” and also “holy cow, X has 78 resolved tickets and 23 still open. It is huge! No wonder it is not finished yet.”


I think it is important to maintain the correct attitude to this. It would be easy to imagine ticket management as unproductive time that I wasted instead of accomplishing something useful. This is wrong. The correct attitude is to consider ticket updates to be part of my work product: I produce code. I produce bug fixes. I produce documentation, reports, and support interactions. And I also produce ticket updates. This is part of my job and while I am doing it I am not goofing off, I am not procrastinating, I am doing my job and earning my salary. If I spent the whole day doing nothing but updating tickets, that would be a day well-spent.

3 Comments RSS · Twitter

Measuring success based on closing tickets sounds a lot like the "fee for service" model of medicine, which, for example, rewards hospital readmissions with additional fees paid to the physicians and facilities, rather than something based on quality or value.

@Sean Right, I don’t think closing tickets should be the measure of success. But it’s helpful to know where the time is going and to record what you learn along the way even if you aren’t billing that way. The opposite medical analogy would be getting home from the hospital and having no record or memory of what tests or procedures had been completed. You don’t feel much better or know where you are in the process, just that you have a bill to pay.

Amen. I can see both sides as developer and primary care doctor. I've had a great deal of benefit in keeping track of my productivity in getting non-face-to-face medical work done, while hopefully not compromising on quality with a large amount of not-directly-reimbursed work (e.g. chart review, documentation, phone calls and online messages, insurance, medication prior authorization, coordination of care). My tool for this is currently an Emacs buffer and a couple of macros, but better than nothing! The US is not great in this area, particularly in primary care. At least Vermont is about to start a trial of an alternate payment model - we'll see... (unfortunately I'm going to be elsewhere starting in 2 weeks).

Leave a Comment