The Null Process (2015)
kateheddleston.com
kateheddleston.com
----
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.
- 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.
>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've been places where excess process is a crutch for poor general technical expertise and troubleshooting skills.
Especially if the customer knows they are paying for our inability to figure out what the hell we are doing.
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.
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.
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.
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.
P.S. the lawsuit was rejected: http://svelf.com/class-certification-defeated-in-twitter-gen... so maybe not the perfect example in hindsight :)
Whenever someone talks of "common sense", they're invoking the null process. It also reminds me of the "ask vs guess" culture issue.
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.
Except that his talk is, on the contrary, about how preferrable it can be in some contexts not to have a hierarchy enforcing processes.