Today I’m leading a session for Lead Dev Together on what makes a good process. LeadDev Together is a seven-part virtual event series featuring talks and panels from engineering leaders on topics like building motivation, increasing alignment, leading big projects, and building inclusive companies. Each session gives you and your team the opportunity to discuss what you’ve learned in a structured manner, using prompts, exercises, and discussion questions provided by speakers.
I am fortunate to get to kick-off the third part of the series on defining, refining, and aligning processes. I get to ask “What makes a good process?” and dive into three aspects of a good process that I’ve identified.
There’s still time to get a ticket to Lead Dev Together, which gives you access to all of the content, including a recording of my talk and my discussion questions. Today on the blog I’m sharing some new writing on process, inspired by that question: what makes a good process? Hope you enjoy it!
—
“I hate process.”
Have you ever heard anyone say that? I have. It’s a little surprising every time I hear it, because it’s so broad and vague. It’s kind of like saying “I hate books”. Or “I hate music.” Okay… but what kind? And in what context? Can you give me any more detail?
In my experience, people who say they hate process have worked in toxic environments where “process” emerged from a host of dysfunctions. They’ve worked on teams where slow, inflexible, and bloated processes festered in disorganization and bad leadership. On unhealthy teams, processes are scapegoated as the problem, when in reality process is undermined by other big issues, like micromanagement, pervasive fear and threat, poor communication, bullying, failure that leads to blame, poor inter-team dynamics, low alignment, and favoritism, among others. Ugly stuff.
So when I hear someone say “I hate process”, I get curious. Do they really hate the process itself? It’s possible, especially if the process was created without their input or buy-in and couldn’t be changed or challenged. I get it: I’d wither too.
But more often than not, they don’t hate the process: they just hate the way it’s been applied on teams they’ve been part of. They hate not having a say. They really hate what they’ve seen as waste: wasted time, communication, and cycles. Process is just an easy thing to blame: “if only our process had been better.” But this misses the point. Healthy processes rarely emerge from toxic environments.
The “by and buy”
The good news is, it doesn’t have to be this way. You can create processes that aren’t bloated, bureaucratic, inflexible, and full of waste. You can create, maintain, and modify processes that have buy-in and work for your team. You do this by asking the people closest to the work what’s working for them and where they need change.
I call it “the by and buy”: the process is created by the people who use it, and as a result, it has built-in buy-in. The first aspect of a good process is that it is created for and by the people who use it.
the Sharp End
Here I want to introduce an analogy from practitioners of resilience and safety in complex systems. In their book “Behind Human Error”, authors David D. Woods, Sidney Dekker, Richard Cook, Leila Johannesen, and Nadine Sarter identify groups of people called “the sharp end” and “the blunt end”.
At the sharp end, practitioners, such as pilots, spacecraft controllers, and, in medicine, as nurses, physicians, technicians, pharmacists, directly interact with the hazardous process. At the blunt end of the system regulators, administrators, economic policy makers, and technology suppliers control the resources, constraints, and multiple incentives and demands that sharp-end practitioners must integrate and balance.
At the sharp end, we have the practitioners: those closest to the work, doing the work. At the blunt end, we have the folks who dictate resources and constraints. When you see “sharp end”, think of the developers, designers, and DevOps engineers on your team: the people closest to the work, doing the work. When you see “blunt end” think of the managers, VPs, and executives: the folks who have historically been able to exert out-sized influence on products and processes, without feeling the direct pain of implementation.
And yet, the sharp end do so much more than just follow rules and processes.
(They) resolve conflicts, anticipate hazards, accommodate variation and change, cope with surprise, work around obstacles, close gaps between plans and real situations, detect and recover from miscommunications and misassessments.
Even when that’s not necessarily part of their job description.
Our folks on the sharp end, then, are the best equipped to tell us what is and isn’t working in our process and suggest changes and improvements. It’s likely that they’re already working around certain processes (or lack thereof) in order to get their work done. Inviting them to be co-creators of process with us just makes good sense.
Let’s partner with our “sharp end” to create processes that have buy-in and really work for all of us. The question for those of us on the “blunt end”: will we willingly cede our “power”, accept influence, and listen? We will put our ears to the ground, provide institutional support, and change as a result?
The word “change” is a good transition to the second aspect of a good process.
A good process is changeable.
As engineers, we understand the importance of building “change tolerance” into our software. Fundamentally, we understand and expect software to change.
In an article on Design, Jim Shore, author of The Art of Agile Development, defines high-quality software architecture this way:
“A good software design minimizes the time required to create, modify, and maintain the software while achieving acceptable run-time performance.”
And in their book Implementing Lean Software Development — a book about process – Mary and Tom Poppendieck say it well:
“Almost everything we know about good software architecture has to do with making software easy to change.”
Let’s apply the same principle to our processes. Like software, let’s expect them to change. Like input from our users, we’ll receive feedback from our teams and organization about what is and isn’t working. For our processes to have continued buy-in, they must reflect the changing reality of our teams and goals. As our teams grow and change, we must examine our processes and be willing to change them.
A good process is documented.
Software and processes both create artifacts of our work together. One artifact of software is code. One artifact of process is documentation. We can build in both change tolerance and inclusion by taking the time to document our processes.
Documenting our processes means writing down how we want to work together in the interest of consistency, transparency, and visibility. We don’t have to write long and overly formal documents. And we certainly don’t need to nail them to the door. Let’s instead create useful guiding artifacts that reflect our goals and values that we can look at when it’s time to reflect and change.
Taking the time to write these artifacts helps us, but the impact is felt beyond our team. This is because documenting the way we work together makes our work more accessible to folks outside of our team. Documenting our processes means taking the time to write playbooks, onboarding guides, tutorials, and SLAs. It means making it clear how to contribute to our work, what steps to take, how to file an issue, and where to go to get help. When we do these things, we write documentation. And when we write docs, we make it easier for others to join us.
These things do take time, but the investment yields big gains in our alignment as a team and org.
A good process has reflection and evaluation built in.
Our willingness to put in the work to create healthy, useful processes leads into the third aspect of a good process: our willingness to reflect and evaluation. Before change, comes thoughtful reflection. Here I think of the analogy of a code review or Pull Request.
When someone requests our review in Github, we don’t just open it and immediately click “Request Changes”. Nor do we rubber stamp it with LGTM. Instead, we take the time to read the PR, try it out in a test environment, and leave comments. We do this because while it might seem quicker to skip the work, we’ll have a higher rate of error and misalignment, which causes us to move slower.
Our processes deserve the same kind of thoughtful review. Because they are created for and by the people who use them, and reflect the changing reality of our teams and goals, we must be willing to build in time to reflect on our processes and consider how they are and aren’t working for us.
Talk one-on-one and talk as a team, too. You can use part of a 1:1 to discuss with your manager if a particular process is causing you pain. You can use sprint retrospectives or incident reviews to discuss how certain processes were part of the problem or solution. I also recommend that managers schedule time quarterly to meet and discuss larger team processes as a group.
On process… and writing this doc
In closing, I want to share a little story from the process of writing this doc. I wrote it as I’ve written many others: in a Google doc. I titled the doc “On Process” and the date, which made me laugh… because about ten years ago when I was writing my Master’s thesis I created a Google doc with basically the same name, but in a very different context. My Master’s thesis was on process philosophy, and in the context of the seminary where I earned my degree, on process theology.
Process philosophy is based on the premise that reality itself is dynamic: that we experience our world and ourselves as continuously changing. Process points to the “processive” nature of Being or Existence, or how we are always changing and growing. In process philosophy, process is not a dirty word, nor is it something to fear or minimize. Instead, process is something to embrace, because it is our reality.
It’s not worth it to fight reality and the inevitability of change. When I create and evaluate processes, I’d rather embrace my lived experience. So I remember that all processes are above all by and for the people who use them: created by us to support us. It’s why I work to ensure processes are easily changeable–which coheres with reality itself, not to mention the principles of good software architecture. And finally, it’s why I build reflection and evaluation into the processes I manage, so that we are routinely and intentionally asking if the process still serves us. Things change, after all.
I went to a liberal arts school and a seminary, where they prided themselves on teaching us how to think, not what to think. If we cultivate these four healthy attitudes about process, we’ll avoid dogmatism and dysfunction and create supporting structures that make sense. In doing so, we’ll create a process that not only works for our teams, but in a deeply philosophical and metaphysical way, coheres with (one view) of reality itself. And how cool is that?
Thanks for reading.
Special thanks to my friend Matt Davis, known on Twitter as @dtauvdiodr, for introducing me via his work in the resilience community to David Woods’ concept of Sharp End / Blunt End.
Leading with Spoons 