- If your AI-generated code becomes faulty, who faces the most liability exposure?
- This Galaxy Watch is one of my top smartwatches for 2024 and it's received a huge discount
- One of my favorite Android smartwatches isn't from Google or OnePlus (and it's on sale)
- The Urgent Need for Data Minimization Standards
- If ChatGPT produces AI-generated code for your app, who does it really belong to?
More work for admins: When labor-saving management tools don’t ease workloads
If not deployed properly, today’s whiz-bang network management tools wind up making more work for network admins rather than saving them time and reducing their overload.
Wait, labor saving devices don’t save labor? Not really, at least when it comes to freeing up time for more important or rewarding activities.
It’s not unlike the “labor saving appliance” revolution in the American home, especially in the post-WW2 era.
I’m referring, of course, to Ruth Schwartz Cowan’s classic history of technology book, More Work for Mother, which explored in depth how various supposedly labor-saving advances in household technology did not reduce the amount of time those women who kept house spent on housekeeping. On the contrary, because they mainly mechanized or automated work previously done by servants, children, or (occasionally) men, these tech advances shifted women’s efforts from organizing such work to doing it. At the same time, with some kinds of work around food preparation and clothes washing, they also brought back “in-house” work that had been effectively outsourced to commercial laundries, bakeries, etc.
And, most perversely, the steady infusion of technology ratcheted up expectations. For example, standards of cleanliness increased with the advent of vacuum cleaners, dishwashers, and washing machines. It might have been easier to achieve the status quo ante levels of cleanliness, but any time saved on that was consumed in achieving the new levels of cleanliness expected.
We can see similar dynamics play out when an organization rolls out new management tools and new ITSM platforms.
A new ticketing system may make it easier and much faster to implement existing ticket tracking and work scheduling processes and procedures, and it may save network admins time in dealing with project work and trouble tickets. Automatic workflows, for example, and auto-filling of contact information can save a lot of time and, as importantly, reduce the interruption to mental flow, allowing network teams to get more done and also spend more time focused on the environment and less on “administrivia.”
But once such a system is in place, there is a temptation and, sadly, a common tendency for IT managers and leadership to elaborate on the processes and procedures. For example, with the new platform in place, management may require network staff to enter more information related to a ticket’s context and resolution into a knowledge bank, or to layer on additional customer-centric tasks akin to “Would you like fries with that?” and not directly related to the tickets per se, or even the kinds of work originally targeted for automation and labor-savings. This ratcheting up of requirements and expectations can rapidly (but stealthily) nibble away actual time savings resulting from deployment of the tool.
This isn’t automatically a bad thing. There are multiple reasons to add management and process automation tools beyond saving network admins time and freeing them up to do other things on their backlog of tasks (for example, improving consistency in deployment; improving security; shortening execution times; deskilling an activity). However, freeing some of their time up for other work is frequently cited as a reason for deploying automation, but, almost always, with a qualification: free up time for other strategic and important work.
So, the tendency of new work to crop up and to eat up the time saved with a labor-saving management tool is only a bad thing to the extent that it is allowed to happen without careful consideration of its opportunity cost relative to that backlog of other “strategic and important” work. And, despite a gut sense that “of course it’s less important than this strategic network project over here that has been resource starved for months,” in point of fact, some of these elaborations and ratchetings-up are in pursuit of other strategic goals and priorities. Rapidly expanding a knowledge base, for example, may be central to a strategy aimed at both increasing self-service in problem resolution and at increasing service desk resolution rates, with the goal of decreasing ticket flow to the network team overall.
There are lots of good reasons to ramp up automation in the network. It is incumbent upon network teams to make sure that doing so gets them the most leverage on their overall workload and backlog, and that their strategic concerns are central to what happens next.
Copyright © 2022 IDG Communications, Inc.