Change versus Transformation
While a lot of my day to day activity touches on technology, I always explain what I do to people as working with three things: People, Process and Technology. I always explain it in that order, and with good reason. People and process define how we use technology. Which brings me to what this post is about: Change versus Transformation.
Who Moved My Cheese?
Have you ever heard of the book Who Moved My Cheese? It’s a great book about the effect of change on people. As a rule, most people do not like change. In fact we may even say that they fear change.
In my role at my organization, and among the technology community, I am tasked with bringing new things to people which include processes and technology that is new, or different from what we have today.
Many people see the role of a Systems Architect as a “bringer of change” but with the way that people inherently do not like change, I want to change the way that we view this. We need to put aside the word “change” and look at “transformation”.
What’s the difference?
Change as a word is scary when you look at the definition:
If you tell somebody that they are going to be facing change, they do often think of it as replacement, or different. In some cases, it is seen as being replaced which is the real heart of why people fear change. I really enjoy Nick Weaver’s talks on automation because they really highlight where we win on transforming the way that we do our work.
Thus, I like the wording much more when we look at transformation:
While it may be semantics, the truth of the matter is that we have to pitch what we do in Systems Architecture and in business process automation as “transformation” rather than “change”. There will be much better acceptance of new methods if we are able to excite everyone about what we are doing by introducing transformative processes.
Because we’ve always done it that way
I can’t even count the number of times that I’ve been handed the excuse “Because we’ve always done it that way” when I suggest introducing something new, or transforming a process. Isn’t that the worst excuse you’ve ever heard?! We are constantly given this response when we suggest automation, or modifying methods.
And don’t kid yourselves that this isn’t an excuse. It is not a justification, or a “reason”. It is an outright excuse. As in a total fear of change.
Show by example, not by suggestion
There is one thing that I have learned to do over the years to create better adoption of processes or technology, and that is to introduce a working model. In other words, we need to create a proof of concept and show something in practice rather than laying it out on paper or in a meeting room discussion.
It is a bit of a take off from the old saying “it is easier to get forgiveness than permission” really. By having a practical example of a tool, product, or process, we can let people see it in action and be involved in using it which will ensure that people will have a first hand view of how good the transformative process is. (see…I didn’t say new).
Start Small. Win Big.
Introduce something cool to your organization next week. Make it small. Make it cool. Make it meaningful. But the most important thing that you can do is to positively affect people through transformation. It could be as simple as a script for a small manual process. Transformation comes in many shapes and sizes.
Every step towards transformative thinking is a step closer to automation, orchestration and ultimately to a more effective way to do the thing that you do. Excite yourself about it, and excite the people around you with it. You’d be surprised by how quickly the people around you suddenly have less fear of change.
You’ll find that what start’s as trepidation soon leads to adoption.