The ticket says the Wi-Fi is slow. It says the VPN keeps dropping. Shimul Shah has spent eight years learning that those sentences are where an investigation starts, not where it ends.

"The fastest resolution is the one you only have to do once," she says. It is the sentence that organizes almost everything about how she works.

Shah is a network systems engineer who moved from Cisco Meraki's Technical Assistance Center to Fortinet, where she now works as a systems engineer. The through line across both roles is a stubborn refusal to patch symptoms. When a case reaches her desk after someone else has already rebooted a device or flipped a setting, she assumes the real cause is still sitting there, waiting to resurface.

At Cisco Meraki between 2019 and 2022, she resolved more than 3,000 cases, including 250 critical escalations across wireless, switching, firewalls, VPNs, and dynamic routing. Her customer satisfaction score averaged 8.5 out of 10. The number she points to more often, though, is a recurrence rate of about one in twenty. In environments where she led root-cause analysis, repeat incidents dropped by roughly 30 to 50 percent, and mean time to resolution fell between 20 and 40 percent.

One case she still describes in detail: a customer with intermittent internet outages that had been "fixed" more than once before the ticket reached her. Instead of adjusting settings by trial and error, she pulled Wireshark captures, walked through OSPF and BGP behavior, and worked with engineering to isolate the fault. It was a routing loop paired with a VPN misconfiguration. Four months later, nothing had come back.

"Packets don't lie," she says. "Assumptions, dashboards, and even customer descriptions can mislead you. A packet capture shows what is actually happening on the wire."

That instinct also reshapes how she handles wireless complaints. Customers tend to assume slow Wi-Fi means a bad access point. In Shah's experience, the cause is usually something quieter: channel utilization, channel width, interference, or inconsistencies between gateways and repeaters. During her time at Promethean IT, a client's newly installed Meraki access points were delivering poor throughput, and no one on the team had cracked it. She analyzed the RF environment, adjusted channel utilization and width, and did live troubleshooting during a scheduled downtime window. The throughput problem went away. The hardware stayed.

"Many hardware failures are design failures," she says. "Replacing hardware without understanding the environment costs money and leaves the real problem in place."

Her Promethean years, from 2018 to 2019, were a crash course in multi-site reliability. She designed, managed, and monitored network and security infrastructure for more than 10 clients with branch offices across the country. She deployed a hybrid identity setup, Azure AD with multifactor authentication and single sign-on, for more than 200 users. She segmented a three-floor wireless deployment across 18 access points, each floor on its own VLAN. And as project lead on a Fonality VoIP rollout that covered 300 phones, she designed the network so voice traffic would not compete with data traffic. The call-quality complaints that usually trail VoIP rollouts never materialized.

At Fortinet, where she has worked since 2022, the pattern repeats at a different altitude. Shah maintains technical depth across more than 40 Fortinet products and is the primary technical voice on sales calls. She has delivered more than 450 demos and 100 proofs of concept, work that has contributed to about $15.5 million in closed revenue and an 80 percent win rate on those engagements. She has trained 6 systems engineers and 20 account managers along the way.

The customer conversations tend to start the same way, she says. "Prospective customers often come in asking about a single product when their real problem is a broader architecture gap." She builds Security Fabric lab environments that stitch together firewalls, switches, access points, SASE, EDR and XDR, and NOC and SOC tools, then uses them to prove out designs tailored to the gap she actually finds.

Teaching has been part of the job from early on. At Cisco Meraki she was Intern Mentor Lead for the 2022 program, guiding 10 of its 30 interns. Seven of her 10 were hired full-time. She also co-led volunteer classes for three cohorts.

"Root-cause thinking is a teachable discipline, not a talent," she says. "Isolate the layer, reproduce the issue, verify with data, then fix."

Not every root cause is technical. At Temple University, she introduced a ticketing system that cut overall problem-resolution time by 15 percent. "The engineers didn't get faster," she says. "The system just stopped losing track of requests."

She keeps coming back to the part of the job that happens after the fix: explaining the why. Customers who understand the cause of their outage make better decisions afterward, and the issue is less likely to come back. For an engineer who prefers to resolve a problem once, that is the whole point.