Giving back

There is a disquieting story in a recent Indian Express, about how seats in Engineering colleges are being reduced for lack of faculty to teach them.

This brings up two issues in my mind: Quality and Quantity. Of the faculty, of course.

Traditionally, Industry and Academics in India tend to look down on each other. Your average professor or Ph.D student would scorn the idea of actually doing the work which an engineer in a company would do, and the engineer would think the research student is only doing research because he couldn't get a job anywhere. Both stereotypes are partially true, in fact. But it didn't matter, because the demand for teaching faculty in the colleges was much less than employable engineers in industry. And the subjects which the faculty taught moved slowly enough that it was possible to wait till the next editions of textbooks came out and were incorporated into syllabi.

None of these things are true for software in India. Actually, none of those things are true for any engineering discipline in, say, the US, but research and innovation was such a low priority in Indian industry that it used to be all right. But for software, the field is intrinsically fast-moving, and besides we have this sense of really competing with the world here. Hence the interaction between academia and industry is more in this area. In order to sustain the growing demand for software folks, more and more teachers are required - teachers who know what the latest technologies are, who know the hot research topics and the newest theoretic trends.

And this is where, for some time now, the Quality issue of college faculty comes in. From personal experience I can say that the vast majority of people who teach computer science are not up to date with what is going on in the industry. The feeling of inferiority persists - people who can gets jobs programming take them, the ones that are left, teach, feeling they have no other option. I don't include professors in the absolute top institutes - IITs and their sort - but the average college which produces the bulk of the programmers for the IT companies. Since the teachers are not up to date, neither are the students. I remember a particularly inept Databases teacher who brought printouts of Oracle command manuals and dictated them to us as notes. All of our class ultimately learnt databases by ourselves, and then did some fast learning when we were recruited.

If our current crop of teachers is this bad, how are we going to get more of even the same quality, if we want to produce more engineers? Something tells me we're already dredging the bottom here.

A good friend of mine, something of an activist and a brilliant engineer besides other things, took it upon himself to help. He went back to the college he graduated from and offered to teach a subject for a semester. Together with one of his classmates, he went every week to his alma mater and taught the subject to his juniors. He had the benefit of having actually used the subject in his job, so he knew what he was talking about. The exercises he set were practical, the problems were real-life situations he'd faced. He knew which books were really useful.

The net result was that that particular batch learned the subject from a real expert - or atleast someone who really knew the topic. All the classes were packed throughout the semester, and the experiment was a real success. Subsequently, people from that batch came back from their jobs to teach their juniors, too.

It only takes a little bit of effort to solve a problem. You, dear reader, fellow software engineer, have learned a lot of things after you graduated from college and began working. Wouldn't you like that the people who come after you don't have to struggle as much? Wouldn't you like it that the new trainees in your company pick up things quickly, and that they know what's what, right after joining? How much effort does it take to solve the problem reported in that IE story? If not teaching for an entire semester, you could take on a final-year project for your juniors. If not that, you could create web tutorials and question sets and pass them on to someone at your college. If not even that - well, any little bit would help - you know best what can be done.

See a need, fill a need

A visit to salon.com after quite a while got me this interesting article : The world in the iPod. The writer talks about how chip fabrication units in China are taking away business from American units. There is talk of a "Golden Triangle" : Architecture in the US, Coding/design in India, Fabrication/Assembly in China.

Unfortunately, the conclusion that he comes to seems wrong :

This shift has some people very worried -- and they are not just out-of-work engineers. They fear that advanced R&D follows the physical location of production. If you are a cutting-edge engineer interested in working with innovative new techniques for chip manufacturing, you will be drawn not to Silicon Valley but to the scores of brand new fabs being built in Asia.

The bit in bold (emphasis mine) is the core of the argument, and it is totally wrong. The correct version would be : Advanced R&D follows markets, not production. It's the old principle of "see a need, fill a need" that drives the creation of any successful businesses.

So, for example, the only sort-of successful products made in India are the myriad banking solutions which are deployed all over Indian banks : because those banks were in a position to buy the software and be immediately benefitted by its installation.

What does it mean for us, the Indian programmers? It gives us a vague timeline for when a successful product market can be created here. If we look over what kinds of products would do well here, we see that consumer electronics - especially mobile phones - is the one burgeoning field - far more than any software industry. Today if you write a little app that helps/entertains the Indian mobile phone user, you'll have a winner on your hands. Note the meteoric rise of the "SMS your entries to 8888" type money-making schemes. Note the dozens of ringtone sellers. Write a codec that'll show amazing video on a mobile phone and see the queue of serive providers at your doorstep.

