This week a few colleagues and I, software engineers and managers at VMware Tanzu, attended the third installment of LeadDev Together. This deep-dive was about defining, refining, and aligning processes. We heard from several accomplished engineering leaders about their experiences with process. The session was skillfully facilitated by Anjuan Simmons and Pat Kua.

Some things I heard

Adrienne Lowe encouraged us to consider the different perspectives at the dull and sharp ends of a process. Leaders perceive less detail than practitioners do. She reminded us of the inevitability of change, of the drift that occurs between a process's philosophy and reality.

Maria Gutierrez brought us back to first principles. She told us that processes are fundamentally about repeating success and avoiding past mistakes. She cautioned us not to transplant processes without understanding the new context: the team's values, goals, and constraints. Finally, she encouraged us to think big and to then scope it down.

Rachana Kumar and Taofeek Rabiu generously shared anecdotes and experiences from Etsy. They described the broad groups they've organized into, in particular, an elastic Task Force to act as both glue between and shield for the other two Application Engineering and Platform Engineering groups.

The session ended with an insightful panel discussion. Brigitta Boeckler concluded the session by suggesting we consider Jo Freeman's essay The Tyranny of Structurelessness to learn, as she did, about the absence of process and women's liberation.

My perspective

As I listened to these experienced leaders, my mind sifted through on my own experiences with different processes and the ways they affected people.

The majority of my career has been with teams that practiced blends of eXtreme Programming (XP), Lean, and UCD. Each of these processes might have once been celebrated as a David amongst Goliaths. Now, these once-heroes might also be begrudgingly received, themselves reconstrued as pedantic and lumbering giants.

(A formative experience early in my career was being introduced to both agile processes like XP and formal processes like CMMI in the same semester of my master's degree. It turns out contrast is an excellent way to notice details one might otherwise miss.)

I wondered why the same processes, like pair programming, sometimes felt liberating and at other times felt prescriptive, restrictive, and, if I’m honest, occasionally soul-crushing. I've noticed even lightweight processes like checklists calcify & confuse people.

In The Checklist Manifesto, we’re taught that sometimes the intent of a checklist is to centralize power and decision making. These prescriptions create teams that can't adapt. An antidote is to the move decision making to the people using these checklists. Atul Gawande tells us checklists are to make the management of complexity routine. That they are in fact required for success. But he doesn't stop here. He adds "there must always be room for judgment." This advice resonates with my lived experience with processes and much of what I heard earlier today.

For the creation of software, the best processes I've experienced worked because the teams they served had autonomy. They defined and refined their own processes in the face of change. The best processes and tools are for individuals and their interactions. These individuals must create, continuously reshape, and sometimes discard their process and tools to keep them effective, relevant, and humane. It also turns out we learn faster when we aren't told what choices to make.