Creative Commons 3 License
Here’s a bit of a diversion from my normal data-oriented posts, but in a previous job, as a data-driven systems thinker it was natural for me to explore and try to understand how to measure productivity and cycle time. The work outcomes that the organization needed to understand better tended to be heavy on system design tasks but also extended into the work needed to set up product lifecycle cash flow.
Background on Productivity in Design Work
It was always a struggle to measure productivity (and cycle time) in this kind of environment, because it was extremely challenging to identify and measure the most important, value-producing events in the workflows. For instance, in system design, it was extremely easy to measure the productivity of one of the major bottlenecks in the process… (drum roll)… drafting! Why is drafting a bottleneck in the design of a system? Well, not only does someone in a factory have to assemble the product you just designed, but you also have to ensure that the supply base can be enabled and protected. Often the bill of materials on a drawing is the entry point for most of the complex activities performed by the supply chain organization. Additionally, quality needs to be protected and the “recipe” for building your system cannot be lost. All of these objectives, always made drafting a long, tedious process that designers and manufacturing engineers both expressed impatience. I went a bit long on this, but maybe you can see why productivity is easy to define and measure. The drafting team is working on one product, generally is not multitasking, and start work and complete work date and times are easy to capture – allowing the cost of the drafting product to be easily normalized by the hours spent (resulting in dollars per hour). Perhaps even the whole process can be measured from logs built automatically by the drafting software.
However, most of the rest of the design process is not so easy to measure. It spreads across many teams, all of whom have some sort of dependencies on other teams, each of which has it’s own “special sauce” and tasks which build upon tasks. Mastering queueing theory helps in manufacturing facilities where assembly tasks depend on multiple preceding steps is hard but doable because in manufacturing, the product is generally always visible to the eye. In design, however, the product can be ideas, processes, models, and pieces of documentation and is rarely visible in the same way.
So with that as background, I recommend the following YouTube video if you have interest in improving your true productivity in a “knowledge work” environment. I agree wholeheartedly, but watch the video and I’ll add my fourth principle to Cal Newport’s three that he offers.
OK. Did you watch the video? What does Cal offer up as his three principles?
- Do Fewer Things – Or better, “Do fewer things at once”. We all can chant “multitasking is a productivity killer”, but most of us still think we’re pretty good at it. Regardless, however, the point is not that you’re bleeding productivity, but that you’re probably doing things that have no impact on your life, your enjoyment of your work, and even on your final work product.
- Work at a Natural Pace – This doesn’t mean “work slowly” as one might imagine, but really involves something I think about as working as an extension of your life. How do YOU work best? Should you spend more time putting the thing you’re working on down and thinking about it more? Do you work better if you spend time to kit up the parts you’re assembling (or build UML models of the code you’re building) first?
- Obsess over Quality – I really like Cal’s point in the video that if one invests in quality tools (i.e., my Macbook that really makes me happy to code or write on) it’s a way for you to signal to yourself that your work is important and you ought to ensure you do the important parts as well as they have ever been done. He uses his grad school $50 lab notebook as a great example of this. How can one take lazy, incoherent notes in a really nice, expensive lab notebook (ostensibly with a very nice pen you’re proud of)??
My Fourth Category as Promised
Here’s Tod’s add. Maybe this is particularly me or maybe this is a pretty general thing, but here it is if it helps you.
4. Manage your Motivation: Your work productivity benefits (at perhaps an order of magnitude) when you are motivated to do it. For years I have pondered the difficulties and tricks for optimizing motivation cycles and have found that I do fabulously better work when I am “all in” on getting that work done. Sometimes, of course, one unfortunately doesn’t have the option of working on the “blue widget” when the motivation hits because the boss is impatient. But I’m going to guess that during those times, “blue widget” productivity and quality suffer significantly because they’re being worked on out out of obligation and not desire. Perhaps these times correlate strongly with surfing Reddit or YouTube?
It is also impractical if your ability to manage your motivation is weak and your motivation cycles are too sporadic. A cursory scan of my blog would probably reveal that I love to write (see my series on self-publishing). Unsurprisingly, I find that I write my most interesting and creative passages when the motivation to write hits, but I have also learned that I really need to create “commitment devices” to help ensure that I can channel that motivation into daily writing sessions. I imagine (or hope) that this is universal, as I have heard similar things from other writers or musicians.
Recap
Productivity in knowledge work is really hard to get one’s head around. It’s hard to define, difficult to measure (and automate measurement), and really challenging to normalize cost with the hours spent on the task. It feels like Cal Newport’s suggestions won’t necessarily resolve this difficulty, but it might allow the improvement of productivity — measurement aside — by focusing on the productivity of the most critical parts of the task.