The only part of the software industry that seems to be doing well in India is the Educational software area. Every large bookstore has a shelf full of these CDs now.

But try to make a high-performance Email Server or office suite here. See whether anyone at all is interested. Unless it's something dramatically suitable for the Indian market, it won't sell. The computer software industry in India lives off the US and European markets, not the Indian.

Even though so-called product companies are coming up in India, the software products they make are built for the US markets. Those companies can get wide-based support only if there is a local market - even if niche - for the products. This requires higher computer penetration, mainly.

The good part is that all this is already happening - more and more computers are being sold, and more and more industries are getting interested in computerized solutions for their business practices. It's a matter of time.

An Open Challenge

A seemingly-unlreated article on Fortune.com drew my attention : The Amazing Do-It-Yourself Economy. The article talks of how much easier it's become for 'amateur' hobbyists to create products - websites, videos, audio, electronics - that are as polished as the professional ones.

One line in particular riles me :
To be fair, all this amateur energy isn't exactly a new force. When exciting technologies emerge, Americans have always pounced and created something original.

What are the rest of us, then? Where are the hordes of desi bloggers, singers, creators, inventors, ready to push their content to the rest of the world?

Well?

Prophecy Fulfilled...sort of.

At a book exhibition recently, I found a copy of a once-popular book - "The Decline and Fall of the American Programmer", By Edward Yourdon. This book describes how Software jobs are going to move from the USA to India and other outsourcee countries, and what American engineers should do to save their jobs. He also adds an appendix describing the Indian software Industry, and how it is developing.

In case you haven't heard of this book before, it's understandable. This stuff was written back in 1991, fourteen years ago, long before the current brouhaha over the issue! There are lots of things he got wrong, of course, such as suggesting that Americans should use CASE tools to improve their producivity beyond the reach of the Indians.

Nevertheless, it is instructive to read the section on India. The Indian infrastructure he describes feels like a bad dream today. For example :

After learning that my flight from Madras to Bombay would be delayed for four hours, I spent another hour with an NIIT manager trying to call the Bombay office to advise them of the delay. It was fruitless: we could not get a connection. Indians are accustomed to this, and have even accepted the fact that if they make an advance deposit of 5000 rupees, it may still take four years to get a new phone installed. Shrugging, they smile and say, "Actually, it's much better now that it was before..."


Nevertheless, Yourdon is spot on with the path he predicts for the Indian IT Industry. The evolution that it will go through (according to him) goes :

1. Building a reputation by providing cheap programming services on site at the customer's location.
2. Shifting the programming services back to India, with well-specified programs and systems delivered via telecommunications link to the overseas customer.
3. Gradually shifting the emphasis and focus from low-cost services to high-quality services.
4. Shifting from a service industry to a product industry by finding market niches or by providing higher-quality, lower-cost clone products.
5. Finding a try value-added software-intensive product in some application area that encapsulates India's own unique expertise.


Where do you think we are now, 15 years after this brave prediction? I'd say we're pushing for step 3 to happen. As evidence, take this recent story on SearchCIO. It quotes the Chief Strategist of Wipro as stating proudly, "Small companies don't come to Wipro.".

Indeed, we are increasingly seeing a particular type of outsourcing projects move off the radar for larger Indian companies. I mean those projects that came here strictly to save money. The ones that insist on giving only outlying, non-core work to the outsourcees and then paying the lowest possible rates. These projects are beginning to go to Vietnam or Uzbekistan. Indian companies are proud of themselves for taking on only the 'better' quality of work.

Let me state this up front, as an Indian software engineer/outsourcee : This is VERY DANGEROUS if it's happening everywhere in Indian companies. Bad work today, if done properly, leads to good work tomorrow. While the bigger companies, that pay well, cannot fight on price anymore with Vietnam and co., we ought to be seeing a new layer of smaller, tigher, cheaper outsourcees coming up in smaller cities in India now. They should be the places where the bad projects go, not Vietnam. The Indian software industry should not be a single, monolithic block that raises or reduces billing rates together, there needs to be competition - local competition - snapping at their heels. There need to be places where simpler work is done for lower rates by less-experienced people.

This may sound paradoxical : I've been complaining about the bad work that outsourcees do, in nearly every post. But that is one extreme; this is the other. Both are bad. Creating an industry entirely of cheap, billed-rock-bottom programmers that do manual testing was my fear earlier; the new one is having a huge pool of architects doing work at high prices, with no space for newbies or part-timers. We need a proper Ecosystem of all types of engineers.

