As in, the culture of the company.
I'm not a software engineer any more, I'm an electrical engineer (I worked as a coder while I was in college). In particular, I'm an analog (and sometime digital) circuit designer. I learned nothing about business practices, Six Sigma, et al in school (S.B. and M.Eng in EE and CS from MIT). Why? Because I spent all of my time taking real EE/CS classes. When I got a job in the industry, _then_ I started learning all the practical stuff I hadn't had time for in school. Why do EE companies do it this way? Because the cost of failure is so high: we spend a million dollars taping out a chip and it doesn't work because I decided to cowboy my circuit and we're out our money.
Many software companies don't see such large quantization steps in their failure cost: we lost a week here or there because the newbie's coding practices don't mesh with the rest of the team, but management is just watching their Gantt chart and we'll push on them to hit their milestone on time anyway; fuck 'em, they're just code monkeys anyway.
See the difference? The assumption that designing bad software has a small cost (mostly because it's deferred until much later when it's discovered, plus the assumption that any bug that's discovered is easy to fix) is built into the management style of the software company; the assumption that failure is extremely costly and the necessary culture of rigor are built into the management style of the EE company (well, not all EE companies... but there are shitty companies in every industry).
So why not teach EE students all about Six Sigma et cetera? Well... when? I took 5 or 6 classes a term (4 is average at MIT) and still took 6 years to do my degrees. There's just too much to cover in EE/CS to get it done---and yet there's no "cowboy issue" in my industry, as far as I can tell.
So is there really less to learn in Software Engineering? In other words, is this just a fundamental difference between EE/CS and SE? I say absolutely not. There's an incredible amount of material to cover in SE without getting into business practices: first, pretty much any CS topic is fair game for software engineering (yes, I know they're not quite the same thing). Then there are more EE-like subjects that most SE people don't get, but should: signal processing, feedback systems (yes, they exist in software just as in hardware, and they can be analyzed with the same fundamental tools). There's plenty of math to learn: discrete math, algorithms, set/group/category theory, et cetera. Then there are classes on system architecture, complexity management, and a million other really hard problems. Given all of this, and only four years to fit it all, any time spent on business practices and Six Sigma is an unmitigated waste of time. It can be learned faster and better on the job---after all, you may as well learn the business practices at the company you work for, while actually doing useful work.
Far from producing "unemployable" grads, a program with no focus at all on "business practices" will turn out coders who have wrung from college everything that ought to be learned in an academic environment, and who are ready to be apprenticed to an experienced mentor who will teach them the practical details that are dirt simple to understand.
In other words, let Vineet Nayar's coders waste their time learning about bullshit Business Practices instead of expanding their minds by learning something difficult and interesting. You need code monkeys to do shit work anyway. There's always a lowest common denominator somewhere.
Or how about this: do you think when you go interview at Google they're more likely to ask you about Six Sigma, or about problems arising in the design of a secure/anonymous/reliable distributed filesystem?