Tech Company Caste Systems

From Businessweek

The suits inside Google don't fare much better than the outside pros. Several current and former insiders say there's a caste system, in which business types are second-class citizens to Google's valued code jockeys. They argue that it could prove to be a big challenge in the future as Google seeks to maintain its growth. They deem the corporate development team as underpowered in the company, with engineers and product managers tending to carry more clout than salesmen and dealmakers.

So a 'caste system' in which 'business types' are second class hurts?

How about the 'caste system' in place in most companies where the suits are on top? I guess that is the 'natural order of things' ? :-)

The outlines of the 'caste system' in place in most 'India Development Centres' can be deduced by examining one expense item - tickets for international flights. Most 'business types' fly first or business class while the 'India Developer Assets' are packed into Economy Class. To see something even more interesting, examine what kind of tickets are bought for Caucasians vs Indians.

Do I mind any of this? Not really. Any game is played in a particular fashion because all players agree to play it that way. It is upto people playing the game to make sure the rules are fair.

What bothers me is the intellectual dishonesty in the implication that "business types on top" is natural but "techs on top" is not. I would have thought that the effectiveness of any company's internal structure would be judged by how successful it is. And by that metric Google is outstandingly successful. So may be the 'new caste system' is 'valid' after all?

I wonder if anyone is working for a "casteless" company? What would such a beast look like?

Update: Slashdot has picked up the businessweek story

I Love China!!!!

From mini-msft

"... Shanghai: the same week various posts come out discussing working with Microsoft engineers in China, also noted by Dare, I took a moment to do a deep dive understanding how things are going over there and what kind of work is getting done. Seems as though most people are very happy with the high quality, hard-work, and ability to deal with Microsoft-Redmond's capricious rearchitecture du jour coming out of China. I haven't heard much in the way of complaints at all, as compared to working with Hyderabad. Microsoft India had best watch out - you guys might get outsourced to China, lending a whole new modern usage to Shanghaied. ..."

Go China go!!!!!!

Conversations and Deeper Issues

Brian Marick writes about Story Cards which contain only the name of the story, thus encouraging developers to talk to the customer before writing code.

This resonates with me for two reasons.

1. I have seen "agile" projects start out by writing story titles on story cards, then add "supplementary" MS Word documents, then write even more bloated documents etc, and then people start saying "but that is not in the document" ,"let us update the document" etc.
2. These days, I am very leery of what I see as an artificial split between "analyst" and "developer".

Don't get me wrong. There are people who know particular domains well and if you are lucky to have such people on board, they are worth their weight in gold. But, and this is very important, an analyst is NOT the same thing as a domain expert. The set of genuine domain experts and the set of so called "business analysts" rarely intersect.

What turns me off is the blurring of the distinction between a genuine expert and someone who comes in and "models" the domain. The idea that someone can become an analyst just because he has an MBA and then spend his time writing ever more baroque MS Word documents/Excel sheets etc, with no real responsibility for the code is ridiculous. The person who analyses the domain and the person who writes the code should be the same. If a software "engineer" can't do this he has no business coding a solution for that domain.

Now, a lot of developers don't care about how business works. This is often because the domains dealt with in "enterprise" software (insurance, leasing) etc, particulary the dreary parts that wash up on the shores of India, are desperately boring to a technically focussed developer and so he refuses to look more deeply into the domain and then pays the price by having to work off an endless stream of word documents.

The easy way out for developers is to work only with domains/clients they are interested in, but in these days of "distributed agile with optimized resourcing " (english translation == outsourcing half baked projects to the cheapest vendor with over staffed, over managed teams), that is perhaps easier to say than do.

I personally find some domains interesting and find innovation and effectiveness in economics just as fascinating as innovation and effectiveness in programming and, these days, work only on projects that interest me. On the other hand I don't have the security blanket of a 9 to 5 "offshore cheap software 'engineer' " type job. Life is more refreshing this way. :-)

Update:- Bill Caputo makes the "Analysis as a separate activity from programming is meaningless" point (in a slightly different context) brilliantly on his blog.

DabbleDb Dazzles

DabbleDb "combines the best of group spreadsheets, custom databases, and intranet web applications into a new way to manage and share your information online". It has smalltalk(Squeak ? ) and Seaside on the backend and is simply mindblowing. Watch the dabbledb movie(warning 113 Mb .mov file) if you haven't already.