Post-Communism and Organizational Change
11 Jul 2018The class I took in college on Transition Economies was one of my favorites. My professor was a brilliant man with a soporific voice, and I’d scan the room to see heads nodding off, but I found it fascinating. At the turn of the 21st century, “transition economy” generally referred to countries that were adjusting to post-communist life. In those sectors of Europe, things as fundamental as buying a carton of milk or even how to do your job were significantly changing. Entire countries were altering how they did commerce. It was the whole system, too, all the way from how to pay people based on their job or skills, up to creating industries that had previously been government-controlled or simply did not exist. It wasn’t only changing a system, it was shifting a culture, too.
This kind of thing happens in organizations, too. When thinking about adopting a large change such as adopting Agile for an organization, I think of it from the perspective of organizational behavior. There were two extreme ends of the spectrum to making the transition: do it gradually, or do a shock treatment. (Pardon the out of date term; I’m pulling from my out of date textbook.) Each approach came with pros and cons of course, but this is how I look at making changes within Engineering, such as adopting Agile Scrum or SOC2 processes. An organization needs to decide where they land on the spectrum.
1. Gradual Shift
At its most extreme, a gradual shift would be unnoticeable to the folks doing the work. The system would evolve over time to follow certain practices, with workflow changes of minute differences until one day everyone looks around and realizes that they are already executing the Scrum, SOC2, or simply, the New Way and need to announce it. Of course, that’s extreme! In reality, an organization may decide the New Way is what they want, and make small changes over time, marching towards that goal.
On one hand, this approach is not very disruptive, kind of like sculpting with a chisel or even a toothpick. The personnel will basically get ample time to adjust to changes and arguably this means they are invested naturally with minimal distraction. The same went for a post-communist economy: slowly auction off government assets, slowly loosen regulations on the areas the government controlled, and the economy makes adjustments, ranging from building a certain amount of widgets, to learning new skills. In the reality of our engineering organizations though, detractors that have never bought into the New Way could bring a persistent sag to morale. In her book, The Change Monster, Jeanie Daniel Duck points out how critical it is to get proper buy-in, and to handle detractors aggressively.
When looking at a gradual model for a company, buy-in will be much deeper in the organization’s roots, and the system could easily feed itself into improvements over time. However, getting this wrong can result in problems that are just as deeply rooted, so the gradual approach needs full attention for the whole ride.
The most obvious cost to this approach is the amount of time it will take to complete. That’s a central point in the decisionmaking that an organization will have to weigh. If an organization has time (or decides to take the time), it could be the right fit, giving the culture time to shift with minimal impact on the short-term. Arguably, the longer something takes to implement, the more sustained the impact will be.
2. Shock Treatment
This is the other extreme: yesterday you are not an Agile Scrum or SOC2 or New Way shop, today you are. Essentially the approach is: swift and resounding. The benefit of this approach is its unequivocal nature: the org is adopting the New Way without a doubt. It goes into effect on such&such a date. Like a big bang software release, this approach will only be successful with proper preparation. Detractors will be more obvious as well, making it clear where there is disagreement so it can be managed. With a shock approach, arguably management attention can have a shorter lifespan on this issue than in a gradual approach. (Arguably. The caveat is that there still would need to be enforcement after adoption.)
In a study of this approach in transition economies, it was found that wages were sticky once they were set. In a similar way, if tweaks need to be made after adopting the change, it will be harder to put them in place and harder to be successful at it. This is partly because there’s limited feedback and fewer change agents in place, and having that kind of organizational dialogue can be stifled. This can result in confusion and inconsistent adoption of any changes.
Ok, So Which One?
Using transition economies as a reference point is helpful for me when weighing the options and coming up with an action plan for an organization. I’ve experienced each of these approaches both as a leader in organizations, and as an employee. The important variable for me has more to do with the appetite for change among the employees. Working in engineering, you see a broad spectrum of folks that are open to change and innovation, and others that fight against it. I’ve seen behaviors along these lines up and down the development chain, whether it is writing unit tests, building a different feature, or adopting a new deployment model. So indeed for me, the soil I’m working with has a lot to do with my own strategy. In general, I side more with the gradual approach; however, I’ve implemented shock changes that have been effective as well.