Something that comes up a lot in my recent reading of job ads is this desire for candidates who “focus on outcomes, rather than processes”. I get it. I have seen plenty of projects bogged down or worse by onerous process. The need for fifteen people to sign off on a typo being fixed, or a ten page memo required in order to secure those additional three days of work.

But it got me thinking about what really makes them “bad”? And why do I believe that many processes are “good”, with some being “essential”?

A question of intention

Let’s start with something simple: how do you make a good coffee?

Perhaps you have opinions about this already. You tell me about your preferred grind settings for the beans, about the perfect temperature to give the right extraction and so on. You’ve spent a lot of time learning this, and you know your coffee is pretty good.

Then I add some context. I have a couple of minutes before I need to leave for a flight.

See, on its own, your process isn’t good or bad. It’s only when we clarify the intention that we can start to evaluate the process. It’s not a bad process, it’s just the wrong one.

At this point, the goal has gone from “make me a great coffee” to “I need a coffee in about two minutes”. That changes everything.

Notice as well that this presents a new challenge. Do you even know how to make a good coffee in about two minutes?

Process is learning manifest

Let’s say you have an Aeropress lying around, and a takeaway cup. You grab those, make a damn tasty coffee, and I’m on my way.

The assumption here is that you not only have access to the tools to achieve the new goal, but that you know how to use them.

Specifically, that you have a process for using them.

This is the real power of a process. It’s a way of transforming learning from an abstract concept into a tool that can be used. And not only used, it can be shared. I could watch your process and replicate it myself. Or perhaps you could text it to me as I sit on the tram sipping my (delicious) coffee.

So processes are really context dependent tools.

Process all the way down

How did you learn this process in the first place? Maybe someone gave you the tool, just like you’re texting it to me as I arrive at the airport. Or maybe you built it yourself, through practice, trial and error, and reflection.

That sounds like a process to me. A process to build processes.

A process to learn.

This learning process enables all other processes. It’s the one process we can’t avoid, but also the one we’re often least aware of. In fact, we often don’t see it as a process at all.

But a process it is, and as such it too can be evaluated against its intended outcomes. How much does our learning process change our future behaviour? How much does it produce new processes that are useful to us in achieving our outcomes and goals?

Does this insight get us any closer to resolving this tension between outcomes and processes? It’s clear that any process is only as good or as bad as its support of intended outcomes, but learning itself is a process which is also open to change and modification as we evaluate its effectiveness.

How does this lens help us refocus those job descriptions?

Starting up

I most often see process skepticism in job postings from startups, or startup-like organisations. Why is that?

By definition, these organisations are seeking to do something new. This means they’re working in uncharted territory, land for which there are no maps, no established ways of doing things. There are no processes, because if there were, would they truly be doing something new? This fear is the first source of process skepticism.

However, this life in uncharted territory means that every day is a school day. Every team member is learning fast, every hour, and so their learning process needs to be razor sharp. They’re building new tools to solve every problem they come across.

The challenge, though, is channeling that learning. If everyone is facing problems, hacking their way through metaphorical undergrowth, learning what works and what doesn’t, that can be hugely inefficient. Each team member must learn the same lessons independently, and some will learn different lessons from the same problems. Some will disappear off into the weeds, following a learning trail that doesn’t support the team’s outcomes.

The result? Chaos. Everyone pulling as fast as they can in the direction they believe is the right one.

The solution? The team needs to define and share its learning process, and check that it actually supports its goals. This could be a daily check in or a weekly gathering. The details don’t matter so long as it is a deliberate practice for surfacing and distributing useful learning.

Many teams at startups follow some form of this. However, it’s often not used as a learning exercise, and so doesn’t change behaviour that much. Even where it does, though, it can still lead the team into trouble, the other source of process skepticism: the dreaded process swamp.

The problem here is that process development is seen as a one way thing. That process that saved their butts in week two is still being followed in week four, despite it now holding them back.

To wade out of the swamp, the learning tool needs to not only be sharp, it needs to be continually applied to all processes. Learning needs to focus not only on what tools need to be adopted, but which are no longer useful given all that has been learned since.

While startup teams often embrace this idea of focusing on outcomes rather than processes, in reality they are among those most in need of both a process for learning, and a process for ensuring their processes still support their outcomes.

Without those, they risk everyone hacking their own paths to chaos, or blindly marching a path that stopped being useful weeks ago. Either way, they just end up lost in the woods.

How do you learn?

So let’s go back to those job postings. What should we make of those who deploy this rhetoric against processes?

My belief is that a general fear of process betrays an incomplete process for learning. If that existed, it would ensure that any process that was no longer useful would be modified or killed in short order.

Again, a process is simply learning that has been turned into a tool, and that as with any tool, it’s when and how it is used that determines its effectiveness at achieving your outcomes. To revisit the “fifteen person sign off” example, the typo it was deployed to approve was in a Key Information Document for a regulated pension investment product.

Does that still seem like a bad process to you? Or one that has an important role to play in keeping the copywriter out of prison?

So yes, a focus on outcomes is essential, but the key question to ask when presented with this dichotomy of outcomes or processes is “what is your process for learning?”

Because without a solid process for learning, the most ambitious outcomes will remain out of reach of even the most capable of teams.