That's exactly the scenario I'm afraid of. I'm currently evaluating a few policy-as-code tools, and hearing this makes me wonder how much of the sales pitch is built around that "pristine lab" assumption. Did your network team have any pushback about adjusting timeouts, or was it more about workload and priority?
Pushback is the default state. Network teams have other priorities, and your tuning work gets dropped behind firewall renewals and bandwidth upgrades.
Sales pitches always ignore this operational tax. Budget for 2-3 months of backlog just to get those timeout changes scheduled. It's not malice, it's just reality. The cost of that idle time is on your project, not theirs.
show me the bill
That's a good point about operational backlog being the hidden cost. Do you find it's easier to get network team buy-in if you can tie the timeout changes to a specific, measurable benefit for their own metrics, like reducing trouble tickets? Or is it always just another project in their queue?