I work for a very small managed IT services company with only four employees. My boss has extensive experience in internal IT and consulting, but he is extremely cautious about automation and scripting. Most of our processes are manual, and he insists that new computer setups follow exactly the same checklist every time because even a small difference could create an issue that is difficult to troubleshoot.
I think carefully designed setup scripts would improve consistency, reduce human error, and save time. However, my boss believes scripts eventually become outdated or break, making them more trouble than they are worth. He will not even approve minor changes to one of our existing remote-management scripts. The script uses Dell Command | Update to scan for firmware updates, but it is several years old, produces errors from custom properties we no longer use, and does not report when manual intervention is required. I was told to use vendor-supported commands or find a replacement instead of modifying it.
There is also a security policy blocking that script from running, apparently because our endpoint application-control rules are too restrictive. I understand that automation needs testing, documentation, monitoring, and maintenance, and I am not suggesting blindly deploying untested code. Still, it seems contradictory to demand perfect consistency while rejecting tools that can make the process repeatable.
Am I overlooking legitimate risks, or is my boss being unusually resistant to modern IT practices?
4 Answers
Your boss is not completely wrong about the danger of powerful scripts. A poorly tested automation tool with broad permissions can damage an entire customer environment much faster than a person can. Production changes should have safeguards, limited permissions, a test environment, staged deployment, backups, and a clear rollback plan. Security controls also need to be reviewed so legitimate tools are allowed through deliberately rather than simply blocked.
That said, demanding flawless manual work for years before permitting a carefully scoped test is not a practical way to build trust. Start with low-impact tasks such as reporting, inventory checks, or firmware-status collection, and document the results. If even small, controlled experiments are rejected, the issue is probably organizational resistance rather than technical risk.
The business model may be part of the problem. Some service providers depend heavily on manual billable work, so efficiency can look like lost revenue. That approach can work at a very small scale, but it makes growth difficult and leaves technicians spending time on repetitive tasks instead of higher-value work.
Whether the company uses fixed-price support or hourly billing, better automation can improve service quality and reduce preventable incidents. If the company has no interest in improving its processes, you may eventually have to choose between accepting that environment and finding a workplace where automation and professional development are encouraged.
There is some legitimate caution here, but the reasoning is being taken too far. Unmaintained automation can absolutely fail, especially after vendor or operating-system changes. That is an argument for version control, testing, logging, documentation, and review—not for doing everything manually forever.
For a risk-averse manager, start with a small, reversible improvement. Test it on a few noncritical machines, make it safe to run repeatedly, include clear error handling, and produce a report showing what happened. A short pilot with an easy rollback is much more persuasive than a broad proposal to automate the entire onboarding process.
Manual work is not automatically safer. Every manual step introduces opportunities for inconsistency, missed actions, and simple mistakes. A well-designed script can enforce the same desired state every time, record its actions, and stop when something unexpected occurs.
The important distinction is between a random one-off script and a managed automation process. Scripts should be treated like production tools: test them, keep them in a repository, document prerequisites, monitor failures, and review them when vendors change their interfaces. Updating an old script and fixing noisy output is normal maintenance, not reckless reinvention.
The concern about automation reducing billable hours is less compelling when clients pay a predictable monthly fee. In that model, efficiency helps the provider stay profitable while giving technicians more time to be proactive.