Stub resolvers only try a different DNS server in the list of available servers if they fail to get a response after trying one server. If they do get a response, then they don't go down the list querying other servers just to make sure the other servers agree with this response. (And if they found conflicting responses, which one should they trust?) So it's normal that when Google's DNS server claims your intranet host doesn't exist, it doesn't check any other servers to make sure.
What you would need to do if your local resolvers are garbage is provide one or more alternative servers that do the same job and use those. Basically: reimplement the slow servers except... not slow.
You will need a list of all domains that belong to your intranet, and the corresponding authoritative nameserver set that serves each one. The problem is that your IT department may not furnish you with this list and it may receive additions and changes over time, so you will need to constantly maintain it up to date. Your IT department maintains this list in the resolvers that it provides, but they may not support a third party maintaining another copy in their own resolver.
You will need a caching DNS server such as bin or unbound. I would normally recommend unbound for this, but if you want to run the software on your local machine you will find bind easier because it comes preinstalled on MacOS. If you run it on your local machine then you can configure 127.0.0.1 as your resolver.
Set up each of the intranet domains as a "forward" zone, and set the forwarders to the authoritative nameservers for that domain. For both BIND and Unbound, you can use mostly the default config, with additions of one forward zone for each intranet domain. For BIND:
zone "yourdomain" {
type forward;
forwarders ip.add.ress ip.add.ress;
}
For unbound:
forward-zone:
name: "yourdomain"
forward-addr: ip.add.ress
forward-addr: ip.add.ress