Such an ecosystem will be essential if we want to move on to the next steps in Yourdon's path.

'Social Networks'

[This article was published in the Express Careers section of the Indian Express on 5th May 05.]


Social networks: A key to employee retention


The Indian IT industry is now entering the consolidation phase. A large number of companies have established themselves with the customers, and have proven themselves as reliable, low cost outsourcing destinations. Now they must secure their presence in all segments of the software development cycle - design, development, testing, maintenance and support. For this purpose, every company today seeks to grow and create specialized work force in all these areas. Companies also want to establish quality processes, and increase the percentage of experienced employees.

The biggest hurdle faced by all companies is retention of employees. More than ever, engineers are feeling frustrated by the assembly-line style work done by software companies. They repeatedly change companies, trying to find work that suits them, yet finding themselves bored by the monotony of every task. In this job-hopping, companies end up with employees that do not stay long enough to imbibe the company culture and values, and thus are not suitable for higher-end jobs.

Companies usually encourage employees to work as hard as they can, and promise bonuses as incentives. However, beyond a point, money does not serve as a motivating factor. One big factor that creates boredom in the employees' lifestyle is the lack of any extra activities or hobbies in their day. In order to keep employees happy and productive, they need to have some social activities and interest-based interaction with peers regularly.

A good solution to this is to create cultural activity groups within the company. Sub groups can be formed related to various interests such as music, dance, painting, sports, singing, quizzing, or trekking. These groups then hold shows, exhibitions, and competitions at regular intervals, open to all employees.

Alternatively, company-wide parties, movie screenings, dinners and picnics can be organized. These are informal events where people can interact with each other without the formal organizational structure coming in between. People meet their friends, old acquaintances, and spend the evening discussing things other than their jobs.

These activities create a welcome change from work, and give people something to look forward to. In Pune and Bangalore, for example, the IT companies hold yearly inter-IT company quizzes, cricket and football tournaments. These are keenly fought efforts, and the entire software engineer community follows them with interest.

An important effect of such activities is the social bond it creates between employees who have common interests. It creates friendships between people who may sit in different buildings, different departments, and pairs them together in joint activities. The social network of these employees thus improves, and they look forward to meeting other people within the company. In large companies, this is a real boon because otherwise employees get to interact only with people from their own projects and thus feel constricted.

Another effect is the creation of a sense of belongingness. Employees who play, say, cricket for their company feel a sense of pride in belonging to the team. The people who cheer for their teams feel the same sense of pride when their team fights well.

A third effect is the image of the company itself. A company that routinely produces winners of a quiz competition gains a reputation for being a 'smart' company. A company that organizes seminars and conferences gains a reputation as a leader-type.

Last but not the least, these activities create informal channels for people to talk to their supervisors and management teams. Discussions on project environments, quality of work, etc. can take place with no risk, and defuse potential tension.

All these activities create a kind of bonding between the employee and his company. He knows the people there, he is comfortable working there, and he has someone to turn to when he wants activity partners. These factors are just as important as the work environment and technologies in retaining him in the company.

More importantly, such measures cost very little to the company. They definitely cost much less than repeatedly losing qualified employees and retraining new ones. With time and a sensible approach, companies can ensure they minimize their attrition rates and grow with the least possible problems.

Conference Calls

