In my quest to do my best work at all times here at the company, there have been many times when I did something that in my judgment needed to be done — but then afterwards I struggled to determine what the proper way would be to log that time.
I have found recently that I am not alone in this struggle. One group of developers that has particular struggles with this issue is that of the leaders, the top performers. Could it be that as an organization we’re unwittingly adding unnecessary friction to the day-to-day work of many whose work and leadership we most need to support?
I think so. Allow me to explain…
Suppose I spend a couple of hours talking with a co-worker about why it seems to me that flexibility is a necessary ingredient for developer productivity, the extent of the problem here, and specific answers we might offer if our opinions were sought in beginning to correct the problem.
It’s hard to see how this has anything directly to do with the security enhancement task I’m currently working on. So poppeth the perennial question: “How would I log that time?”
Five different approaches come to mind:
- Log it to the task at hand
- Log it as “Administrative” time
- Log a separate task
- Do it on your own time
- Don’t do it (at least not now)
Let’s look at each of these in turn…
1. Log it to the task at hand.
- These sorts of activities are necessary day-to-day “sprinklings” — through them, I keep on top of my craft, which is important for the company to remain competitive long-term.
- In the end I tend to work more efficiently on the task at hand when I also explore other longer-term thinking and doing that comes up along the way, so there may not be a time hit, especially on larger projects.
- It may appear sneaky or dishonest to log to a task time not spent strictly on that exact task.
- It may appear that the developer is hiding inappropriate behavior or getting away with something dishonorable.
- It might even be sneaky, dishonest, inappropriate, and dishonorable!
2. Log it as “Administrative” time.
Looking through the tasks assigned to me, I don’t see any that involve this issue. (I proceeded to discuss it, not because it was part of a task assigned to me, but because the idea came up and, on my own initiative, I identified that it seemed an important topic to discuss.)
None of alternative 1’s worries about dishonorableness.
- If I don’t miss my guess, administrative time is seen as unproductive time, maybe sort of as necessary waste — in that sense, it seems misleading to log these things as administrative time
- We’ve been directed to limit the administrative time we log to basically at most one hour beyond our weekly team meeting, and that’s not enough flexibility to cover the sprinklings (such as the one we’re discussing) that might happen in a given week.
3. Log a separate task.
If logging to the current task doesn’t seem quite right, and logging an administrative timesheet isn’t quite right, why not log a task for the exact issue we’re exploring?
- Doesn’t suffer the drawbacks of either alternatives 1 or 2.
- Allows tracking time at a finer-grained precision (if you really can separate “sprinklings” from “purely” working on a task, which I’m not certain of).
- In its current form, our Product Development Methodology (PDM) doesn’t support working on tasks outside of the official approval process. Rather, part of its map to increased productivity involves ensuring that developers are not working on other things (to be fair, it is counterintuitive that this would be a problem, isn’t it?)
- It seems most likely that the visibility gained by logging separate tasks for these things would lead to a denial of permission to work on them. Some way would need to be found to build the developers’ trust so that they could be confident that logging time at this more detailed level would not be rewarded by the loss of freedom to do what, in their judgment, they need to be doing.
- Logging tasks can take the focus away from the issue being worked on, breaking the flow and causing a hit to efficiency. (This could be mitigated by requesting only a bare-bones task with some form of description of the activity, rather than the fuller documentation required when a task might be worked by a different person.)
4. Do it on your own time.
It might be stated like this: “These sprinklings you’re talking about don’t sound bad, but they don’t seem to pertain to any initiatives you’re slated to be involved in right now. I don’t mind that you’re interested in this, but I can’t allow you to use time during work at this point (we’re so far behind already – how could I justify it to those I’m responsible to?) If these things are that important to you, maybe you can do them over lunch, or evenings or weekends.”
Avoids the moral qualms of #1, the negative perception fostered by and misleading qualities of #2, and the current unrealisticness of #3.
- If these things really are important for the company, how can the company ask for additional personal sacrifice on the part of developers who take the initiative to pursue them?
- For developers who believe that flexibility to do these things is important to the company’s remaining competitive (though they may not have been able to articulate that in so many words), this is another way that “we don’t trust your judgment” is communicated.
5. Don’t do it (at least not now).
“This is just not a direction the company is going right now. Perhaps next quarter there will be a chance for some of this; or write up the idea and put it in the queue of the team that’s responsible for this type of thing.”
- For a particular idea, maybe someone else is already pursuing it. There’s no reason to duplicate work — it could be worthwhile to check that.
- By not doing it now, we avoid the moral qualms of #1, the negative perception fostered by and misleading qualities of #2, the current unrealisticness of #3, and the additional personal sacrifice of #4.
Admittedly there is give and take. No one gets everything they want all the time. But when there is a pattern of denial of flexibility/permission/trust, we see some of these effects:
- Developers feel that they are powerless to effect the good they see they could do.
- Developers who try to exercise initiative may begin to feel that there are barricades on all sides.
- The discouragement bred by the systemic inflexibility results in much lower productivity (even though the strictures are in place in the name of increased productivity!)
- Many top performers may feel that to remain top performers they must get free of the shackles, and so leave the company.
- Those that remain are in danger of losing their edge, because there is so much overhead involved in getting permission to do each thing that allows them to stay sharp that it’s just easier to lose the passion and downshift into a new gear: just try to cope, survive, get by.
Whatever alternative we choose, we must not squelch the spirits of those who are working hardest to make our company great. The stakes are high!
Updated 2/13/2008 – Revised the introduction and added conclusion