This is a bit of an addendum to my post the other day about working from home. The definition of what counts as "work" is not as clear cut as one might think, particularly when you are working with ideas rather than widgets.
When I was in college, I had a job in the cafeteria washing pots and pans. It was pretty obvious what the content of the work was (all the dirty pots and pans at the wash station need to be cleaned) and it was easy to see progress being made (the stack of unwashed pots and pans getting smaller and smaller). There was a standardized "three sink" process for how things should be cleaned, from removing large food debris and scraping in sink one, to soaking and cleaning in sink two, to soaking and sterilizing in sink three. Every team used the same process. Of course, throughout the meal service more dirty pots and pans would be added to the stack, but after working a few shifts, it was relatively easy to internalize the ebbs and flows of when the dirty pots and pans would arrive and to pick a work tempo that was sufficient to avoid terrible backlogs.
With knowledge work, such as coding or report writing or analyzing data, it is less obvious what the content of the work is. Sure, there are obvious work products, such as working code, a completed report, an insightful analysis, etc., but the process to get to the completed product may not always follow the same, predictable steps. (One could argue that at the 30,000 ft view there is a process, in the "plan the work, work the plan" kind of way, but there is still a huge range of variation in the actual steps.) The exact contours of the finished product often evolve as the work is undertaken, as knowledge work is inherently iterative in nature.
The iterative nature of the work also leads to another challenge -- dead ends. Time spent not getting pots and pans clean in a cafeteria could be seen as "shirking" one's responsibilities. But what about spending time working on potential solutions that don't pan out? Or doing some reading about a statistical technique to analyze the data that you ultimately decide is probably not appropriate? Is that working or is that shirking responsibility? What if it takes you in inordinate amount of time to realize that the reason your code wasn't working wasn't due to a faulty logical flow in the function you were looking at, but rather a mislabeled variable in an upstream function? Does that mean your misguided troubleshooting efforts should not be counted as work?
And, to bring it back to the WFH / RTO debate, if you are pondering why your code may not be working while staring at the ceiling in the office with your butt planted firmly in the seat, does that count as "work" whereas pondering why your code isn't working while taking your dog out for a quick walk so it can relieve itself does not? (And does gossip around the proverbial water cooler at work count as long as you are in the office, or should you be taking personal time to do that?)
Of course, as with all things, the ultimate answer will be "it depends" and is highly dependent on context. We all have more and less productive days. Sometimes our first attempt leads to a reasonable solution, other times it takes a bit of trial and error. We may occasionally go down rabbit holes trying to research or code something only to come up empty handed. If we are generally productive at a reasonable timescale (weeks, months), variation is par for the course in knowledge work. But if we are just generally unproductive, then it may be time to take a closer look at where we might have room for improvement (maybe we are too easily distracted when we WFH) and/or where there may be systemic aspects of the work which need to be addressed (to quote John Seddon, "If you want someone to do a good job, give them a good job to do").
No comments:
Post a Comment