[As a followup to my previous post, I'm posting a brief tutorial on Conference Call etiquette. This essay was published in mangled and shortened form in the Indian Express a couple of weeks ago.]

Effective Conference Calls

Most software companies in India are service companies with offshore clients. This means that, when one joins the IT industry and is allotted to a project, sooner or later one will be communicating with a US or Europe based customer. Besides E-Mail and Instant Messenger, he will be periodically co-ordinating with the client over the telephone. These are commonly called Conference Calls, because several people from both sides usually join in and resolve all pending matters.

New employees often make mistakes while participating in these Conference Calls. This may have serious consequences. Since the clients usually haven’t met the project members face to face, these calls are the only means they have of judging them. Creating a good impression is a must. Besides this, since the calls are international calls across Time Zones, time needs to be used effectively.

Here is a guide to getting the best results from Conference Calls.

Setting up the call.

1. It is always best to send out an email listing the details of the call well in advance, to prevent misunderstandings. The mail should contain:

- What is the appropriate time and date for the call? Remember that your client is in a different Time Zone. If US-Based, he/she is 9 to 13 hours behind. If Japan or Australia based, he is some hours ahead. Not all the client-side participants need be in the same time zone – they may belong to different offices. So make sure that the timings are convenient to all. When sending out notification for the call, ensure that the local time for each participating office is mentioned explicitly. In the case of the US, remember to take Daylight Savings Time into account.

- Who are the people participating in the call? Make sure that the names of all participating people, from India and all other offices, are mentioned. Also ensure that the email goes to each one of these people.

- What is the number to be called? Different offices have different ways of setting up call numbers. Verify that the correct number is sent to everyone. What is the country/area codes for the numbers? Are any passwords required to connect? Mention these details.

- Agenda for the call. It helps if all participants know the topics to be discussed. They can keep any related data ready if required. It also gives everyone a rough idea of the duration of the call, and whether or not they are really needed for the call.

Keep a printout of the mail handy, to use as a reference during the call.

2. What is the place from where the call will be made? Usually a conference room or a specific cubicle is used. Ensure in advance that the space and the phone instrument will be available.

3. For all agenda items, you can work out in advance the information the client is likely to ask for, and keep it ready.

Making the call

1. Be available online (IM or email) 10 minutes before the call. The client may want to reschedule the call if an emergency comes up.

2. As far as possible, see that all required Indian team members are present in the conference room before the call starts.

3. Designate one person to take the lead in the call. He will

* Make the actual call,
* Introduce himself, and attending team mates.
* When client is ready, start discussion on the points listed in the agenda. The concerned team members can then take over for their own items on the agenda.

4. At any time, if you do not understand what the client is saying, do not interrupt him; wait till he pauses. Then say specifically what it was that you didn’t understand. Request him to repeat the unclear portion.

5. Some new topics, which were not in the agenda, may come up during the call. If not sure about the details of these, do not jump to a hasty decision. Offer to send the details and analysis over email after the call.

6. It is fine for the local team to discuss points that the client has raised, while the call is ongoing. But do not speak in Hindi, Marathi or other languages during the call, even if the listener is Indian. This is very irritating to other participants if they are not familiar with the language. Stick to English. Do not use slang.

7. Designate one person to note down the minutes of the meeting. In particular, action items for team mates as well as clients should be noted, along with the expected time of completion.

8. At the end of the call, read out again the action points, the person responsible for each and the timeframe for them.

Following up

1. Send out the minutes of the meeting by email, to all attending parties as well as any managers who are interested. Most importantly, the minutes should list any decisions taken and all the action item details, as above.

2. When reporting the completion of the action items decided during the call, make a reference to the call itself. Thus in the mail, mention: “As per our discussion in the call of date so-and-so...”

3. Keep the minutes of older calls available on a local web site or newsgroup. This will help new members when they join the project.

Training? Why, wasn't college enough?

A news story in rediff today says that IT companies consider employee training low priority. I agree. My experience has been that a new employee is expected to 'just know' everything that is required for his job. Often there will be some technical training in the domain of the project, but that is pretty much it. The larger companies even have a couple of months of training sessions, which are supposed to bring even non-computer science graduates up to speed on IT, after which they join alongside their CS-grad brethren in projects. I don't doubt that the technical training they get is decent enough and comprehensive enough to work on the outsourced projects. (Remember my thesis that it is the fringe and 'simpler' part of any project that generaly gets outsourced.)

The area where training usually falls short is the Culture training. I don't mean stuff like which-hand-to-hold-the-fork and what-dress-code-to-be-followed. The working culture of a professional organization is very different from the cool, somewhat laidback environment of a college. The ground rules for interaction with colleagues and customers are more formal and rigid, even though they may not be spelt out explicitly. But these details are usually explained through informal sessions with senior employees in the project, not through any formal training. And this is where new employees usually trip up. Remember that the only way customers know the project team members is through their phone conversations, emails and chat. Special care needs to be taken in this respect. Yet these issues are skipped over entirely in the training sessions, and usually there isn't even any documentation explaining the details that experienced people take for granted.

I will list out the particulars of the unwritten codes of conduct in the next few posts. Comments and additions to the list are always welcome.

"My Job Went to India"

George sends me this link about a book which so blatantly opportunistic it hurts. It's called "My Job went to India(and all I got was this lousy book.)" Well, atleast he knows the quality of his book beforehand.

The blurb is full of marketing-type gems like "It's time to take control of our careers, and in the process, learn to stay both relevant and employed.", and "You'll learn how to shift your skillset up the value chain, from offshore-ready commodity to one in high demand."

On a more serious note, this book ought to be on every Outsourcee company's library bookshelf. Any Indian manager who is dealing with American clients on a daily basis needs to know the keywords and terminology that reassures the client. And whatever techniques this guy advocates to 'keep current' can be used just as easily by Outsourcee companies too.