Tuesday, December 04, 2007

Why corporate IT means something

Over on Joel on Software there is a post about his talk at Yale where he warns people not to go into "in-house" corporate development because its soul suckingly bad. Why?
Number one. You never get to do things the right way. You always have to do things the expedient way. It costs so much money to hire these programmers—typically a company like Accenture or IBM would charge $300 an hour for the services of some recent Yale PoliSci grad who took a 6 week course in dot net programming, and who is earning $47,000 a year and hoping that it’ll provide enough experience to get into business school—anyway, it costs so much to hire these programmers that you’re not going to allowed to build things with Ruby on Rails no matter how cool Ruby is and no matter how spiffy the Ajax is going to be.

"No matter how cool Ruby is", "Spiffy"?!?! this just about sums up why vendors don't understand their customers. Now most companies I've been in are doing just those sorts of things and are doing it when it makes sense and the people doing this tend to the leading IT lights of those companies. Having worked with lots of product companies as well I can safely say there are legions of developers in those companies who certainly don't have the ability to choose a new programming lanaguage and who are never going to lay their hands on Ajax. So maybe the issue isn't corporate development but the sort of development that Joel did when he was in a corporate.
You’re going into Visual Studio, you’re going to click on the wizard, you’re going to drag the little Grid control onto the page, you’re going to hook it up to the database, and presto, you’re done. It’s good enough.

Now apart from the last bit (which after all is just smart engineering over turd polishing) this does sound frighteningly like average development. There is a bit around never having time to do quality and refactor to your hearts content but that really does miss the point as I've never met a good developer who ever thought what they had produced couldn't be improved.
Now, at a product company, for example, if you’re a software developer working on a software product or even an online product like Google or Facebook, the better you make the product, the better it sells.

Ahh I know Joel is talking to students here, but is lying really the option? The best software sells the most? Only if you define best as sells the most. The history of software is littered with examples where better software was ignored for inferior fare. Hell in IT it often seems that we deliberately go for the worst option out of some sort of perversion (C v Ada syntax for instance). The implication here is that product software is the best quality. My experience has always been I've never met a piece of commercial software I couldn't break. Things like having a messaging product, Java VM, Operating system and hardware all from one vendor and it wouldn't work at all not as in a slight issue but as in they could never have tested it because it didn't work in any way whatsoever. Things like vendors shipping software products without decent test tools being available. Things like evil class loader work arounds due to vendor stupidity. Things like Rational XDE which came exactly from people "optimising" (the new stuff is soooo much better and started from a different place IMO).

Corporate in-house software on the other hand is designed to do a specific purpose and when it does that thing it works. There are less edge cases to worry about and you have a defined reason for doing it. Now there is indeed lots of crappy inhouse software in the same way as there is lots of crappy vendor software the question should be really about comparing the best of corporate IT with the best of vendor IT. Now excluding the "found your own IT company" which is always the best if you can pull it off the question is which is better to work for?

Now the problem is that Joel clearly worked at a crappy job in the crappy part of an corporate company. He complains about the pay and conditions and seems to think that software companies always have the best perks. This isn't true for several reasons
  1. Societal balance - by which I mean women. Tech companies are male domains and the male/female ratio is normally completely dreadful. If you work in a corporate then the odds are this will be much more balanced. This makes for a better social life
  2. HQs of corporates are better than tech companies. I've been to lots of the supposed "best" tech company offices and the HQ of a pharma, bank, oil company, airline or even traditional manufacturing company tend to be miles better. Now only the best in IT get to be at HQ, but were you planning on being average?
  3. Flying - The policies at most vendors appear to be "coach unless a VP" whereas in corporates it tends to be "we are in business so we fly in business".
So a clear win for the corporates on that one. The next up is the worry that you can't become the CEO if you work in a corporate in IT. Now this is pretty fair, but you can become the CIO and be responsible for a multi-billion dollar budget which doesn't seem too bad and given the choice between that an CEO of a small product company then I have to say I'm with the CIO of a large corporate. Lets be generous here and say that the vendors win this one.

Next up Joel talks us through his hell hole job at Viacom. It really does seem that he was a completely unempowered programmer and this is a crap job at any company, where he makes the mistake is thinking that these people don't exist in vendors. They absolutely do and they have many of the same issues. Field sales engineers are good examples, often very talented but having to put up with whatever is thrown at them from the mothership. The point here isn't corporate v vendor but empowered v munchkin, and you don't want to be a munchkin.

So the question in terms of what is best is what sort of impact can a good and empowered person have on a corporate or a vendor? In this day and age I'd say that the impacts are pretty similar. The key is finding what matters. With a vendor company you could take them into a new market and you can do the same in a corporate, with a vendor you could create a competitive advantage over the field, something you could do at a corporate. The point is that these days when decent companies look at changing the game they make sure IT is in that decision. Its a good place to be.

The real reason to me that corporate IT is a great place to work, if you are good and have good communication skills, is that you can actually see what you do make a difference. I'm incredibly proud that I wrote software that means air traffic controllers can do their jobs and be alerted quickly to any collision risks. Now sure the folks who wrote the graphics library and the OS, the software vendors, had a part in it but it was me who brought it together and gave it purpose.

Corporate IT is the point of vendor IT. Vendor IT is there to make money and its the corporates that it predominately gets this from. This means that while as a vendor you can say "look at our shiny app server" or "look at my bug tracker" the only point to your software is if some corporate people turn it into reality. Thus its corporate IT where the real achievement is. Software Vendors provide the bricks and mortar, they quarry the stone and provide you with the rough hewn pieces for you to carve and give purpose to.

The key in corporate IT is to be one of two things. Firstly you could be very talented and looking at real edge challenges (for instance forecasting in retail & supply chain) where you'll have to push the boundaries of technology to the edge in order to stay ahead of the game. Secondly you could be the person tasked with sculpting a result out of all the raw materials of people and the software the vendors provide to create a new solution to a business problem. This is where, IMO, the greatest challenges and talents in IT are. People who can understand technology, people and process and bring them together. Making people think in different ways, using technology in ways the vendors hadn't expected and doing this all successfully to a properly formulated business case. That takes talent.

The majority of the hardest technical challenges I see in IT are in the corporate space. There are of course challenges in the vendor space, especially where the sale is direct to the customer (but is Amazon really IT company or a next generation retailer?) but the challenges in the corporate space are just as large and hairy and often just a lucrative. The hardest challenge in IT however is the same as it has always been, how to take multiple technologies and large numbers of people and deliver a system, changing the business as you do so to make the adoption of the system successful. These are the people who give a point to all of IT and who can point to things in the real world and say "I made that happen".

So vendor or corporate? If you are talented and have good communication skills I'd say go for the corporate. Especially when it comes to the Christmas party.

Technorati Tags: ,

2 comments:

Noons said...

"how to take multiple technologies and large numbers of people and deliver a system, changing the business as you do so to make the adoption of the system successful. These are the people who give a point to all of IT and who can point to things in the real world and say "I made that happen"."



Steve: that is soooo right!...

Anonymous said...

Not sure about corporate development being challenging. Its all appllication servers, portals and web services.

I started off at vendors where the products were cool but all I did was support.

Then I went to corporate where the work was unchallenging, using application servers and never really being challenged. Then I consulted for corporate which was even worse.

Then I went into investment banking where I was finally got to do challenging work. Why because I had to work in real time technologies where coding involved solving multithreaded prolems and I got to see pretty women everywhere.