Morgan Stanley

• Okay salary.
• Nice offices.
• Pockets of IT excellence, usually where someone technical has been promoted to MD level by accident.

• Absolutely atrocious development environment. Business units are commonly on better spec PCs for using Excel or Outlook than developers get for using heavyweight IDEs.
• Windows XP.
• 4GB RAM. That's right, 4. On a developer 'workstation', a.k.a the cheapest Dell box money can buy.
• Everything is completely locked down, including developers' own PCs. The simplest tasks become an almighty chore involving multiple layers of non-value adding bureaucracy.
• IT management is completely divorced from modern software engineering culture. MDs are typically smart, political, completely non-technical, and utterly unequipped to actively lead technical organizations.
• Apps are typically supported by offshored/outsourced vendor teams of poorly trained staff. Devs, intended to be the last line of defense, end up being the first and only port of call for most issues.
• High attrition rate for genuinely talented developers; good developers come in, try to change things, get frustrated when they can't, then move on.
• If your manager is non-technical, it is a nightmare trying to get some decent tools to do your job. "Why do you need a ReSharper license? Jim does just fine without it."
• MS has no idea what motivates developers. Everything revolves around comp and the bestowing of shiny titles.
• Many MS developers have forgotten what is meant to motivate developers. Everything revolves around comp and the bestowing of shiny titles.

Start looking at companies outside the industry to see how they do things. MS is not 'special'. Technology, and the process of running technology, has moved on enormously. Note, Goldman Sachs is not a role model in this regard.

Modern development practices are light years ahead of what MS currently uses, and have a lot to say about how to introduce change into production systems at a reasonable pace and at the minimum of risk. MS senior IT management do not understand how you actually minimize change risk. They simply believe that documentation equals proof of testing, and that copious blackouts and sign-off from non-experts lead to system stability.

Time spent doing TCMs and testing documentation and attending change meetings where non-technical management pretends to know what you're talking about would be far, far more productively spent writing good automated tests.

The time spent trying to document that due diligence has occurred takes too much time away from performing that due diligence itself. An audit trail is necessary, but MS goes far, far beyond this.