Is My Boss Too Risk-Averse About Automation?

0
6
Asked By MellowBirch42 On

I work at a very small managed services provider with only four employees. My boss has extensive experience in internal IT and consulting, but he is extremely cautious about automation, scripting, and changing established procedures. Most of our work is done manually, even though he also insists that processes—such as preparing new laptops—must be performed exactly the same way every time to avoid unexplained differences between machines.

I feel that carefully designed setup scripts would actually improve consistency and reduce human error. However, my boss is reluctant to let me make even minor changes to an existing script used through our remote management platform to check Dell firmware updates. I wanted to remove a few unused custom-property commands that generate errors and clutter the output, and add a property indicating when manual intervention is needed. He considers customizing the script too risky and prefers using commands or scripts provided by the platform community, even though the current script is about four years old.

I also discovered that our ThreatLocker policies block this firmware-update script from running at all. This makes me question whether the overall approach is becoming counterproductive.

I understand that poorly maintained automation can break, and I do not want to introduce unsafe changes. At the same time, manual work can be inconsistent, difficult to scale, and prone to human error. Is my boss being reasonably cautious, am I underestimating the risks, or is the real answer somewhere in the middle?

4 Answers

Answered By RiverNook6 On

The billing model matters too. Some providers resist automation because manual work creates more billable hours. If your clients are on fixed-fee or all-inclusive agreements, efficiency is usually beneficial: fewer preventable incidents, more proactive work, and better margins over time. Even with hourly billing, automation can free technicians to handle higher-value projects instead of repetitive maintenance.

I would avoid assuming bad motives immediately, though. Ask what evidence would make your boss comfortable: a test environment, limited permissions, a rollback plan, documented ownership, or a review period. If there is no acceptable path even for a tiny change, that tells you a lot about the culture.

Answered By CopperVale7 On

Your boss has a legitimate concern about unmaintained automation, but he seems to be using that concern to reject automation altogether. A well-designed script should be tested, logged, reviewed, and maintained just like any other operational process. Manual procedures are not automatically safer—people skip steps, mistype values, and perform tasks differently.

The strongest argument for scripting laptop builds is consistency. Start with a small, reversible change rather than proposing a complete overhaul. Build in validation, clear error handling, logging, and a way to stop safely when a prerequisite is missing. Test it on a non-production device, document the results, and show exactly what happens when something fails.

Answered By GraniteFox88 On

There is some truth to the caution. A script with broad permissions can damage an environment much faster than a person working through a checklist, and vendor changes can break previously reliable commands. Scripts should be treated as software: use a test machine or development tenant, limit permissions, use version control, review changes, and deploy gradually.

That said, refusing to update a four-year-old script while also allowing security tooling to block it is not a strong risk-management strategy. The safer approach would be to investigate the block, update the script deliberately, and establish a maintenance and testing process.

Answered By PixelHarbor31 On

This sounds less like a technical disagreement and more like an organization that has stopped learning. Automation does not eliminate responsibility; maintaining scripts becomes part of the job. Idempotent scripts, good logging, error checking, alerts, and staged rollouts make failures easier to detect and recover from.

A manual checklist can still be useful as a fallback or verification tool, but making every employee repeat every step by hand forever will limit how much the business can grow. If your boss will not allow even low-risk improvements after you demonstrate them carefully, you may eventually have to choose between staying stagnant and finding a workplace that supports the skills you want to develop.

Related Questions

LEAVE A REPLY

Please enter your comment!
Please enter your name here

This site uses Akismet to reduce spam. Learn how your comment data is processed.