All Endeavor Creates Process

Doing is doing.

When creative professionals complain about “process” (and oh how we complain), what we are generally objecting to is actually process management. Some of these complaints are justified! But we also need to understand why process management is necessary — and ultimately good for us.

This is an entry in my ongoing, irregular series on process management. Before I get into more meaty topics, I really feel the need to rant a little.

Time and again I’ve heard the cries from the team: “I don’t need a ‘process,’ I just do it!” “Stop adding ‘process’ to my work!” or, “This team is too focused on process; it’s diluting the actual work!”

Full disclosure: I am 100% as guilty as anyone of lodging these complaints (everything above is something I personally have said at some point over the years). 

I have sometimes fought process management even when it would literally make my own life easier. I have wrenched up the works of other people implementing it. I’ve even straight-up lied and just invented data to satisfy reporting requirements or analytics.

However! I am also a staunch, steadfast advocate of good process management. Honest.

Everything is a process. 

When we do anything, we follow, modify, or create (or maybe all three) at least one process (and maybe many). “Process” is in fact, quite literally, just a systematic series of actions directed to some end.¹

Just because we haven’t rigorously discussed, vetted, and documented that process doesn’t mean it doesn’t exist. 

For crying out loud, it’s not being done “without a process.” The doing is the process!

And look, here’s a stark reality that we all eventually have to accept: the chances are very, very low that we just happened to discover the most optimal process to do whatever we’re doing. 

Refining, optimizing, and documenting process is the practice of process management, and doing it well is fundamental to the success of any professional creative team. It’s not a matter of “adding process” to the work. It’s a matter of, well… refining, optimizing, and documenting.

For sure, some process management regimes are legitimately terrible; the complaints aren’t necessarily unwarranted.

Onerous, obtuse, not-fit-for-purpose instruments sometimes get plopped indiscriminately onto a creative team from some other discipline (say, sales, or finance, or engineering). In the name of “consistency” or “uniformity” a larger organization will sometimes shove a one-size-(doesn’t)-fit-all solution down the throats of all of its various teams.

On any given team, these systems will track irrelevant metrics, miss important opportunities, and fail to reveal problems, even while adding friction, destroying flow-states, and building absurd incentive structures. Happens. All. The. Time. 

But that it sometimes isn’t done right doesn’t mean it can’t be done right.

In fact, I’d go so far as to say a creative team without any process management is 100% guaranteed to fail (and be miserable doing it). Bad process management will certainly keep a team from performing at its full potential, but none is a non-starter.

A lightweight, intuitive, fit-for-purpose process management regime is possible! And highly desirable! It’s not easy, and won’t happen by itself, but everybody realizes the importance and is ready to get onboard, right? Right?

Now, I could probably write 50k words just on this subject…but I’ll spare us all. I’ll return to it many times, I’m sure. Here I want to look at just two aspects of this challenge. I’ll call them The Peril of Expertise™ and Schrödinger's Optimization™.

Let’s talk about expertise — and experts — for a moment. Our teams are filled with them, after all.

Experts are good at what they do. They are not necessarily good at describing what they do. When asked to document their process, they’re pretty likely to say something like, “it’ll be faster if I just do the work.” 

Well, yeah. That is almost certainly true! An expert at a task can, with virtual certainty, complete that task more quickly than they can write up comprehensive documentation on the process they use to do it. 

That is, pretty literally, the very definition of expertise. It also totally misses the point. It’s The Peril of Expertise™.²

There are any number of reasons we might want to document processes. Maybe we need to distribute them to increase scope. Maybe we want to reduce risk. But for sure we want to be able to optimize them. And that requires knowing what they are.

Of course, when asked to create documentation, we might just lie. I don’t mean this maliciously. It’s just that we’ll document some idealized version of the process, skipping over all those weird little shortcuts, half-measures, almost shamanistic steps, the organizational knowledge that’s virtually intuition at this point — we’ll neglect to mention the terrifying dead ends that now seem “obvious” to us, and the fail-states that we have forgotten are there (after burning our fingerprints off one too many times). We’re experts!

It turns out we all muscle-memory our way through innumerable ridiculous inefficiencies and at some point become completely blind to them. We probably couldn’t accurately document all the steps if we tried.

There’s a better way. It’s an old saw (really old: first-century Roman philosopher Seneca said it), but valuable: “by teaching, we learn.” One of the most effective ways I’ve found to uncover opportunities for optimization is to have an expert teach their process to someone else. 

Stepping through a process — for real — for the first time is like throwing on the lights in a dark room.

I recently saw some random online meme that said: “The only difficult thing about training new staff is trying to remember the correct procedures and not the things I’ve made up along the way.” Right?

Still, I don’t want to overstate the efficacy here. Let’s be clear: it is true that sometimes someone on the team will have such very specific knowledge or expertise that it simply doesn’t make sense for them to try and teach it to another.

I’ve seen this with folks, for instance, who have coding experience talking to folks who don’t. If the work requires the kind of knowledge and expertise you’d get from a degree in computer science, you’re probably not going to teach it to somebody else in an afternoon. 

But you can still document it, and it can be subject to optimization! Don’t let them convince you otherwise! It just might take a different approach.

To be successful we’ve all got to “work on the business” in addition to “working in the business.” Done well, the proportion of these two are balanced in a sustainable, efficient way for everyone.

Okay, so we’ve convinced our delicate geniuses to adopt some process management measures (or tricked them into it, whatever). Now how do we avoid just proving their initial reticence right? How do we not gum up the works?

