I had solved the job I was given.
My health checks replaced repeated manual console work. PowerShell ran from Windows Task Scheduler, queried the systems, applied thresholds, and emailed reports. It worked.
It also lived on a tools server and depended on me understanding it. There was no version history or useful record of what had run, and no safe way for someone else to change it. I’d removed the repeated manual work and left us with something else to look after.
We already had a bigger platform.
The organization was paying a six-figure annual license for a commercial automation platform nobody had adopted. It could do more than the replacement I eventually built. Lack of features wasn’t the problem.
I didn’t want to ask engineers to rewrite scripts they trusted or hand ownership to another team. I wanted them to get something useful from the next step: put the script in source control, give it a repeatable place to run, control its credentials, save its output, and name the owner.
They didn’t have to use my tool.
I wrote those requirements separately from the platform. If a team met them another way, that was fine. On my platform, engineers kept responsibility for their scripts while the shared system handled running them and retaining the results.
I wanted another team to be able to look after its work without routinely calling me. Otherwise I’d just moved the dependency on one person into a bigger piece of software.
My own platform still had gaps.
The review found missing post-change checks and rollback documentation. The SAN health check was also running outside the shared process. Those were unresolved responsibilities in the original account, even though other jobs were running successfully in production.
What I’ve learned is that I need to look past the manual steps I removed. Who can change the automation? How do they recover it? What will they have to work from when I’m not there? Those questions tell me whether I’ve made the work easier for the next person, too.