Well, not really, but that'll come later....
What do I mean by that? Well, first off, if you have a small company, you should probably consider getting a new sysadmin after about two years. If you have a "team" of sysadmins, then it means that (aside from cross-training for vacation and sick coverage) you should keep them focused on certain aspects of the work, and try to steer them away from other aspects.
I've seen this sort of situation time and again: SysAdmin is overworked. He picks and chooses which things in the infrastructure he can "fix". It's normally hot "hard" to fix any of the things he needs to fix, but he can only get to certain things, so some things he fixes, and other things he grudgingly learns to live with in their slightly misshapen state.
New sysadmins, though, never put up with that. A new sysadmin comes in and, again, from my experience, spends the first 30-60 days "cleaning up" what his predecessor had learned to live with. They're given the slack, time-wise, from their superiors, because that cleaning up process is often an excellent way to get to know the systems, etc.
In other words, lots of really good nitty-gritty work gets done in the first couple months of an SA's employment... after about six months or so, if the problem was pre-existing to their start date, and there's a workaround in place, it's pretty unlikely that they'll actually get the time to fix it.
Take my experience at $JOB->prev()... in the first couple months I was there, I kicked serious ass changing all sorts of shit. I pointed out bunches of things that also needed to get changed, but then as time wore on, the likelihood of those getting changed slowly diminished. I had a "wish list" of "stuff I wish I had time to get to"... when my replacement started, after I left, it seemed like everything on my wish list got done in short order, probably for the reasons I outlined above.
Obviously, it's not really in my best interest to suggest firing sysadmins every couple years, and in reality, that's not really the best answer. I think it's probably a good idea for SAs and their employers to consider the reality of this, though, because I've seen it in companies relatively small and relatively large.
One answer might be for the employer to commit to a schedule that includes "[NN] days a month are not about current-projects at all, but about handling wish-list items" ... days when "current projects" no matter how important are set aside to handle the equally important infrastructure issues which need to be taken care of. If you schedule them on a set schedule (say, "the 10th through the 15th of the month, each month") then the ongoing current projects would know that they don't have any SysAdmin resources during that time period and can project their timelines accordingly.
This is important stuff, because it doesn't matter how spiffy the current project is, if it's built on a house of cards that's not getting the attention it needs, then it's not going to be all that stable, and you're not going to be happy with it anyway.
This is also the period when the sysadmin establishes his reputation as a BOFH. He doesn't know the Policies and Procedures, and has no qualms about breaking kneecaps.