Is this a harbinger for the times to come or just an Apple Idiosyncracy.

June 4th 2006 : Apple announces shutting down it's India support and development centre.

June 6'th 2006:  IBM has announced plans to invest nearly $6bn (£3.2bn) in India over three years on the back of strong growth in business outsourcing.

Confused ?  So am I.  For one Apple decided to junk India for support and development. "Support" meaning call centres and the like. This segment is at the lowest end in terms of skill and cost is simply the biggest decision maker. Other Asian nations have not been sleeping when it comes to call centres and some of these countries have lower cost levels than India. Philippines is known for better quality.

Now, coming to the "development" part, the cost structure for offshoring low end work (I would be surprised if Apple outsourced core product design and development) would depend roughly on the number of entry/mid level programmers availaible and of course costs like Infrastructure (real estate+telecom+…).  India does not have too many entry/mid level developers focussing on the Mac platform. Of course, you can always hire and train, but why bother paying 30K rupees to a freshman from India when you can get similar skills in Philippines or Thailand at a lower cost ? Also countries like China have definite infrastrutural cost advantages over India. The real estate boom is not helping either.

But all these factors apply to IBM as well. But the crucial difference is that IBM entered India very early and built a strong foundation when costs were much more attractive (both in Infrastructural  and people) than they are now and given the scale and scope of current India operations it makes sense to invest further. It is very difficult to build from scratch these capabilities in another asian country however cheaper the option.

               To sum up, this is definitely a wake up call for the low end of the BPO segment. There are more attractive value points outside India! The solution: Put some control into the mindless BPO growth we are currently enjoying and start focussing on quality instead. Focus on building a reputation for quality while we continue to grow. The software development folks need not worry yet. The entrenched gaints will stay and invest. India has many advantages (cultural, project management, domain and consulting capabilities) over other asian competition and these are competencies that cannot be acquired overnight. However, companies looking to enter India for the first time might have a hard time deciding.

How will Google spreadheets impact MS Excel ? Is this the beginning of the end or will this add to the roster list of applications MS has devoured ?

The view from the market :
Corporate-high end : Corporate users who use the more sophisticated features of excel. Say the risk management department of a bank with plenty of spreadsheets with confidential data being analyzed and presented graphically. This segment demands a mature and stable product with all the bells and whistles thrown in. These guys have no issues throwing money as long as they get the features. Switching costs due to network effects are maximum for this segment owing to high level of inter corporate communications. Even with intensive development (see technology viewpoint below), GS will have a seriously tough time winning over this most crucial and lucrative segment.
Corporate low end: Really small companies especially in third world countries with miniscule IT budgets. Usage of excel is mostly relegated to the basics with the odd macro thrown in.The sooner GS can incorporate some sort of basic macro support (even if not compatible with excel macros) the sooner this segement will sway.
Home market : Grocery lists, mom and pop accounting and the like rule this market. Technically I see very few swiching costs here. Commerically GS will be attractive. Which home user wants to spend money to get a spreadsheet to add and subtract. But the million dollar question is : How do you get a forty year old, change averse housewife to switch to a web based equivalent when she's really happy with an outdated version of Excel ?
School and college market : A potential goldmine for GS, but needs a full suite rather than just a speadsheet app to tap. This segment is eager to explore, nascent and has not been overexposed to the MS Office suite. Which college professor would not like to use the cool chat feature in GS to connect to his students who are thousands of miles away ?  

The technology viewpoint :
Utlimately, the strength of any application is limited by the strengths and weaknesses of the platform it runs on.
The Windows Desktop: Hate it if you must, but this is a platform that has matured over the last 25+ years has all the infrastructural nuts and bolts needed. Be it User experience or richness of the API this is a proven warrior. Feature for feature this is an impossible battle to win.
Browser : A ten year old boy with special gifts but still to grow up to fill his big shoes. This is the biggest liability and given the fact that MS controls the bulk of the browser market, I see this as a killer weapon for MS. Even with all the best of innovation from Google, the limitations of the browser would ultimately circumscribe product capabilities. The trick is to leverage the strengths of the browser like easier collaboration, and use this to capture new usages that MS Excel cannot replicate easily.  
What Google should do next:
Add macro support if it doesn't exist already.

Develop a full suite to rival MS office. I see this reducing switching costs atleast to some extent. A standalone excel clone just does not cut it.

Mimic MS office shamelessly. Make it easier for the home market to switch.

Since competing on a feature for feature basis with excel is impossible, find new usage patterns for spreasheets that leverage the unique strengths of the web.

Integrate GS into the search engine. The search engine remains Google's biggest weapon. Integrating GS (I don't know how! Maybe some sort of search results analysis tool ? ) would mean millions of users overnight.Focus on capturing the low end excel market that is price sensitive.                    

This company never ceases to amaze me. Check out Google Trends (GT), yet another jinn from the Google labs magic lamp. Here are some ways I think GT can be more than an addictive time pass. :-)

