I read Seth Godin's blog regularly. It doesn't always resonate with me, but I really enjoyed his post called Understanding Stuck. Partly because every time we fly my husband comments sarcastically about how lucky it was that they explained how seat belts work. But mostly because I have worked in organization that got stuck.
Many of us in the organization tried to make changes to get us unstuck, but typically we were told "No, you can't change that. This is how we do it here.", when we tried to fix a broken process or tool. The ironic part for me was that I had established a number of these processes. Now, years later I was being stopped from making necessary changes. There seemed to be some mysticism about how we worked; as though the processes had been handed to us, fully developed, from on high. It was frustrating. We did get things changed but it took an extraordinary effort. We definitely could have used a clean slate. I wonder if we would have had the courage to take that step?
If your organization is stuck, I would give the clean slate prescription a try.
I am curious if you think that there are things you could have done when creating these processes in the first place that could have avoided or mitigated the eventual entrenchment.
ReplyDeleteIt seems like there are likely cultural aspects to this, but can process and policy be created that repels the mysticism? Or is a cycle of entrenchment and unwedging/obliterating inevitable?
I think it is possible to have process and policy that repels the mysticism. The key, in my opinion, is to have it as a living process. That is what I stated when I did set up the process (the one that eventually I was not allowed to touch). But I didn't put anything into the process other than a very simply post project review that allowed people to critique it and there was only an unstated rule that you would update it. If the culture had been set that the process was reviewed and updated regularly, even completely replaced if need be, I think it would have worked much better.
DeleteSo when people started to feel sluggish, we would have adjusted, and we would not have gotten ourselves stuck.
The other thing that I think would have helped was to have more information about the problem the process was solving. It came clear to me that people were hanging on to parts of the process for all the wrong reasons (or at least not reasons that I agreed with). I think the process became the end goal for many - process for the sake of process. I (we) should worked with the engineering team to ensure that we all knew the business goals, and how the process was intended to support those goals. Once a process was no longer meeting its intended goal or if the business goals changed then it would have been more natural to look at modifying the process.
The final piece of the puzzle was eliminating the need to have complete consensus before making a process change. We should have encouraged teams to try out new approaches, even if they weren't complete, and adjust as needed. Getting any changes accepted was very difficult. That, however, was a bigger cultural issue within the engineering team not simply limited to change in process ... perhaps a topic for another post?
I would certainly read that. I am particularly interested in what you think the role of trust is in a dynamic organization. And the related question: can trust scale?
DeleteThis article is a couple of months old now, so you might have seen it already, but I thought that it was worthwhile to link Why Companies Fail, about culturally stuck companies, and when (and if) they can turn around.
ReplyDeleteIn the case of my personal "stuck company", I found it interesting to think about the factors that encouraged the sort of potentially crippling stability she discusses: "Change is risky, after all, since it definitionally involves doing something that isn’t already working—and even product lines that have grown lackluster still have some customers." Certainly some level of rigidity is a practical choice, but that engenders a cultural rigidity that can bleed into all sorts of domains that abhor rigidity.
Interesting article Eric. Thanks for sharing.
Delete