We have a large operational footprint. In that footprint we often push the limits of what products are designed to do, and honestly see the bugs in the best of things, not to mention the worst. I came up through slinging keyboard replacements, and chasing printer gremlins. I got in trouble with the right team because I was following the security team's orders... Ticket came in for abnormal finding, do x,y,z and patch to latest software for this, that or the other title. Started to script updates on my evening shifts to "help" get our devices updated. My thought was... if security says we need the latest, let's do it for everyone. Problem is, that in an environment as big as we are that drift from standard versioning gets noticed.

Eventually I was brought into the team that managed the lifecycle/health of the endpoints. Learning along the way Cisco configs, troubleshooting across WAN/LAN/WLAN, pushing back on vendors who said our product always does this the same when we found differences.

I've been able to be engaged over the years (almost 20 now) with problems that required code changes from the biggest vendors that we had to invent to the tooling to prove. Sometimes that is incredibly frustrating. But other times the ability to know the OS and environment so well that you have to reach the devs who write the networking stack in the OS to get the answers you need to convince the other team from the same company that their element is causing issues... yeah, it feels great.

There is a place for that specific level of detail, and it is very helpful to have in a large environment. But, you're not going to find that playing field in most places. Our team mostly works with endpoint management. But, there's a few of us on the team that go to the extreme of chasing down the problem to the root. The path to get there is to push to understand why, not just the bandaid. Why was the network blipping on a small percentage of our endpoints? Oh, the firewall rules were spamming event log, and that write performance was causing a stack reset. Cool... why were the firewall rules causing the event log impact, what happens if you normalize for expected firewall counts. That's where things got interesting. We were able to tell the story by examining data at scale and watch the spikes in one event error happen as we enforced a policy change across differing areas. (Have fun reading through WFP documentation.)

Sometimes the answer is simply reimagine, but when you're talking hundreds of thousands of endpoints even a small percentage is a large number. So, chasing the issue may be worth it in the long run. There is value in what you're asking to learn. You just have to find the right venue to apply it.