I've noticed an interesting paradox. Many of us get into IT because we're excited by new, cutting-edge technology, and yet as a profession we can be extremely resistant to change. The extent differs from person to person, and between organisations, but it's a theme pretty much everywhere. Even in the most cutting-edge startup, there's an engineer who'll tell anyone who'll listen that things all started to go wrong with that release a few months ago. This can become a real problem both for individuals and for whole organisations, as change is inevitable and is the only way to take advantage of new opportunities. Resistance to change is rooted in fear. By overcoming that fear, particularly when related to automation, and by embracing change, you and your organisation can be happier and more productive.
Change resistance
There are many ways people can hinder change. It can take the form of direct challenges; for those in authority it could be the refusal of change initiatives, or direction to maintain existing services in the same way as before. For those without direct authority it can be vociferous complaint whenever the topic is mentioned, challenges to change programmes through things like unions, or refusal to engage and support change initiatives. Some forms of change resistance are more subtle. By overplaying the risks of change and underplaying the benefits, the resistant can use governance processes to maintain the status quo, and can systematically prevent change from happening. If you notice that your organisation consistently ignores the risks inherent to existing approaches when exploring new ones, this may be happening to you.
Ultimately, change resistance comes from fear of the consequences of change. Allowing fear to make decisions on a personal level is unlikely to result in happiness, and indeed can make the fearful outcome more likely. This process is akin to target fixation, the phenomenon where, in trying to avoid an obstacle, the fixation of the driver's gaze directs them towards a collision. The way to avoid target fixation is to instead focus on the escape route. This turns out to be true when seeking happiness too, and why a focus on positive goals rather than simply the avoidance of unhappiness is so important.
Automation for all
Perhaps the most significant fear is that your job will be automated away, leaving you with nothing to do. This is a trend across all sectors, but it's been a feature of IT since the discipline started. I suspect it goes a long way to explain the resistance to change technical people can show. Automation has a long history; perhaps as long as the development of technology itself. It's an unavoidable consequence of the creation of process efficiency. As industrialisation takes hold, jobs which previously involved many people only take a few. The most obvious example of this is in agriculture, where farms which would have provided jobs for hundreds are now run by only a handful of staff.
On the face of it, this sounds like a bad thing, and that automation is creating unemployment. However, what it's actually doing is freeing people from the requirement to meet basic needs, and allowing them to focus on higher-level needs. It's also making the workers who remain much more productive. Agricultural workers were freed to pursue other, more rewarding, less backbreaking vocations, whilst there still being enough food to go around.
A few generations later and one of our farm-worker's descendent is working as a systems administrator. The forces of automation remain, though. When he joined the profession, it was normal to custom-build servers and to compile the operation system for specific hardware, and then configure all the settings individually. That's not something anyone would do anymore, and it's not even something most people would consider. It's completely orthodox to run a server instance in a virtual machine with settings configured and managed by a config management tool like Puppet, Chef or SCCM. Now, there's pressure not to use independent server instances at all, but instead to use containers hosted in the cloud.
The importance of abstraction
This example highlights another important feature of automation; it goes hand in hand with abstraction. The importance of abstraction is that it allows the user of the system to focus on what they're actually trying to achieve, without getting bogged down in the underlying way the tools work. Abstraction is great for ensuring processes happen consistently, which is a key requirement of automation. However, it comes at the cost of flexibility. A necessary part of the abstraction process is the creation of specific modes of use, which rely on assumptions about how people are going to use the tool. Take the difference between an command-line interface and GUI. The GUI is a higher-level abstraction of the OS than the command line. That's not to say one is better than the other, but a GUI is quicker to learn, more consistent in use, and an awful lot less flexible. It's about choosing the right tool for the job.
When something moves from being bespoke, specialist and expensive to being consistent, predictable and (relatively) cheap, it becomes a commodity. As products start to commodify, you see a range of similar but slightly different offerings available on the market to suit specific needs. When an IT product becomes a commodity, it's time for in-house IT to stop delivering it themselves, and start buying it in, as there's no value to add in customising a commodity for the organisation. A good example of this which is happening at the moment is the changes to email. A few years ago, enterprises needed to run their own mail servers in order to get the service and security they needed. Features like legal hold and robust message hygiene required skilled staff to manage them with on-premise servers. This is no longer true, and today buying in email from Microsoft or Google is likely to result in a better product than can be delivered in-house, at a fraction of the cost.
Future-proofing yourself
If you're the one responsible for email services you might worry whilst reading this. That's a perfectly reasonable response, but as I've outlined above, there's no point standing against the tide. Instead, there are a two steps you cant take to avoid being left behind. The first of these is to look for integration opportunities between newly commodified services. Can you, for example, link the management of a new cloud email service with an enterprise bus, giving your users a supercharged version of IFTTT? In this scenario, you're looking for opportunities to build new abstractions out of mutually-independent commodity building blocks. There's almost certainly huge value there.
The second step is to build the kind of skills which aren't directly related to technology and aren't vulnerable to being automated away. These are often referred to as soft skills, but they're as vital to good IT as technical talent, and becoming more so. As users get used to more sophisticated, abstracted systems in their everyday lives, such as mobile phones, social websites, and consumer cloud services, they come to expect these at work as well. The ability to understand user needs and behaviour on a fundamental level is vital to deliver these kind of services effectively. The development is also increasingly collaborative, and focusing on the people skills necessary to be effective in a team is also highly automation-resistant.
Using these approaches you have nothing to fear from automation. By embracing the opportunities that newly-commodified services bring you can change things for the better and increase your level of security, rather than allowing to to ebb away. However, by pushing back against the tide you will only put yourself in a more and more precarious situation, actively bringing about the very thing you're trying to avoid, in a fine example of the dangers of target fixation. Don't worry if what you were doing last year has been automated away, go and build something new out of its replacement.
Change resistance
There are many ways people can hinder change. It can take the form of direct challenges; for those in authority it could be the refusal of change initiatives, or direction to maintain existing services in the same way as before. For those without direct authority it can be vociferous complaint whenever the topic is mentioned, challenges to change programmes through things like unions, or refusal to engage and support change initiatives. Some forms of change resistance are more subtle. By overplaying the risks of change and underplaying the benefits, the resistant can use governance processes to maintain the status quo, and can systematically prevent change from happening. If you notice that your organisation consistently ignores the risks inherent to existing approaches when exploring new ones, this may be happening to you.
Ultimately, change resistance comes from fear of the consequences of change. Allowing fear to make decisions on a personal level is unlikely to result in happiness, and indeed can make the fearful outcome more likely. This process is akin to target fixation, the phenomenon where, in trying to avoid an obstacle, the fixation of the driver's gaze directs them towards a collision. The way to avoid target fixation is to instead focus on the escape route. This turns out to be true when seeking happiness too, and why a focus on positive goals rather than simply the avoidance of unhappiness is so important.
Automation for all
Perhaps the most significant fear is that your job will be automated away, leaving you with nothing to do. This is a trend across all sectors, but it's been a feature of IT since the discipline started. I suspect it goes a long way to explain the resistance to change technical people can show. Automation has a long history; perhaps as long as the development of technology itself. It's an unavoidable consequence of the creation of process efficiency. As industrialisation takes hold, jobs which previously involved many people only take a few. The most obvious example of this is in agriculture, where farms which would have provided jobs for hundreds are now run by only a handful of staff.
On the face of it, this sounds like a bad thing, and that automation is creating unemployment. However, what it's actually doing is freeing people from the requirement to meet basic needs, and allowing them to focus on higher-level needs. It's also making the workers who remain much more productive. Agricultural workers were freed to pursue other, more rewarding, less backbreaking vocations, whilst there still being enough food to go around.
A few generations later and one of our farm-worker's descendent is working as a systems administrator. The forces of automation remain, though. When he joined the profession, it was normal to custom-build servers and to compile the operation system for specific hardware, and then configure all the settings individually. That's not something anyone would do anymore, and it's not even something most people would consider. It's completely orthodox to run a server instance in a virtual machine with settings configured and managed by a config management tool like Puppet, Chef or SCCM. Now, there's pressure not to use independent server instances at all, but instead to use containers hosted in the cloud.
The importance of abstraction
This example highlights another important feature of automation; it goes hand in hand with abstraction. The importance of abstraction is that it allows the user of the system to focus on what they're actually trying to achieve, without getting bogged down in the underlying way the tools work. Abstraction is great for ensuring processes happen consistently, which is a key requirement of automation. However, it comes at the cost of flexibility. A necessary part of the abstraction process is the creation of specific modes of use, which rely on assumptions about how people are going to use the tool. Take the difference between an command-line interface and GUI. The GUI is a higher-level abstraction of the OS than the command line. That's not to say one is better than the other, but a GUI is quicker to learn, more consistent in use, and an awful lot less flexible. It's about choosing the right tool for the job.
When something moves from being bespoke, specialist and expensive to being consistent, predictable and (relatively) cheap, it becomes a commodity. As products start to commodify, you see a range of similar but slightly different offerings available on the market to suit specific needs. When an IT product becomes a commodity, it's time for in-house IT to stop delivering it themselves, and start buying it in, as there's no value to add in customising a commodity for the organisation. A good example of this which is happening at the moment is the changes to email. A few years ago, enterprises needed to run their own mail servers in order to get the service and security they needed. Features like legal hold and robust message hygiene required skilled staff to manage them with on-premise servers. This is no longer true, and today buying in email from Microsoft or Google is likely to result in a better product than can be delivered in-house, at a fraction of the cost.
Future-proofing yourself
If you're the one responsible for email services you might worry whilst reading this. That's a perfectly reasonable response, but as I've outlined above, there's no point standing against the tide. Instead, there are a two steps you cant take to avoid being left behind. The first of these is to look for integration opportunities between newly commodified services. Can you, for example, link the management of a new cloud email service with an enterprise bus, giving your users a supercharged version of IFTTT? In this scenario, you're looking for opportunities to build new abstractions out of mutually-independent commodity building blocks. There's almost certainly huge value there.
The second step is to build the kind of skills which aren't directly related to technology and aren't vulnerable to being automated away. These are often referred to as soft skills, but they're as vital to good IT as technical talent, and becoming more so. As users get used to more sophisticated, abstracted systems in their everyday lives, such as mobile phones, social websites, and consumer cloud services, they come to expect these at work as well. The ability to understand user needs and behaviour on a fundamental level is vital to deliver these kind of services effectively. The development is also increasingly collaborative, and focusing on the people skills necessary to be effective in a team is also highly automation-resistant.
Using these approaches you have nothing to fear from automation. By embracing the opportunities that newly-commodified services bring you can change things for the better and increase your level of security, rather than allowing to to ebb away. However, by pushing back against the tide you will only put yourself in a more and more precarious situation, actively bringing about the very thing you're trying to avoid, in a fine example of the dangers of target fixation. Don't worry if what you were doing last year has been automated away, go and build something new out of its replacement.
Comments
Post a Comment