IBM

Working at the symbol of corporate stability can be great if that's what you're looking for.

Getting in at IBM and making a few connections will probably net you some decent job security.

If you're a developer who wants to do sales and services instead of development, you can find a home at IBM.

Where to start?

If you're a developer, IBM enterprise software is not a place I would go to feel valued. Maybe the Watson team has it better, but the enterprise division is very sales, services, and metrics-based.

As a developer, you are undervalued and often burdened with fulfilling promises made by people who will make a commission on your fulfillment. That's pretty much the best-case scenario.

I mentioned metrics because IBM uses a bell-curve system. Meaning someone has to be the best and someone has to get a trash rating that can threaten their chance at raises or even employment.

Speaking of raises, you won't really get any unless you leave and come back. The metrics are black-box, and no matter how many times the team tried to pin down specifics, management gave us vague responses or tried to placate us.

The way banding works is supposed to get you more compensation but ends up as a way to give lateral promotions with increases in responsibilities without increases in compensation.

You'll often be compelled to use tools not because it's the best solution to your problem, but because IBM eats its own dog food. It doesn't matter whether this tool actually has the features you use; someone who drank enough Kool-Aid (or who is under the thumb of someone who has) will tell you to use the IBM product. This can be annoying for developers who want to get things done instead of playing politics.

As a developer, you are encouraged to draft and submit software patents because IBM is a participant in the current patent wars like other major tech companies. Think about that what you will.

In Sales/Services, the focus seems more on getting IBM its money than actually providing quality service to the customer. Things like being encouraged to spend hours within certain time periods, without too much concern for whether the customer actually needed services.

If you're comfortable with that, there's probably a very lucrative future in enterprise sales for you.

Metrics are demoralizing, even more so when they are black-box. When it's a bell curve, it's like you want intra-team conflict. Don't infantilize developers. If your devs are consistently vocalizing issues, maybe they should be addressed instead of treating developers like a static, unfeeling resource that will convert misery into code.