At one point in my career, I joined a company with a lot of process in place. There were document templates for any kind of proposal you could create and spreadsheets to track progress all activities. Hiring, onboarding, strategic planning, project planning, software acceptance, sprint reviews, you name it. All covered by processes. In case you wanted to push for something new, there was even a guide for making a “plan for a plan.”
As a newcomer, the amount of process didn’t strike me as extreme. Yes, it was on the high end, but I didn’t see it as problematic. However, as I got to know the teams and the engineers, I heard a consistent refrain that it made them feel disempowered. In some cases, they wanted to “just start making progress” but felt that they had to jump through documentation hoops and spend too much time preparing to start. In others, they had an idea for a better approach to planning but believed they had to follow what already existed.
The big surprise was that the executive who created most of the process thought he was doing it to increase autonomy and empowerment. Process falls on a spectrum between “must follow” decrees and “may come in handy” tools in the toolkit, and there was a fundamental mismatch on expectations between executives and the boots on the ground.
In this article, I’d like to discuss why the process was created, what went wrong, and how to design more empowering processes in your organization.
In defense of process
Before discussing pitfalls, it’s important to say that “process” is not a dirty word. In the pursuit of a generative culture, for example, some process is necessary to ride the fine line between autonomy and alignment.
Some good reasons for implementing “must follow” processes are:
- You need to follow the highest standards for equity and fairness. Hiring decisions and performance/compensation reviews are the two most common examples of this. Structured interviews and performance assessments are critical and need to be followed the same way by all parties. Otherwise, biases can creep in.
- Someone is embarking on a stretch responsibility that is new to them. There are many models of skill acquisition, but I find the Shu-Ha-Ri¹ model to be concise and helpful here. In the first stage of gaining knowledge (Shu), learners benefit from following practices precisely, putting theory and invention on hold until they’ve experienced a few repetitions. Rigid processes are especially helpful here when it’s important for the new responsibility to yield the right outcome the first time.
Beyond these cases, I believe that it’s best for leadership to provide frameworks and process options that are less rigid, then allow autonomy within and around them. For the rest of this article, I’ll refer to processes on the less-rigid side of the spectrum as “toolkits.”
The origins of mismatched process expectations
Let’s return to my example from a prior employer. to recap, I had found that the expectations for process rigidity were not aligned across the department. Leadership and the engineers were not speaking the same language. After getting to know the organization, it became clear that the process had been invented when everything was a stretch responsibility, but that expectations had not shifted as the team matured.
The department head had originally been hired to bring the engineering team from a point of disorder to a point of alignment, and many of the team members did not have experience with core parts of the job. Gaps included product partnership, project planning, and technical vision. During this phase of stretch responsibilities, creating clear and rigid processes had huge value.
The intervention worked and the team matured, and everyone could see it. The department head could properly identify the team’s maturity, had a good vision for their future growth, and knew that they needed to move on to autonomy and innovation next. However, the team was used to more rigid process expectations, and continued to think that rigidity was expected of them. The gap holding the team back was in proactive communication over time.
Inconsistent, overly complex, or sporadic communication is at the root of many leadership issues (perhaps most of them?). It is especially problematic when setting process expectations because: (a) having rigid processes for too long makes you feel micromanaged and demotivated; and (b) too much rigid process pushes you towards a bureaucratic culture rather than a generative one.
My advice to department leaders and managers is to regularly communicate two things:
- Whenever a toolkit is provided, explain why it is a valuable tool, but also be clear that it can be used, remixed, or ignored as individuals see fit.
- Whenever a rigid process is provided, explain why it needs to be rigid, hopefully for one of the two reasons above. Then be clear that the rigidity is a special case.
Why should toolkits be the default?
Yes, toolkits increase autonomy, decrease feelings of micromanagement, and move you closer to a generative culture. However, they also primarily exist to decrease extraneous cognitive load. In contrast, rigid processes tend to decrease all types of cognitive load, even the germane type where creativity can emerge.
The fields of instructional design and pedagogy have identified three types of cognitive load that exist while performing tasks.² They are:
- Intrinsic cognitive load. This is an inherent level of difficulty or base knowledge that you can’t get around. When programming, knowing how to use a keyboard, being familiar with your programming language, and understanding the difference between memory and disk are all examples of intrinsic load.
- Extraneous cognitive load. This is the mental effort involved in following “the way” in which the work needs to be done. What kinds of authorization do you need to begin work? How do you need to get your environment configured before you begin coding? What are expectations around code review and acceptance? How do I convince the rest of my organization that we should go this way? In general, extraneous cognitive load should be minimized by offloading it to processes or toolkits.
- Germane cognitive load. This is the mental effort that makes your task unique, in which you’re creating solutions or coming up with answers that bring real value. This is what our employers pay us for, and this is the only type of effort that can get you into the happy flow state. The more time we have for this, the better.
The Checklist Manifesto by Atul Gawande³ digs deep into this cognitive load distinction. Gawande advocates for checklists (in the fields of aviation, medicine, and others) as a mechanism for reducing extraneous cognitive load. For instance, if surgeons rely on a checklist for basic sanitary procedures, they have fewer things to remember in a crisis, and their brain is more free to identify creative actions that only they can see (and which could save lives). I find that checklists are also useful toolkits for software engineering.
In my experience, it goes a long way if you explain these types of effort to your managers and engineers. That way, when they pick up the tools in your shared toolkit, they can each reflect on the goals and utility of the toolkit themselves, bringing pieces to bear in a way that brings down extraneous load and makes more space for the germane.
Don’t forget: live what you preach
It goes without saying, but I’ll leave you with one final note: even if you’re the best advocate in the world for toolkits, you can undermine it all if you then insist that they be used precisely. You may be really proud of the onboarding checklist that you created for the department, but if a manager takes it and makes some fundamental changes for the context of their team, you can’t be surprised or frustrated by it.
True, their modifications may cause them to miss something important. If that happens, don’t push them back to your original version as the “right” approach. Instead, talk through the miss, talk through the goals, and ask them to use their best judgement to fail forward into their next version. Then, of course, make the improvements available to everyone!
[1] Martin Fowler. ShuHaRi. https://martinfowler.com/bliki/ShuHaRi.html
[2] Wikipedia. Cognitive Load. https://en.wikipedia.org/wiki/Cognitive_load
[3] Atul Gawande. The Checklist Manifesto. https://atulgawande.com/book/the-checklist-manifesto/
Process that Empowers was originally published in Better Programming on Medium, where people are continuing the conversation by highlighting and responding to this story.