Thursday, December 28, 2006

Handling attrition in SME

I have come across a few instances where a large number of employees from a division quit within a short time. Though I didn't face the problem myself as a boss, I was part of the group that quit once - just once. The reasons range from better job market to low morale. Here are some thoughts on what the management can do about it.

1. When a key person or more than one person from a team quits, stop; think if you are doing anything wrong. The person might be leaving for any reason - the management needs to take the employee's reason with a pinch of salt. Rarely employees tell you what is wrong with you. They tend to be nice and usually lie.
2. Some of the mistakes that management end up doing are - share the work done by the employee who left among the remaining ones, putting more pressure on these members to complete the work and pressurizing HR to recruit more.
  • Sharing work is fine as long as the time allotted for completion is extended appropriately.
  • Giving pressure would happen involuntarily as management would like the project to complete on time or sales maintains the pace. In instances where possible, extending the deadlines or relaxing the targets would be the right thing to do.
  • Pressurizing HR without ensuring that the team is adequately staffed and skilled will cause more unhappiness in the HR team. Soon you will be seeing an exodus from HR. The first thing to do is to help HR ramp up on the skills and resources or begin outsourcing some of the recruitment activities.
These mistakes help in worsening the situation.

3. In divisions where the attrition is high, find out if the working conditions are normal. Smaller organizations do not have a process to address employee grievances. In many small organizations, employees don't have a chance to complain about their bosses with a confidence that they will be listened to and addressed. In cases, where a single boss micro-manages everything and there is no hierarchy, no employee would tell the boss that the conditions aren't right. Especially in cases, where the top manager is involved in every employee's daily tasks, there is no chance for an impartial observation of the situation.

4. It is comforting to list all external factors like good job market as reasons for people leaving. It just ensures that your ego stays unhurt. So, just be aware of this tendency and be reasonable in including such factors.

5. If the problems point to poor working conditions like office space, facilities, timings or accessibility, be sincere in addressing them. Speak to the employees that the situations can be addressed. If possible, involve them in a solution - like help find a bigger place, suggest timings. If the problems point to a person, work on informing the person of his / her shortcomings and help in improving on those.

The most difficult part in handling the attrition is - seeing your shortcomings and addressing them. I'll try to locate a few who managed it and write about them in the next few months.

Tuesday, December 26, 2006

Technical Writing and all such talks

Technical writings and software documentation

It seems Naveen, Ari and Shivan won't get to a conclusion. For relatively small SME projects, following a good coding habit is the most essential requirement. The cost of documenting the project could be too prohibitive for the SME. Consultants can give a value for the money by just following standards as per the language and environment.

This makes it imperative for the developers to be disciplined on whatever they are doing; that doesn't come right away when you work for small projects. It is like a circle, where bigger projects bring in discipline - developers have to gain experience with smaller projects to enter bigger ones - smaller projects need discipline (more than bigger projects where minor deviation from standards here and there won't matter much).

Tough cycle to break; but will try that!

Friday, December 22, 2006

Traffic lights coming down in city

Traffic lights coming down in city

Chennai added a large number of traffic lights and cops in the last 12 months - An indication that we are becoming less considerate to other road-users!

Tips for reading other person's code

Tips for reading other person's code

More from a maintenance guy's experience.

1. Concentrate on code and take the comments with a pinch of salt. Often you will encounter comments that were not updated when code got updated.
2. Try writing down your understanding of the code, taking one chunk at a time. A chunk typically consists of a program construct like if...else block, or a loop or a function. This way you can reconstruct the algorithm, especially if the code wasn't structured.

Thursday, December 21, 2006

Hype about IITs

IITians, do something for Indian education is right on target. There is no doubt that the students who enter IITs are the smartest ones in the country. The question is, what value does IIT add to these students during the best part of their life. Success stories of IITians becoming entrepreneurs and good scientists typically have chapter where the person spent 2 years at Stanford or MIT or Harvard or other great universities in US, after their B.Tech at IIT.

IITians when they come of out their B.Tech often have an air of justifiable superiority complex that prevents them from being normal. This gets normalized when they go to US, see that there are others including Indians from other schools who are at least as smart as IITians are.

In addition to getting into serious competition with Chinese and other Asian universities, IITs should also get into research in education, humanities and basic science.

Friday, December 15, 2006

ChennaiCentral - a die-hard Chennai-loving Indian Blogger

ChennaiCentral - a die-hard Chennai-loving Indian Blogger

It is surprising to note that SEO is influencing blogging rather than the urge / need to express.

Wednesday, December 06, 2006

Google: Gmail - Calendar Integration

You have reasons to be paranoid on what all Google does with your email.

I was having an email conversation with a contact to schedule a meeting. I used Gmail. As the email thread grew, on the right side navigation Gmail shows links to add this to the calendar. When I clicked on the link, Google had pre-filled some of the fields like date, location. If I had used a different time format, Google would have picked that one too.

It is nice to know that Google does so much for better user experience. At the same time, I am a bit uneasy with the parsing of my mail content. I guess Google WILL parse the email for ad-sense and such money making features.

Is there a way I can tell Google not to parse my mails or show context sensitive ads on the right side?

Tuesday, December 05, 2006

Differing views of managing software requirements

I hope this is doesn't become a habit that I bitch about non-technical people, though I may have intentions to do so.

Coming to the topic of my opinion, there are two views of software development.

i. Build the perfect system handling extreme cases though the extreme cases will not be encountered for the next couple of years. Consider a service aggregation where multiple service providers sign up. Users can choose the services that they are interested in and pay for it. If the business is not yet ready to bring in multiple service provider for the same service (say payroll), it makes no sense to build the software up-front to handle features like the priority, pricing etc.,
The business must be a very powerful one to get such multiple service providers sign up with them. If that is the case, why should the software be designed for it up-front. When the business spends the efforts to rope in multiple providers, the logic for the priority and pricing will have to be reviewed and changed as there will be a better understanding of the problem.

ii. I am fine with an approach where you treat software as an evolving beast. Address the requirements that would be useful right away for which the efforts are proportional to the effects. In web lingo, what is the cost per click - if you were to measure the cost in developers' time. If there is a reasonable doubt that a feature will be useless for 50% of the users, it makes sense to drop it and focus on something more important.

Often I come across bosses, mostly non-technical who want to take the first approach. I would bet that less than 10% of such over engineering done ahead of time is useful.