I don’t know anything at all about quantum mechanics. Naturally, therefore, I will carelessly deploy it as a metaphor just like everyone else does — ignorance is bliss! Anyway, there’s a notion, famous from the Schrödinger's Cat thought experiment, that observing the state of a thing changes the state of that thing.³ 

I understand nothing of the science of this. But I love the poetry of it! And look how applicable it is to professional creative process management (as long as we ignore everything about its literal meaning). Schrödinger's Optimization™!

Often, an early stage of process optimization is to implement mechanisms to try and get a little visibility into the process — to better understand velocity, find bottlenecks, or raise early-warning flags. We want to be able to observe the process…but changing-by-observing becomes a real risk. 

Wander with me on a little mind-journey, will you, while I propose a completely absurd example to demonstrate my point.

Let’s say that to create some asset I have to click a mouse three times. A new process management regime is suddenly implemented, requiring that I document every mouse click. So now, I have to click the mouse, then type a sentence, then click the mouse, then type a sentence, then click the mouse, then type a sentence. 

Yes, an absurd example. Or is it?⁴ 

In this example, the attempt at management has not only added to the process, it’s fundamentally changed it. What was clicking is now clicking and typing — and having to think up what to type! What once was a flow with a single modality is now a flow with three (clicking -> thinking of language -> typing -> clicking -> etc.), including all the context-switching costs that incurs. 

What we wanted was visibility into the process — to be able to observe it. What we got was a changed (and changed for the much worse) process.

The immediate instinct would be to rail against the project manager who implemented this regime. What were they thinking? 

But before we do that, let’s try an exercise in empathy. And this will be some necessary catharsis for me — so please join me as we go, Inception-esque, even deeper into this (totally made up, honest) scenario. 

Imagine that this onerous new process management system had been introduced by a project manager new to the team. This person had just come over from a different team — one whose job was to write 3-5 page essays as their usual work-product.

It was a large team and some people had been duplicating work. There was far too much total content for the PM⁵ to be able to keep up with it meaningfully, so they instituted a new measure: every doc needed an accompanying single sentence description to go with it. 

This was imperfect, but it gave the PM just that little bit of insight into the work being done, allowing them to effectively diagnose the problems, figure out the duplication, and streamline the process. It wasn’t particularly onerous since the authors were already writing and typing in the tool, and adding a single sentence to 3-5 pages was less than 1% of the total work for each piece.⁶

It was an example of process management that added a minimal amount of friction to the process — but was still pretty darn lightweight in terms of flow — and returned well on the investment. The observation of the process didn’t fundamentally change the process. 

It might be reasonable for the PM to feel a little confirmation bias about that and then, upon transferring to this new team, feel justified in trying to replicate it. I’m not suggesting it was therefore a good thing that they just wholesale dumped Team X’s process management regime onto Team Y, I’m only suggesting that it’s understandable how it happened.

But then! Imagine that with enough pushback, eventually the PM relented. Now with a better understanding of the needs of the team, they took a new tack. They commissioned a small addition to the tool that allowed the creators to simply click from a pre-made list when they completed their current process. This selection was less informative than the sentence writing, but vastly more efficient for the creators (it added simply a fourth click and a very small cognitive load).

Now the original process could be observed meaningfully without materially changing it. And the PM got the info they needed to propose some optimizations. Probably should have started there, but ending up with the right answer is a win.

Good process management systems are never one-size solutions. Assuming work is underway (which it always is!), the system must understand the current process, in a fairly fundamental way, and attempt to observe it without changing it.

Cards on the table, I’m pretty enamored of notions of “continuous improvement.”⁷ I have a deep suspicion of any process that has stayed exactly the same for any appreciable length of time. Is it possible that it’s just fully optimized? Sure! Do I think that’s likely? Dear reader, I do not.

Continuous improvement requires understanding both where you are as well as where you want to go. If I ask Google Maps to get me to midtown Manhattan, it’s probably going to give me different directions if I start in Des Moines than if I start in Tribeca.

But even in the case of a process that is already highly optimized, know that it won’t stay that way. The specifics of the work will change, tools will grow and adapt, new technologies will be introduced, new team members with slightly different experiences will onboard.

If you’ve got a well-oiled process going, take the win! And then keep improving.

Process management is not free. It can’t be! It will cost some specific efficiencies no matter what we do.

The goal is to find the value in the tradeoff. It should be an investment, rather than an expenditure. A small disruption in flow-state here for a massive de-duplication of work there. Data collection here to prove the case for more resources there. The addition of a couple of steps now to save excessive re-work later. 

The dirty little not-so-secret of professional creative work is that it’s…professional. There’s business involved! Efficiency, metrics, analysis, optimization — these are critical even in the most generous conception of a “creative environment.” 

Capitalism gonna capitalism. Does that wreck everything? Yeah, kinda. But here we are. Let’s make the best of it.

1. I know, I know. The old, “Webster’s defines ‘process’ as…” approach to argument is pretty weak. But the word just gets used incorrectly so damn much! Words mean things!

2. The Peril of Expertise™ is a totally different concept than The Curse of Knowledge. Says me.

3. No, that’s not exactly what it means. Don’t look this up. It doesn’t matter. At this point I’m referencing pop-culture versions of a thought experiment that itself was originally meant as an absurdist critique of a scientific notion…whatever. Go with me here.

4. Yes, of course it is, but sometimes this stuff gets pretty absurd in practice.

5. Here, PM = project manager. Not everybody uses that kind of abbreviation, but damned if I’m typing “project manager” every time.

6. Yes, there is a cognitive-load cost even here — but even good process management isn’t free.

7. This is true even given my skepticism of business practices that get a name like this and then have seminars and consultants and so forth surrounding them.