Many years ago, the word/phrase to be found around the workplace was “workflow.” Between the many folks selling workflow solutions, large companies making initiatives on top of initiatives in order to improve/measure/etc. workflow, and the various technical languages which jumped the shark into being “workflow enablers” for those who needed a bit more agency, it was a another one of those fervor moments you could only just sit and wait it out. And yet, so much about the idea of understanding workflows isn’t just key to understanding how businesses will be done but also understanding how things are done.

For example, take the process by which teams from different companies come together to craft a proposal. The structure of the group dictates who will be the gatekeepers, even though the role of every member is to contribute some kind of content for the proposal. From the developers and designers who might be tasked to envision a concept for the eventual state of the product, to the resource and financial analysts who need to know the value of inputs, outputs, and their impacts across a very fluid timeline, there’s a great deal to pull together. Thinking about this within the concept of a seamless workflow you ask questions such as:

  • where will draft versions of documents be kept
  • who will be responsible for auditing the output versus the proposal template
  • what happens to the resources which become the conceptual product
  • is there a round of feedback/editing which needs to happen with a smaller piece of the team before this is considered final
  • what will be the primary communication methods

In each case, through each role and team contributing to this project, the idea of workflow isn’t just a matter of “what kind of work needs to happen between them for the end product,” but also, what kind of work needs to happen within those individual members in order to flow up to that project team’s output in the most seamless manner. Differences in applications might lead to reduced fidelity from one team to another. Differences in availability might lead to passive/indirect communication journals which fail to convey some necessary tone.

This makes workflow less a religion and more a sacrament. It is a descriptor of what should probably already be happening. Yet, when codified, creates the accessible means for those outside of the team or process to best understand why success happened or didn’t. Challenge for many folks is that they don’t know what that structure looks like. Their work is dependent on another, but they don’t know what questions to ask in order to see what’s on the other side of the fence or garage door. And then when things are created, and you just see the output, you don’t realize the depth of work which went into this. It seemed seamless due to the time and quality met, but there’s a depth to which only the workflow (as codified) would be able to explain.

Not to say that documentation is everything. But, when there’s some kind of workflow involved, there has to be a record of the process. That is, if your process is actually contributing to the positive outcomes for the projects you are setting before yourselves.