Super duper market sensor: Be it the launch of a new car, or buzz about a Tom Cruise movie release, this can be an early predictor of market success. This is especially true of high end consumer goods where the target market is internet savvy and uses the web (by default Google :-)) as the primary means of ferreting out information. Google might want to introduce a premium service that allows people to search commerically valuable terms for a fee.
Plug in for CRM products : I am no CRM expert, but intuitively, with some application level plumbing to add value to the raw, real time feedback on market trends provided by GT this could potentially add a real time edge to CRM. A neat SOA service implementation could get the Siebels of the world humming with interest.
Integrate GT with Google mail : Make a Google account mandatory for using GT. This merges the account information in mail with the searches the person makes, making the trending data more meaningful for marketers. This can be sold for a premium. Eg. How many kids aged between 9 and 18 searched for "X Box" and how many searched for "Playstation".
Extend Google search to enrich trending data : Log the website clicked on after a search result. A little AJAX behind the scenes could do the trick. Let's say someone searched for cars and got both www.edmunds.com and www.cars.com as results. How many went to cars.com and how many to edmunds.com ? Which search keyword resulted in maximum hits to cars.com ?
Expose an API and charge for use : Allow people to freely add value to the raw trending data and charge for API calls.

Developers are the heart of any project. So, what are the key aspects that one needs to keep in mind while hiring developers?

Define target team composition:
                 Team composition does not merely mean technical skills composition ( eg .five JSP developers, two EJB developers, one DBA), but also includes the larger 'capability composition' of the team. A good team in my experience could have the following capability composition-

·         Killers- 5%. Killers typically are very intelligent, driven, ambitious and love being in the limelight. You will find them working weekends learning new skills. Although tempting, do not try to saturate the team with killers. Too many killers create 'people' issues. Most medium sized teams need one or atmost two killers. De-risking tip: If your estimation is aggressive make sure you have a couple of killers on hand!

·         Stars- 20% Stars are potential killers, but lack the drive needed to be one. Talented but easy going, one typically hears them say 'I have finished my work, so please let me go at 5:30 itself'.

·         Backbones-60% Aspiring and committed, with good attitudes, backbones stand ready to make sacrifices in order to meet set expectations. They typically prefer semi-routine work with well defined tasks. They are crucial when a project is what I would call the 'slog overs' stage.

·         Greenhorns-15% Fresh or relatively fresh, they bring youthful enthusiasm and energy to the team. They are your talent bed of future stars, backbones and killers.
          Depending on project complexity, deliverable aggressiveness and cost imperatives one would choose an appropriate team composition. Defining the same upfront ensures balance and consistency with respect to other project parameters.

Define your target 'hard' skills wishlist
     You could either be hiring for an existing project, or creating a buffer for future requirements. Depending on your immediate need and projected future needs, prepare a target 'hard' skill list in descending order of importance. This could look like:

SKILL                                                                            SKILL LEVEL [1-10]
 
Session ejb- design, development and deployment.     8
 
ANT build scripting- development, execution and
maintenance.                                                         5
 
JSP-design and development.                                   3
 
CMM-5 quality procedures.                                       2
 
 
Prepare an interview plan: Set expectations
     Identify technical recruiters and make sure there is consensus with respect to skill levels needed for individual roles and what these skill levels mean in practical terms. e.g An EJB developer with skill level '7' would, apart from basics, be able to solve issues involving transaction management and would understand exception handling in the context of transactional failures. Driving consensus helps ensure consistency across interviewers. I have seen interviewers providing vastly different ratings for the same candidate while testing similar skill areas.
     Partition responsibilities for assessing specific skills to different interviewers. It makes little sense to have three rounds of technical interviews, with all the interviewers focussing on exactely the same area.

Identify job specific soft skills needed:
     Every software professional is expected to have good interpersonal and communication skills. Thanks for the news eh ? Well, one needs to move away from these cliches and get down to specifics. eg. A build engineer needs lots of patience, good coordination ability and the willingness to put in long hours. Make sure your panel tests these aspects.

Seek to identify strengths not weaknesses:
     The goal of an interview is to find out what the candidate knows, not what he does'nt know. Avoid out of the blue questions like 'Can you tell me something about Aspect oriented programming ?'. Such tactics may be used to shock a candidate with an attitude problem, but are of little use from a regular evaluation perspective.

Test ancillaries in addition to core skills:
      A 'web tier' developer that does not know javascript is not a 'web tier' developer. I have seen developers spending inordinate amounts of time on seemingly 'peripheral' tasks like HTML/javascript and SQL queries. Make sure you test candidates on these little 'extras' that usually get taken for granted.

Test application ability in addition to concepts
              Most interviewers merely test concepts. Use mini case studies to test the ability of the candidate to apply the concepts. As far as possible, relate your questions to the candidate's project profile.

Make sure you test work ethic!
     I have seen a great deal of time getting wasted because of lack of adherence to process, poor time management and inefficient inter-developer coordination. Ask the candidate to take you through a typical work day in detail. Ideally relate this to a case study.

Do not be biased towards referrals
     There could be a tendency to apply lower standards for employee referred candidates. People refer candidates to get the referral bonus not to ensure the best possible fit. Apply the same standards to one and all.

While hiring freshers(<1 year) go for talent
      Freshers are sometimes subjected to 'computer sciency' tests and programming languages tests. In my experience, recruiting from premier institutes through IQ tests would be a better choice. I have seen smart freshers with good attitudes scaling up in weeks.

As Frederick P. Brooks articulates in the 'The Mythical Man Month' : The difference between an average developer and a great one is an order of magnitude. Happy hiring!