From Productivity to Workflow Engineering

March 29th, 2016 · 44 comments

The Ford Transformation

The craftsmen hand-building cars at the Ford Motor Company’s Piquette Avenue assembly plant in the first decade of the 20th century were, among other things, impressively productive at their tasks.

Two or three workers would gather around each partially-assembled car, taking parts, checking their fit, adjusting them on a metal lathe as needed, then checking the fit again, and so on. To watch them work would be to watch experts practiced in their movements and efficient in their tool use.

But as we now know, this productivity was irrelevant, as their approach to the work as a whole was sub-optimal.

By the second decade of the twentieth century, Henry Ford perfected his assembly line model and combined it with a commitment to producing interchangeable parts.

This new workflow was less natural, required significant capital investment, and introduced many new logistical headaches: but it also unleashed a level of value production that the old method of car construction could never match — no matter how skilled or efficient its practitioners.

Beyond Productivity

This story illustrates a division that I think will come to occupy an increasingly important role in the knowledge economy: the difference between productivity and workflow engineering.

To understand this difference, let’s begin with a key definition.

A workflow describes a general means or approach by which a professional goal is pursued.

(For example, in the Ford case study, in the early years of the company the primary workflow for car construction centered on a dedicated team hand-adjusting and assembling the relevant parts of a specific car.)

Productivity focuses on executing a given workflow more efficiently.

Workflow engineering, by contrast, focuses on optimizing the general means through which the relevant goal is pursued. It is defined by a willingness to make radical and inconvenient changes if the ends justify the means.

For example…

• A team of computer programmers making their intra-company communication more efficient by adopting real time tools like Slack, and perhaps even integrating the tools into their code editors so they can reply to missives without switching applications, is an example of standard productivity thinking.
  Realizing that programmers produce much better code if you minimize cognitive context switches, and therefore eliminate their email and Slack accounts altogether to ensure deeper work, is an example of workflow engineering.
• Similarly, to draw from an earlier case study, media entrepreneur Pat Flynn hiring a high-priced executive assistant to help him answer reader email more efficiently is an example of standard productivity thinking.
  Fellow media entrepreneur Brett McKay instead simply removing his email address from his web site and replacing it with a PO Box address is an example of workflow engineering.

The goal with workflow engineering is not to maximize convenience or to minimize cost and disruption. It is instead to start from a blank slate and ask: “if my goal is X, what is the absolutely most effective way to get there?”

This, in turn, requires a willingness to consider major, annoying, complicated changes if you have evidence that they’ll end up helping you ship a hell of a lot more metaphorical cars.

Workflow engineering is a concept I’m still toying with, but I think it has the potential to capture well the differences in my thinking regarding the future of work as compared to how most experts tend to talk about getting more things done.

Stay tuned…