Peter Drucker, who died in 2005, is well known (among other things) for identifying “knowledge work” as a distinct, and at the time, somewhat new, way of working, in contrast with other types of typically more physical labor, such as plowing a field, or assembling an automobile.

Since then, a lot of thought has gone into the concept and nuances of knowledge work. And this morning I was reading A World Without Email in which author Cal Newport makes a statement that hit home for me:

Knowledge work is better understood as the combination of two components: work execution and workflow.

The first, he goes on, “describes the act of actually executing the underlying value-producing activities”, such as a programmer coding.

The second “describes how these fundamental activities are identified, assigned, cooridnated, reviewed.”

So if writing turning Jira tickets into for loops and quick sort algorithms is the work execution, then deciding how to prioritize Jira tickets, who does the coding, how to review the work, and how it’s deployed for the benefits of customers are all workflow.

To me, this distinction is one of those “obvious in hindsight” sort of insights. And it’s the latter, the workflow, which I usually focus my professional attention on. And not because I don’t like the work execution—I really enjoy writing code. Rather, I focus on the workflow because I believe it provides much better leverage.

All the best work execution in the world is ultimately wasted without a good workflow.

Is your workflow serving you? If you could use a second brain to help improve, you can borrow mine.