This is a piece about the danger of not handling change in the modern world, most specifically in regards to IT organizations. I’m going to be using Apple as an example of an org that has (for the most part) done very well in anticipating change and steering in the correct direction. They’ve definitely had their failures... nobody bats 1.000 all the time (as I’ll mention below).
There’s a maxim: Change will happen whether you like it or not. I like to say that it’s up to you to attempt to shape the future in the way most beneficial to your org. But organizations and individual people (this isn't just a group psychology thing) often settle into an equilibrium that is difficult to get out of because it’s comfy or too profitable. This creates an inertia that an organization is dangerously good at maintaining, not having the courage to make necessary change and ignoring challenges that might cause them to struggle now or in the future. Thus they remain blissfully unaware that they are a frog in a pot of gradually hotter water, their options slowly evaporating until it’s too late.
To quickly bring this to an individual level that most will understand, people don’t quit smoking or drinking because it's hard, or even because it might affect their social life despite the health benefits. Many people stay in unfulfilling relationships not out of passion, but because the barrier to entry to a new life feels higher than the daily tax of boredom. These are all common personal behaviors, and people need to fight against it in order to change. It's called inertia for a reason.
On a larger scale, companies don’t want to have to spend a bunch of money and employees sometimes don’t want to have to risk problems/looking bad, or learning new things. I’m mainly going to be focusing on the change required for existing products and tool sets. I think there’s some iron rules of systems to determine this desirability.
1. Understand and Re-evaluate
We must seek to understand the system we are working in as much as possible and re-assess on a regular basis. In the case of IT nerdery, we need to know the needs of the organization, costs associated, the costs of maintain the existing tooling, and the complications of jumping ship to something else.
To be successful this has to be regularly re-evaluated, not just for new products, but to see if it’s the right time in terms of headcount, feature set, etc.
Investigation and re-evaluation are difficult if not impossible normally. Most IT orgs are understaffed and underfunded, and research and planning both tend to get put off until tomorrow when concerns that appear more urgent to management appear. This is doubly so in today’s age of cost and staffing cuts, increased velocity of change due to AI and other global changes. These sorts of changes make the necessity of awareness and planning for what’s next even more important.
2. Take action when appropriate
Be ready to strike when the iron is hot. When there’s a crossroads, we need to be ready to switch if needed. But consider that the ‘old and busted’ product/path doesn’t need to be discarded immediately. Even if the next product we’ve identified does everything except make us coffee, we still might have financial/contractual constraints, staff training, more important projects to finish, etc. But we need to have a plan to move forward at any time.
Generally a system generally only changes when the cost of staying the same becomes higher than the cost of blowing it up, and people that don’t prepare to strike when necessary end up on the short end of the stick. When Apple released the original iPhone, Blackberry and Microsoft both didn’t understand the system and what users wanted, and they weren’t ready to respond. They continued on their existing path until it was far too late, and both are effectively out of the mobile market.
Also consider that the ’new hotness’ is not always good (yet). Just because a new product is announced it might not fit our requirements. But change is inevitable in our field. Apple has been the avatar, possibly the primary avatar of Schumpter’s idea of creative destruction for years. They’ve been willing to not only "drink the milkshake" of other companies’ businesses (see ya, Blackberry) but also their own. In 2005 they released the iPod nano which was an even better product than the iPod mini despite the latter still being ridiculously popular. They said at the time they are fine with cannibalizing their own sales as long as other companies aren’t doing that. Successful entities destroy their own 'good' current state to reach a 'great' future state.
There’s a possibly apocryphal story I heard back in the day about Steve Jobs, probably fourth hand or worse. This was during the time when he was away from Apple running NeXT and he had made a major enterprise sale of a version of NeXT OS. When the subsequent version came out, which was superior but had some significant changes to the UI, the enterprise buyer refused to pay for the upgrade, saying they’d have to go through the cost and effort of completely retraining their staff. It was that in part that made Steve decide that Apple wasn’t focused on the enterprise. That static enterprise customers weren’t who he wanted to associate with in order to run a vibrant, fast-paced business - which certainly didn’t make enterprise customers very happy when he’d say that out loud...
While companies like Microsoft continue to support parts of their OS that go back decades, Apple has been nimble enough to not only change their user interface but to change CPU platforms twice in the last 20 years. While Apple doesn’t attract as many slower and safer customers as Windows does, since they make the whole widget and don’t have to worry as much about backward compatibility they can produce more secure hardware and software. Their ability to be a nimble organization and skate where the puck is going, to quote Wayne Gretzky, allows them to not only give Apple users a good experience but also improve security for those users.
3. Change isn't always successful
Finally I want to point out that we always make mistakes and things are always harder than we think they are going to be. People choose products that aren’t exactly fit for purpose, or there’s hiccups in deployment processes (bugs are a way of life in IT). People often mistake a 'Deployment' for a 'Success.' They think that just because they’ve spent months on a build, they have to launch it—even if the code is a mess. I tell people starting out in IT that they shouldn’t be afraid to fail. I break stuff all the time. It’s not a question of if they are going to miss something or press the wrong button, but how they deal with it. Owning up to it is vital so people know if any other followup is needed, and so everyone can learn lessons. And wisdom gives people the ability to know how to minimize errors in the future.
Finally, a vital part of any deployment or change is to review what went right and what went wrong. This isn’t to assign blame, it’s to call out any potential limitations, a call to improve support and end user documentation, and to improve processes going forward. This can help us welcome needed change and make future changes more seamless as they inevitably show up at our door and demand entry. We don’t have to always accept change with open arms because it is often really, really hard, but it’s also important to not look away from change with closed eyes either. The more these changes are looked at and planned the more likely there isn’t going to be a ‘jump scare’ or something else that makes that particular change problematic.