18 January 2016
tl;dr A recent DZone post lamented how logging hours makes the author "die a little inside each time". I used to feel the same way. Then I grew up and got over it.
As is typical with my posts, I ask you to go read the original (or in this case, the DZone copy of the original) before proceeding much further; I'll quote it, but it's always better to have the source freshly in mind when reading the rebuttal.
And it is a rebuttal; just not necessarily aimed at him.
The author, Matthew Casperson, opens with:
Friday afternoon rolls around, and the obligatory call for weekly hours goes out. “Make sure your hours are up to date!” And I die a little inside. In truth, assigning hours to tickets is not actually that much work. As I have been told many times over, logging hours can’t take much more than a few minutes. So why does this simple act of corporate obedience feel like I have just been beaten over the head?
He then goes on to cite four main reasons why this "simple act of corporate obedience" makes him feel "beaten over the head":
He goes on to explain each of those four points in some detail, but I think the points pretty well stand for themselves in summary form.
Truth be told, I have a hard time arguing with him. Or, rather, the version of me from about a decade ago has a hard time arguing with him. Filling out timesheets felt so pointless and stupid, why bother? What if I just totally randomized the numbers and sent that in? Would anybody actually notice? (Nobody ever did, by the way.)
But the 2016 version of me will, actually, argue this with him. Part of it is simply professionalism---if the client or your employer says to do this thing, you do it, because it's simply the professional thing to do. (And I have every reason to believe that Matthew is being a professional and doing it, lest there be any doubt there.)
More importantly, the 2016 version of me will also turn around and argue this for him, because everything he says screams out to me that his management is Failing him.
Utterly, completely, and totally Failing him.
With a capital "F".
Let's start with the simple one first: When an employee talks about an act as being a "lack of trust", usually that suggests that other factors are in play. Matthew writes, "... all this work and effort feels completely undermined by management asking for an hour by hour account of my day. Am I that bad at my job that you really feel the need to know where every hour of it was spent?"
This is a smell that suggests that there is more at work here than just the logging of hours; employees do not feel distrusted simply because management wants a time accounting. (There's good reasons for wanting this, which I'll get to in a second.)
This is a smell that suggests that the employees don't trust management. It's really that simple; trust, like most relationships, operates on a "bank account" kind of principle, and if employees are feeling like the trust account is a little low, then it's really up to managers to (a) recognize that, and (b) work to put some trust back into the account. (Of course, that does go both ways, which is what makes relationships hard.)
This is emphasized by his last point, about logging hours as being a "lazy management technique". Listen to what he says next: "Meaningless numbers being interpreted in secret ways by management that never speaks to me...." Wow. Matthew's management has a serious problem on their hands. "Meaningless", "secret", "never speaks to me", those are three red flags in just the first half of a single sentence. This is a statement of pure opinion, despite the allusion to factual studies about employee disillusionment that follows in that paragraph, but the fact is, employee feelings are just as legit as fact. The fact that an employee feels disrespected is every bit as important as whether or not they actually ever were. Emotions are real things, and need to be treated as such.
I think a lot of the management Failure here stems from his third point.
When an employee sees an act that "feels so pointless", it's because they don't see any value within the act. If it's an act that doesn't generate value to them, then management has Failed in a pretty simple way:
Management has not explained what these numbers are for.
Honestly, when I was managing consultants working for the consulting company, it was painfully obvious where the numbers were going---these were billable consultants, and so their hourly reports were going directly into the invoices that we were sending to the client for payment. When we asked them to put a little explanation around their time, it was almost always met with nods of recognition, because they could easily understand why those might be needed.
But suppose you're not working for a consulting company---why track the numbers?
As a manager, I can certainly see a desire for those numbers---without those numbers and how they relate to story points or features, I can't really effectively track my team's ratio of estimation to actual.
And that ratio is actually very, very important.
Because when I'm called into a meeting with other departments (or other clients), and they start tossing off what they want us to work on next, I'm often asked to provide a ballpark estimate for how long this thing might take. "Oh, we know, it's just a ballpark estimate/SWAG, we won't hold you to it," they always say, but truth is, once a number gets named, it tends to "stick" and become the measuring stick against which all other things are discussed.
At that moment, my goal as a manager is to protect my team from an unachievable schedule---that is, quite frankly, the most important thing I will do all day that day. I can't just toss off a "oh, sure, whatever, let's say.... six months?" with a cavalier wave of my hand, because chances are I'm totally underestimating the work on so many different levels. My first reaction must be to stall, distract, and delay, until I can get a reasonable estimate to them.
(By the way, it's not unreasonable for them to want an estimate---contrary to the beliefs of the "No Estimate" movement that is currently making the rounds. Modern budgetary accounting requires some idea of what it will cost up front, before you commit to the purchase. Think about it this way: How many of you would buy a car with no idea of the price, agreeing to send a certain amount of money to the dealership every month until the dealer told you that was enough? It's a complete and deliberate "head in the sand" rejection of how 99.9% of the world's corporate budgeting and internal accounting works.)
Now this doesn't mean I need to create estimates down to the final story---a SWAG is still appropriate here. But if I have that velocity metric, I can take a couple of hours, do a rough pass over what they want, come up with a number of stories or feature points that are within the same order of magnitude (hopefully) of the actual result, and then multiply that times our velocity to have a first-pass SWAG that at least puts it in the right ballpark.
But that's just me.
In some cases, managers use these numbers as a sanity-check, a way of feeling out how the team is doing, without having to tear them away from their actual work with one-on-one meetings. Think about it this way: which is less intrusive to you as a programmer, to spend a few minutes at the end of the week to fill out a simple report that will give me a high-level view of what you're doing (and by the way, why are you spending so much time debugging? Didn't we get that super-nasty bug fixed last week? I think I need to follow up with you), or would you rather pull yourself away from your desk for an hour a week so you and I can go over all of that in person, when you will probably forget half of the details that would show up in a report?
Personally, I don't like the reporting approach---I would much rather have the one-on-ones, because then we can talk about a bunch of things that wouldn't normally go into a status report. (Actually, I tend to do both---at the consulting company, I looked at the submitted timesheets, and had one-on-ones with the team leads, so that I could both passively get a feel for what was going on, and then validate---or not---that same feel via an active conversation.)
Is this an act of lazy management? Maybe. But what developers need to realize is that developing software is not like constructing a building or a house, because 98% of what they do is entirely ephemeral and very difficult for anybody else to see, even other software developers. (Try it sometime---observe what another developer is doing and the progress they are making without talking to them about it directly, and then try to describe what progress you've seen them make or not make. Even with rigorous source control practices and team-wide discipline around check-ins and merges, it's really, really hard.) If you're not a software developer, trying to understand what your team did today can be almost downright impossible without asking them.
So they ask them, in the form of a report.
Perhaps Matthew's manager isn't in the same position that I am, or isn't asked (and held) to estimates that early in the process. Why, then, might the numbers be necessary?
I could posit a few theories (Accounting needs them in order to know how to charge time against internal budgeting reports, or HR needs them to feed into the payroll system so that they can keep track of your vacation time, or the CTO wants a roll-up report each year of how much time was spent on different activities within his organization because he is convinced they are spending way too much time in debugging and maintenance and he needs those numbers so he can go to the CEO and the board and ask for a larger budget to accomodate their requests for the next fiscal year, or...), but any theory I come up with is entirely just a flight of fancy, and entirely irrelevant; the point is not why I think the numbers are important, but that Matthew's management has not said why they think the numbers are important.
Of course, the other possibility is that the management Failure occurs much, much higher up, and that this time-tracking was established by the previous (or the previous previous) CTO, and right now those numbers just go into a report that nobody ever reads. Which is its own management Failure.
Napoleon Bonaparte, one of history's greatest generals, was less fond of the precise marching orders than the various generals (particularly the Prussians) that he faced. His approach was far "looser" (and arguably much more agile); he would split his army into pieces, and to each of his Field Marshals he would give certain tasks.
But before he turned them loose, he would also make sure that each of the Field Marshals also understood what the overall goal of the campaign was: "We must take that town there before we move on the city, so that we have a place by which to set up the cannons to bombard the walls.", for example. In this way, when he turned them all loose, they all understood the larger picture. Then, when one saw an opportunity to further the overall strategic goal, they could act on it quickly, without having to send a messenger back to Napoleon himself to find out if that was something they should do. If the town in question lay open and undefended according to their scouting reports, they could dispatch a battalion or two to seize it and hold it. Then, when the rest of the French moved into their various positions, the town was already seized, and Napoleon could advance his plans that much more quickly.
Management that fails to explain the "Why" of a particular policy is effectively falling into that most heinous of management Failures, that of treating their employees like cogs. No, employees can't (and shouldn't) know everything that a manager knows---certain things, for legal and privacy reasons, must remain confidential. Lots of data about the company must remain in the hands of only a certain few.
But the hours policy is very, very likely not to be one, and it's even more highly likely that even if there are places where these numbers go that the employees can't/shouldn't know about, there's other reasons that we can talk about, to give them a sense of "why", and let them see that those few minutes spent every Friday to fill out the damn timesheet actually serves a useful purpose, even if it's not useful to them personally.
Because being told to do something that serves no useful purpose to anyone simply undermines your credibility as a manager. And that's probably the worst management Failure of them all.
Just after I posted this, there was an email from the Harvard Business Review entitled, "The Best Bosses Follow These 5 Rules", and they read like a complete counterpoint to everything Matthew described:
If Matthew's management adopted these five, particularly #1, #2 and #3, they would immediately seek to manage him as an individual, which would lead them to finding out more about what makes him tick, and that would lead them to following up on the time reports. They would seek to provide a sense of meaning around those silly reports, and his feedback could go into perhaps even making the reports better, depending on what the reports are actually used for.
Most of all, if they were good bosses, they'd be embracing #5, and we probably wouldn't have had to have this little conversation.
Good chat.
Last modified 18 January 2016