Explore a better way to work – one that promises more calm, clarity, and creativity.

From Productivity to Workflow Engineering


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…

47 thoughts on “From Productivity to Workflow Engineering”

    • 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.

      • 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.

      • 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.

  1. 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.

  2. 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 –


  3. 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.

    • 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!

  4. 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.

    • 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

    • 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.

      • Yes!!!!! Exactly. I think there’s a dis-analogy between what Ford did, which was to atomize the work of building cars so less skilled people could be employed to do the work, and the kind of work Cal does.

    • 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.

    • 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.

    • 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.

  5. 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.

    • 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.

  6. 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!

    • 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.)

      • Agreed. Some examples:
        1. Project manager to team member: “You need to get this stuff done.” (The popular book, GTD, uses the word “stuff” liberally as its widget. The lack of specificity is problematic.)
        2. Annual appraisal: “You should develop better time management skills.” (Time cannot be managed… so the advice can be interpreted in any number of ways.)
        3. Coaching tip: “Make better use of your memory.” (The only way to scale the management of time demands so that more tasks are well-managed is to avoid the use of memory.)
        4. Company norm: “He who responds to email the fastest is the most productive.” (This crazy metric is widely used as an indicator of “good” skills.)

        These are all examples of the fuzzy communication that frustrates employees who are trying to do a good job, but together with their colleagues, lack the distinctions/knowledge/grammar required to do so.

        On a related topic… I was inspired by a book on a different psychological object that you mention in your reply… promises. (Although, arguably, a “time demand” is a kind of internal self-directed promise.) Jan Bergstra’s book (which in its draft form was called “Promise Theory”) deals with the workflow of promises. It’s an outstanding piece of work, building on insights from Weinograd/Flores’ “Understanding Computers and Cognition.” Bergstra offers up a way of measuring promise flow between people that is groundbreaking. I recommend it!

        By quoting these researchers, however, I don’t mean to imply that these are well-researched fields. I had to search hard to pull them from the weeds of different, disparate academic thickets. Finding anyone interested in “the workflow engineering of psychological objects” is very hard work. Experts in the fields of psychology and engineering simply don’t sit down together very often for coffee…

        Your post bravely opens up the can but the worms are very few and hard to find. However, this particular can is one which contains knowledge we use every single day so it’s vitally important to do so. Too bad it’s not being opened and studied with enough consistent rigor.

        My 2 cents…

      • A few thoughts:
        Francis is onto something here. Without concrete definitions of what wigets are for us we are all left in the dark.
        In regards to the workflow from a creative writer’s perspective: I’ve been wrestling with the idea of streamlining my work to emulate the ideas of batching. First random thoughts in a notebook. Next the outline, the rough draft, the structur draft where I make sure the arcs of the story are clear, then the chapter by chapter, and finally the line by line. Then it gets back from an editor and goes through more. This doesn’t sound novel but the culture of writing is still filled more with myth and image rather than the dedication to wearing the hardhat and hammering the craft. I started organizing my writing time like this with the thought of the assembly line.
        Now how this works with widgets, well I’m not so sure. For me focusing on the processes from 1000 feet up allows me to sit down and make the decisions of how to tackle the work down to a daily level.

        Last thought. Everytime you slam social or communication programs everyone comes out to talk about it. Most take the stance that it’s good and bad. Others find ways to justify it and tell you your wrong. I say that bravo for going out on a limb all the time. Fight the power. There are a lot of people who are now recognizing how unintentional distractions are ruining their work thanks to your efforts. I know you articulated it for me.

        • For creative writing, I think the main problem is that people assume that writing by ~inspiration~ is the most authentic way of doing it. I think that creative writers’ processes differ, and everyone should work on refining their processes as works best for them. My outlining process tends to be in the foggy middle between “write it and see what happens” and “plan everything.” In terms of workflow engineering, what’s helped me the most is writing on paper and typing during the editing process. It’s very helpful not to have the distraction of the internet staring at me all the time.

  7. 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.

    • I was wondering the same thing. Ever since reading SGTCIY and Deep Work I’ve started to think my multi-monitor workstation is actually distracting and causes unnecessary context switching. I’m practicing using a single monitor to see if that make a difference.

      • I think it depends on what you do with the extra monitor.

        I’m a programmer and I use two monitors. I have my editor open on my main monitor, and on my secondary monitor I will either have some reference document related to the data or code I have to work, or the program’s main GUI (I work with a scripting language — Matlab — so I can try out ideas in real time while I code). Or file browser windows so I can find code or data more quickly. What I never have on either monitor is anything that makes noise, flashes, or changes color. There is nothing to draw my attention from what I’m working on.

        I think that, given this constraint, having the second monitor is extremely useful when I need it, and it just sits there if I don’t. Though I can usually find some use for it.

    • Taylor helped kick off the scientific management movement in the industrial sector, but as it picked up speed, it soon moved past his relatively simplistic notions (many of which didn’t pan out) to more complicated notions.

  8. I saw lots of talk of effectiveness, not much talk of efficiency (or did I miss it?).

    Effectiveness at any cost is not sustainable. Also, effectiveness can be “engineered in” more easily than efficiency in my experience; efficiency is very hard to “bolt on” or “engineer in” to an existing process.

    Just a thought.

  9. Cal,
    Great post. I think it’s cutting to the heart of the opportunity set for the new knowledge worker. I.e, how can a knowledge worker optimize her environment, surroundings, inputs, task activities and deliverables to produce the highest value.
    I agree with your point that worker satisfaction may indeed be the key catalyst to realize the step change gains in productivity and (more importantly) effectiveness.

  10. Any company that claims to be global needs to have a global infrastructure, not piecemeal at each individual location. Not only does this reduce overall costs of having multiple different applications doing the same tasks, but reduces the complexity and overall maintenance costs of multiple independent networks.


Leave a Comment