it's not actually $370mil that gets spent on labor.

step 1: pull out overhead and profit. i'll be generous and estimate at 150% (this is probably *way* low). now you're down to 987 engineers for a year @ 150k per engineer per year
step 2: pull out irrelevant direct charges (project management, accounting, etc.). assuming this explains 10% of billing (again, quite generous), you're now left with 888 engineers.
etc.

it's pretty simple bud: if you think that databases or web development qualifies as a specialized comp. sci. area then you have either been mislead or are plain ignorant. more importantly, you should know that grad school is, generally, an extremely bad plan unless you're the peculiar kind of person that is really serious about your particular field. grad school will be _HELL_ if you don't love what you're doing. and to be honest, i don't think you love what you're doing.

i'd suggest you start exploring other options, because i'm afraid you've already lost this battle.

i'd wager that you suffer from some combination of:

1) confusing being a bastard with having a spine. user can't follow policy? kick them off the network. they want back on? get their boss to put it in writing and then sandbox the snot out of them.
2) being hamstrung by management (not backing you in disputes over policy, not giving you adequate resources)
3) being hamstrung by yourself (not proactively seeking out management's help when you need someone to back you on policy, give you resources; not hiring or otherwise outsourcing responsibility for desktop maintenance)
4) failure to manage expectations across the board (likely due to a failure to communicate)

if you suffer from #2, i'm afraid you're done at your current place of employment, same for #4. and while it is possible that #1 and #3, with time and the appropriate resources + backing from management, can be fixed, i wouldn't hold my breath.

throughout the course of an average day, i use:

1) a broad sampling from electrical engineering (specifically robust approaches to controls, detection + estimation, signal processing)
2) a broad sampling from software engineering
3) a broad sampling from computer engineering (specifically: what's going on at a hardware level as code executes, dma/rdma/misc. other for transfer to main memory, misc. busses)
4) a broad sampling from systems engineering (primarily approaches to testing, end-to-end performance analysis, root-cause analysis)
5) precisely enough mechanical engineering to explain why nobody should trust me with hardware

... let me tell you that going from a company of 30 to a company of 140,030 is still quite a shock, and the purchase went through nearly 18 months ago.

if you decide to go down this path, make sure that:
1) you have definite set dates for _EVERY_ part of the transition, _especially_ for 401(k)s, health insurance, etc. these dates must be part of the terms of the contract with seriously stiff penalties.
2) take a long, hard look at all your groups' bumps and warts. if you're like my group, you have several excellent tech leads and no project managers. make sure that your potential purchaser can either fix or drastically improve all of your failings.

there's a lot more, but for me the biggest items are those 2.

so you're in your 30's, depressed, and trying to figure out what you did with the last 10-15 years of your life?

(i'm not sure what it means that i'm 28 and going through the same thing...)

the obvious reason:
actually getting to take off fridays off is an iffy proposition, at least in my organization. i objected to it when it was implemented nearly 18 months ago as a sneaky, underhanded way to squeeze extra unpaid overtime out of employees and i feel even more strongly about that now than i did back then. i haven't had an off friday for the past 3 months and it seems increasingly unlikely that i'm going to get to take those fridays off until i get through a march delivery. obviously, your mileage will vary; however, unless your organization is serious about off fridays being sacred (mine, unfortunately, is not --- they expect you to be in the office on those fridays if there's even the slightest business need), expect to lose them quite frequently.

the non-obvious reasons:
1) trying to make up sick leave / personal absence gets to be really challenging. i find the incremental effort from 8 to 9 hours in a day not that bad, but 9 to 10 and beyond is really, really difficult (at least if my goal is to be actually productive as opposed to a warm body).

2) scheduling with clients / customers / team mates that are not on 9/80 gets to be more complicated, especially if you have multiple stakeholders whose off fridays are out of phase.

3) receiving shipments of parts / software / hardware / etc. on time can be difficult unless you have a dedicated receiving department working throughout the week.

4) depending on how you do time cards (assuming you do), correctly transcribing time can be a challenge. (you need two fridays per week)