Interesting article. The Null Process seems at least somewhat analogous to the phenomenon described in the essay "The Tyranny of Structureless" [1] (that when people claim there is no hierarchy/structure in a group of people, in truth there is an informal but very powerful hierarchy that's hidden from you and whose rules you are not familiar with). If there are "no processes" in truth there is a process and you don't know its rules because they aren't stated anywhere. Aka the "unspoken expectations" mentioned in TFA.
This is all reminding me of the murmurs from Jeri Ellsworth and friends about the shadow government at Valve.
The lack of transparency means that the subtle people win a rigged game that the more oblivious don't even know is being played. A category in which engineers are substantially over-represented.
We put it out there so that there are more eyes on it, and people are forced to acknowledge their own pain points and learn a bit about themselves and/or teamwork.
I've enjoyed using and explaining this concept ever since I read the article initially, a few years ago. I think it's a powerful idea when applied in the right context. I do want to play devil's advocate though, and point out some "benefits," imo, to "the null process" that are left out from the article:
- The null process does not have a formal process owner, so nobody is directly on the hook for blame when things go wrong with "the process."
- The null process does not shake up or disrupt existing, implicit or explicit, political power structures in place. It's harder to make an enemy by "doing things how we've always done them" rather than fighting to change something.
- The null process allows those in leadership to drastically change strategy at both small and large scales/scopes, without having to actually do formal change management. The new process is whatever randomly settles around the new goals/strategies. As opposed to having to actually tear down or carefully alter existing, formalized processes.
- The null process is usually poorly understood by any one individual, it's made up of haphazard, ad-hoc communication channels and specific rituals between individuals or teams. This disperses power and disallows any one person or small group from gaining undue influence over the whole by controlling some key cog or relationship in a formalized process.
- The null process can somewhat shield creatives and strategists from being overwhelmed by stick-in-the-mud, by-the-book people who may use formalized process as a cudgel to beat people over the head with in order to show dominance or gain power.
> so nobody is directly on the hook for blame when things go wrong
Usually the poor guy who broke the unspoken rules is to blame, and worse yet, it looks like he's to blame out of the blue. Things went wrong, his colleagues are unhappy, and the reasons for that are vague.
> The null process does not shake up or disrupt existing, implicit or explicit, political power structures in place.
In part, it is those structures, the unspoken implicit expectations. Messing with them is much like messing with explicit power structures, only blindfolded.
> This disperses power and disallows any one person or small group from gaining undue influence over the whole by controlling some key cog
Rather, the people informally "in the know" do gain the undue influence, but do so informally. You just have to talk to them via these haphazard channels (and know to talk to them in the first place), or certain things fail to work well. This also lowers the bus factor of the organization, without formally acknowledging it.
OTOH I tend to agree with the other two points: that informal "null" processes are easier to dismantle and replace with a more formal process of a very different kind, and that the lack of formal process allows some needed creativity, informal "skunk works" to sneak in where (other) formal processes do not allow for that.
>> so nobody is directly on the hook for blame when things go wrong
>Usually the poor guy who broke the unspoken rules is to blame
Sure. I could have phrased my point better as, "Even if someone is blamed, nobody in leadership will be blamed for 'bad process' decisions."
>the people informally "in the know" do gain the undue influence
I could argue that this is a feature and not a bug. The inefficiency of the null process means that the "informally in the know" group will need to be much larger, on average, than the feasible power groups in efficient organizations. A group composed of 25% of the employees would probably be less likely to end up making radical decisions than a group of <4% of the employees.
>This also lowers the bus factor of the organization
By the same measure, having a larger power group and the null process would seem to me to greatly increase the bus factor. There would be more people each specifically focused on smaller areas, and/or possibly also overlapping in knowledge due to inefficiencies/redundancies in the null process.
I have been trying for ages to articulate 'what happened to Agile' and recently had what I felt was a minor breakthrough.
Part of our problem is conflating practices with processes.
Scrum is all process, but few of them. XP has fewer processes than Scrum, but way more practices. Practices, by the way, that I've heard asserted more than once are the difference between a successful or a failed Scrum team - that successful Scrum teams are using half of XP. In other words, Scrum is simply underreporting the number and variety of success factors, making it look much simpler than it really is.
Almost all of the process in Scrum is performative. It's social. It's the parts that we have always struggled with, and that's precisely why the business folks 'ruined' Scrum so easily. XP is overwhelmingly practices of craftsmanship, a concept which some of the best of us enthusiastically embrace, and which remain opaque to people focused exclusively on emotional intelligence. The worst among us don't like the focus on self improvement. They'd rather talk their way out of it, and you can do quite a bit of talking in Scrum.
Sure, but that seems to be the default position of engineers. Do we need blog post telling engineers what they probably already believe?
I think posts like this are useful because many engineers like to push ideas to their pure form, and for some things a balance is what's best. I think process is one of those cases.
This reminded me a message from the book "kids are worth it!" by Barbara Coloroso. In it she describes three forms of parenting. The first is brick wall parenting -- essentially conform to my will or else. Brick wall parents tend to raise children who go on to be brick wall parents or jellyfish parents.
Jellyfish parents provide little to no structure to their own children and essentially turn them free-range.
She also talks about a middle ground between which she calls the backbone parent. Parents who provide structure but to not enforce their will on their own children.
In the case of processes, they shouldn't be mandates from management. Instead, they should be results of the workers deciding what is best for the time being. If the needs change and old processes are no longer useful, the workers should be enabled to change them. I have yet to work in an organization that is setup this way. They either have 'Null Process' or they have rigid corporate processes that control workers vs enable them.
Some people loves a structured world with clearly stated rules. This has many benefits especially when the situation is very well defined, repeatable and requires many people to cooperate. The down side is that rules will almost never accommodate all possible situations.
So when a problem is very dynamic and requires few people to cooperate it might be beneficial not to try and force strict rules on uncertain conditions.
And yes some people are not as good in picking up social cues and working with loosely defined rules, and maybe they are not the perfect match for these positions. Its not the end of the world.
Not saying that building processes is bad, just that for some situations it might better not to.
My first and second drafts of process documents are always way too long. It's easy to be verbose. It's hard to be concise.
It's very hard to be concise and to accurately convey the whole process.
One strategy that helps is imagining a tiny flashcard checklist you'd carry around while executing the process.
Another strategy I've seen help in some contexts is tutorial videos -- if you watch someone follow a checklist, you might get to see an obvious implicit part of a step which a novice doesn't know. Watching someone's screen as they actually use a system according to the published steps can be really valuable.
Processes can be instituted democratically, when everybody interested agrees that a process would be beneficial / helpful for their work. I've seen this happen, and I think it's the proper way in most cases.
----
[1] https://www.jofreeman.com/joreen/tyranny.htm