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…

Study Hacks - Cal Newport

Thoughts on "From Productivity to Workflow Engineering"
  1. Josh says:

    March 29, 2016 at 9:29 am

    I love the concept of workflow engineering. Remind me of Dr. Daniel M. Cable’s ‘Change To Strange’:

  2. Miguel says:

    March 29, 2016 at 10:45 am

    Aren’t you re-inventing/re-wording an already existing concept called "Process reengineering"?

    Just asking…

    1. Study Hacks says:

      March 29, 2016 at 12:37 pm

      That’s more or less exactly what I’m doing: pointing out that the current state of knowledge work is like the early industrial age (lots of exciting new technologies but not much thought on how best to use them). Just as the industrial age eventually evolved under increasingly complicated management theories (e.g., how do we get the most return out of capital investment), the same wills soon happen for the knowledge age. Ideas like business process reengineering, when applied to knowledge work, will highlight the supreme inefficiency of our current workflows, which are built around a generic, one-size-fits-all devotion to unstructured inboxes.

      The term business process engineering, however, is not an exact fit as it’s a practice that includes in its definition pieces specific to industrial business restructuring.

      1. Prasad says:

        March 29, 2016 at 5:51 pm

        I feel that sometimes new words are required to describe a ‘first principles’ concept because existing business jargon has been mis-used and overused. So workflow re-engineering is a good word to use.

      2. Miguel says:

        March 31, 2016 at 10:42 am

        So, you basically want to coin for yourself the latest re-invention of "process reengineering" in the knowledge worker realm…

        I can certainly see the marketing appeal, but as a scientist shouldn’t you be more focused on building on existing concepts (and maybe clarifying/correcting them in the process)?

        Also, I see danger in carving out the "knowledge work" from the "remaining work processes". After all, the developers you use in your example do not exist in a void… their work inputs and outputs feed other knowledge workers and ultimately customers and so on… it is a business process, whether you like it or not (you could even see it as a manufacturing process of sorts)

        I understand process re-engineering enjoys a bad rep but I do think this needs a little bit more of research and rethinking.

        Don’t get me wrong, you are asking the right questions and I agree with what you are saying but I think it is worth spending more time framing it in the bigger context.

  3. Jeff Geisler says:

    March 29, 2016 at 12:03 pm

    Here’s an example of "workflow engineering". Toyota adopted the radical approach of STOPPING the entire production line when they found a problem. It’s one of the core reasons they have some of the lowest labor hours per vehicle stats in the business.

  4. Jesse says:

    March 29, 2016 at 2:50 pm

    Thanks for this Cal –

    You’ve taken an idea that resonates strongly with me, and is best captured by Daniel Quinn in several of his books like this:

    "If the world is saved, it will not be saved by old minds with new programs but by new minds with no programs at all."

    And applied it to a part of the world that badly needs a retooling. As an IT pro by default – and a Wellness Coach by design – I can attest to the fact that many of the processes we use daily are horribly inefficient, and every time a company I’ve worked for "restructured" us, all it did was superimpose a new process on top of the old, inefficient one.

    I look forward to seeing what direction you take this concept in the future!

    Be well –


  5. Joe Conley says:

    March 29, 2016 at 2:53 pm

    As a programmer, I find myself torn between the benefits and drawbacks of tools like Slack. Overall I think Slack is the "best bad option" we have today for intrateam communictaion. On one hand, Slack does allow for deeper work as you have a high level of control over how and when you get notified. Working on a physically distributed team requires some level of online collaboration (especially as I’m a senior programmer and do need to help resolve "blockers" for the junior folks). I typically mute most/all of the channels and only allow direct messaging to interrupt my workflow, which has proven effective as most chatter/small talk tends to occur on a "general" channel anyway. And if there’s something super-important that I’m working on I can simply exit Slack.

    On the other hand, it’s always tempting to heed the unrelenting call of Slack (i.e. what’s going on at my favorite channels). Similar to social media, staying away from Slack most of the day almost builds up a "kinetic energy" such that the need to "check in" grows the longer you stay away. This is certainly unnatural and doesn’t help if you’re at a tipping point of being productive/distracted.

    Ultimately I agree with the overall sentiment of the post. We ultimately need tools that optimize our work, rather than attention-seekers whose goal is to keep you in the app as much as possible.

    1. Jonathan says:

      March 29, 2016 at 10:13 pm

      I think the concept of Slack though helps a ton with companies replacing email and allowing for more consistent communication. That said I think people should be more then willing to mute slack when available to and allow for concentrated and deep work. From a support and response perspective, I love Slack and find that companies that integrate Slack are able to get back to me quickly which is awesome!

  6. Sam says:

    March 29, 2016 at 7:30 pm

    Cal, I’m a bit puzzled where you’re going with this since you’re not in the business of manufacturing.

    Translating the "product" from Ford and Toyota who deliver high-quality cars to your context would be your "product" of writing more high-quality papers. This is where you lose me–unlike car manufacturers you can’t write the same paper 5 times over with a repeatable process. There are many elements of good writing that are common between papers but you need new original content (=proved theorems) for each paper you write, and producing this content and coming up with a good pitch for why these theorems are important are the two major time drains of paper writing.

    1. Spencer says:

      March 30, 2016 at 12:38 am

      I don’t think Cal’s recommending that you figure out how to churn out research papers like Ford’s assembly line churned out cars.

      It seems like the point is to stop and ask yourself, "if my goal is to publish X research papers in top-tier publications this year, what is the absolutely most effective way to get there?" And then to engineer your workflow from there.

      The result might be something that’s radically different than what conventional wisdom dictates or what you see other people doing.

      You might decide to only respond to emails at a pre-determined time each day, get off Facebook, get up at 5am, or engage in any number of new behaviors.

      The specifics of what you decide to do aren’t important, as long as your resulting workflow supports the production of your desired outcome

    2. Brendon Robinson says:

      March 31, 2016 at 11:43 am

      Hmm, that’s a good point. In Cal’s example at Ford, the improvement was to make the work more consistent and repeatable. That sounds like the opposite of what Cal says about deep work – they went from a deep, craftsman approach to mindlessly and repetitively cranking widgets.

    3. Jeremy B says:

      March 31, 2016 at 4:09 pm

      I understand your point, Sam, and my initial reaction as a long-term reader was also, kinda "whu…?" but it *is*, as Cal notes, "metaphorical". The underlying point is about making a complete change, not just an adjustment, to how you work. There’s a couple of other, more information age, examples given, but here’s another one: normally, I’m methodical about my e-mail, cranking out the responses at set times, filing stuff that needs to be done later, and so on, but it takes time and concentration. I have a deadline this week, and I’ve barely opened it. I’ll have an inbox hangover next week, but nothing fatal – and next deadline, I’m just going to put on autoreply for the week, and not open it all (career destroying stuff, someone will phone me). I think that is a small example of what Cal is getting at.

      1. Jeremy B says:

        March 31, 2016 at 4:15 pm

        (An example, I should note, made before I’d read the post about e-mail that comes just before this one…)

    4. Study Hacks says:

      March 31, 2016 at 5:14 pm

      Here’s the right analogy:

      In the industrial sector, the major capital investment was factories. Innovations like the assembly line allowed you to get the most value out of these assets.

      In the knowledge sector, the major capital investment is in individual brains. Similar innovations are needed to figure out how to get the most value of these assets. This includes the quality/quantity of what’s produced by the brains, but it also includes the need to keep the brains satisfied and happy in their work, as if an employee burns out and quits (ahem, Google), it’s a bad return on investment. Once we see things through this lens we are unlikely to stick with workflows purely because they’re simple, convenient, and cheap (e.g., just work everything out over email), but instead figure out what actually produces the best work and makes the workers the most satisfied.

  7. Greg says:

    March 29, 2016 at 7:40 pm

    Pat Flynn made more than $130,000 in February. He’s smart not to cut his fans off.

    1. Study Hacks says:

      March 31, 2016 at 5:18 pm

      The bulk of Flynn’s income comes through affiliate links which are heavily dependent on lots of traffic. McKay noted that quitting email had no effect on his site traffic. Assuming the same would hold for Flynn I don’t think there is much causation between his email habits and his earnings.

  8. Elizabeth Saunders-Time Coach says:

    March 30, 2016 at 2:22 pm

    I agree with your assertion.

    I’m going to take some time pondering how this applies in various areas of productivity.

    To your brilliance!

  9. AC says:

    March 30, 2016 at 9:10 pm

    There are people who already are applying "Lean Manufacturing" concepts to knowledge based work. In software development, you have "Scrum" and "Kanban" methods which fall under the "Agile" banner. Jim Benson( and Dan Markovitz( have written books on using lean methods to improve personal productivity. They are all worth checking out.

    1. Study Hacks says:

      March 31, 2016 at 5:20 pm

      These are great examples of workflow engineering in action…

      For example, I think if you combine SCRUM with no email (rely on a small number standing meetings to coordinate, ask your questions, tell people what you need), and the hiring of extra assistants to take care of administrative stuff on behalf of the main thinkers — you’d real up value production.

  10. Francis Wade says:

    March 30, 2016 at 9:14 pm

    I think workflow engineering is a useful phrase. Plus, I think the "widget" needs to be identified so that we are all focusing on the right object.

    I happen to be an Operations Researcher/Industrial Engineer by background. I started re-looking at time management solutions in earnest after falling into time-stress. I discovered a gap. After reading several books and training programs I realized that no-one had nailed the "widget."

    In the world of industrial engineering the "widget" is an abstraction, meant to represent the physical object that makes its way down an assembly line. In the example Cal gave above, a partly assembled car would be the main widget which would be combined with other minor widgets to produce a car.

    I carved out a new definition also… I called it a "time demand" and defined it as an "internal, individual commitment to complete an action in the future." Social scientists would classify it as a "psychological object" that is discrete, occupies time and is created with certain subconscious attributes such as urgency, importance, deadline, context, etc.

    These objects are intangible, but they are discrete and are limited in number. Quite later I discovered that Drs. Oullette and Wood called it a "conscious intention."

    Further research showed that we all start to create time demands as adolescents and the habits required to manage them in our teens. Usually, they are set in stone by mid-adulthood.

    Our generation is the first to confront the powerful cocktail of mobility, the Internet and an explosion in information. The result is that we create more time demands than our self-taught, teenage methods were ever designed to handle. Persistent failure drives us to look for solutions… upgrades to the way we manage time demands so they don’t fall through the cracks.

    These uprades occur primarily in 7 practices – Capturing, Emptying, Tossing, Acting Now, Storing, Scheduling and Listing. In my work I describe ways to produce a systematic improvement in each practice in a structured way.

    Over on Quora, I answer the question of "new research topics in industrial engineering" by describing the need to model flows of psychological objects in general, giving the notion of time demands as an example. Although this widget is remakably different from its physical counterpart, I argued that they share enough properties to attract researchers in topics like workflow engineering.

    Here’s the link – do enjoy!

    1. Study Hacks says:

      March 31, 2016 at 5:23 pm

      These are interesting points…

      My sense is that we need to return to more concrete widget definitions. We have shifted people toward these generalist roles mainly to avoid the hard work of figuring out specific work objectives and processes, and putting in place the overhead needed to support them. It’s easier, for example, for me to tell a new hire that they should just be ready to do what I need, and I’ll email them as things pop up, then to specific the 2 things she will be doing, including the process by which the work is done (how inputs are provided, how questions and feedback are generated, etc.)

  11. Raymond says:

    March 30, 2016 at 9:20 pm

    Cal, would you ever use dual monitors? I don’t know how else to ask you this question but you’re the only person with the answer.