One possible approach, in settings where a browser is being deployed as part of a consistent desktop, is to decouple the browser as much as possible from any desktop it's installed on. Remote virtualization or self-contained app deployments (e.g., PortableApps) are two ways to accomplish this. You can then upgrade the browser independent of anything else on the system, with as few external dependencies as possible.
This approach is particularly recommended if you have chosen a browser that has a fairly aggressive upgrade cycle (e.g., Chrome or Firefox); the upgrades can be rolled out by the IT department rather than the browser maker.
For people developing public-facing apps: Wait until a given feature is uniformly supported by the major browser share using your application, then add it. Derive actual usage statistics from your site logs; don't rely exclusively on user feedback to decide which browsers to support, as the loudest voices don't always represent the lion's share of actual users.
Whenever you can, keep development on HTML5 discrete from development for HTML4 and XHTML. The latter two are stable, known quantities. HTML5, on the other hand, has a lot of elements that are still protean, and therefore you shouldn't formally add support for any of those elements until, one, the majority of browsers have it and, two, the features in question are implemented as consistently as possible across browsers.
Keep in mind that the story is going to be different for product makers rather than rank-and-file IT supporters. In this case, we actually have it easier in the long run than commercial product developers, since IT departments typically don't compete in the open marketplace, but rather concentrate on serving our users. "Do you want to be the only tablet maker that doesn't support WebSockets or IndexDB when you're doing everything you can to attract developers to your platform, which is one choice among five?" says Hammond. "Probably not."
Where does this all leave us, savvy IT people watching the Titans (W3C and WHATWG) tussle over the future of the Web?
There's no denying the evolution of HTML5 is a mess but also unavoidable at this point -- and on the other side of that mess is a whole new kind of Web. "We're in a period of short-term pain in order to get long-term gain," says Hammond. "It's platform fragmentation, which is driving browser fragmentation, which is driving innovation. As a result, the level of support for standards and proposed standards is all over the place."
Once those standards are adopted, things should settle down, Hammond predicts. "We'll see greater pressure from all to support them."
In the meantime, hold on tight and enjoy the ride. "Evolution is messy during periods of punctuated equilibrium. That's the kind of era we're in right now."