Work execution vs. workflowKnowledge work is the combination of work execution and workflow. Execution usually gets the attention in IT.
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.
How do you keep Devs, QAs and Testers constantly busy?
I understand where this question comes from. But it's the wrong question.
Why do devs want more devs?
Almost always, more team mates means slower output, not faster. So what's the proper solution?