First: reframe the conversation
The biggest mistake engineers make when proposing a tool to replace their own work is framing it as "what I built isn't good enough." That's a career risk. Nobody wants to hear that their own work should be thrown away.
The correct frame is: "What I built solved the problem we had 18 months ago. The problem has grown. The solution needs to grow with it."
This isn't spin. It's accurate. When you wrote the script, you had 8 firewalls across 2 vendors. Now you have 35 firewalls across 4 vendors. The script was the right call at the time. It's the wrong call now. Your engineering judgment was correct then and it's correct now — what changed is the scale of the problem.
The 4-step playbook
Track your time for 2 weeks. Be brutally honest.
Before you talk to anyone, you need data. Track every hour you spend on script-related work for two weeks. Include everything: maintenance, debugging, on-call responses, vendor API updates, the Monday spreadsheet, incident recovery, documentation updates. Write it down. Don't estimate from memory — memory is kind to you and your manager won't trust it.
The goal is a single number: hours per week spent on infrastructure automation maintenance. In our experience, this number is typically 10-15 hours for a primary maintainer. That's 25-40% of a senior engineer's capacity.
Present the problem as a business risk, not a personal complaint.
Your manager doesn't care that you're tired of maintaining scripts. That sounds like a morale issue, not a business issue. But your manager does care about:
- Key-person risk. "If I go on miluim for 30 days, nobody can maintain or debug the sync system."
- Split-brain exposure. "When the script fails mid-push, we have firewalls with different policies. That's a compliance finding waiting to happen."
- Opportunity cost. "I'm spending 12 hours a week on glue code instead of the micro-segmentation project we keep postponing."
- Scaling ceiling. "We're adding 2 more sites next quarter. The script can't handle that without a major rewrite."
These are risk and efficiency arguments. They're manager language. They work because they describe organizational problems, not your problems.
Ask for a test, not a purchase.
Don't ask your manager to buy anything. Don't present a vendor's pricing page. Don't send a sales deck. Ask for permission to test one alternative for 3 hours. That's it. Three hours. No budget. No commitment. No procurement process.
Cyberm8 deploys as a container. You can pull it onto a test host, connect it to one firewall, and run a sync in under an hour. If it works, you have a demo to show your manager. If it doesn't, you lost an afternoon. The risk is asymmetric in your favor.
Show, don't tell. Use their worst scenario.
After your test, schedule 15 minutes with your manager. Show them two things:
- The happy path. A rule pushed to two firewall vendors simultaneously, with a unified audit trail. Point out: "No Python. No per-vendor code. No session management."
- The failure path. Simulate an API timeout mid-push. Show the automatic rollback. Point out: "This is the scenario that pages me at 2am. The platform handles it. I sleep."
The failure demo is more powerful than the success demo. Every manager has lived through a 2am escalation. Showing them that it goes away is worth more than any slide deck.
The script for the conversation
Here's a fill-in-the-blanks template for the actual conversation with your manager. Adapt it to your style, but keep the structure: data → risk → proposal → ask.
"I've been tracking my time on the firewall sync automation for the past two weeks. I'm spending about X hours/week on maintenance, debugging, and on-call for that system. That's X% of my capacity."
"The core issue is that the system I built was designed for N firewalls and N vendors. We now have N firewalls across N vendors. The complexity has outgrown the architecture."
"There are two specific risks I'm concerned about. First, I'm the single point of failure — nobody else can debug this code. If I'm unavailable, the sync system is unsupported. Second, when the script fails mid-push, our firewall estate enters an inconsistent state that requires manual recovery."
"I found a platform called Cyberm8 that handles this specific workload. I tested it on a single firewall in 1 hour. It replaced N lines of my Python code with a drag-and-drop configuration. The failure recovery is automatic — no 2am pages."
"I'm not asking for a purchase decision. I'm asking for permission to run a proper 3-hour evaluation against our actual firewall estate. If it works, I'll present the business case. If it doesn't, we've lost an afternoon."
Objections you'll hear (and how to handle them)
Do's and Don'ts
Don't say
Do say
The email you can forward right now
If a face-to-face conversation feels like too much, start with an email. Here's a template:
Hey [name],
I tracked my time on our firewall sync automation for the past two weeks. I'm averaging [X] hours per week on maintenance, debugging, and on-call — about [X]% of my capacity. The system I built works, but it was designed for a smaller environment. With [X] firewalls across [X] vendors now, the maintenance load has scaled past what's sustainable as a side task.
Two risks that concern me: (1) I'm the only person who can debug the code — single point of failure. (2) When the sync fails mid-push, our firewalls end up in an inconsistent state that requires manual recovery.
I found a platform called Cyberm8 that specifically handles this workload. I tested it on a single device — it took [X] minutes and replaced [X] lines of custom code. The failure recovery is automatic (transactional rollback).
I'd like to run a proper 3-hour evaluation against our actual firewall estate. No cost, no commitment — just a container on a test host. If the results are compelling, I'll put together a formal recommendation. If not, we've lost an afternoon.
Worth a try?
Forward this article to your manager if you want. It's designed for them to read too. The URL doesn't have "sales" or "demo-request" in it. It's an engineering playbook that happens to describe a real platform. Most managers will respect the approach, even if they don't immediately say yes.
We'll help you build the case.
Tell us what your environment looks like. We'll give you a test container, a pre-built demo scenario against your vendor stack, and — if you want it — a one-page business case template with your numbers pre-filled.
Help Me Build the Case → info@cyberm8.com — we've helped 20+ engineers have this exact conversation.