My biggest challenge right now. Follow-ups.

Last 2 weeks in my project were pretty challenging. Reason - 'Follow-ups". I hated the job of following up with someone to find out if they had done their job.

I hated it because I felt I was knocking into their privacy.

I hated it because I felt it was not under my control anymore.

And I hated it because it makes you feel like a beggar.

The more and more I hated it, the more and more I realized that it was inevitable. I had to do it. It is unavoidable. Now, I had this big task of doing something that I hated. Whenever I faced situations like this, there is one thought which keeps me kicking - "If 'I' could learn and write SQL, then I can do anything". SQL is something that I hated a lot. I used to score "Single digit numbers" in my training tests. But today SQL is my career. And I do it passionately. So I decided to apply the same philosophy to follow-ups too. Turn something that I hate, to something that I have to do it passionately...

Vidaathu Karuppu (A Tamil phrase for "an omen that never leaves your back")

Treat it as an omen that will always sit on your back. You just have to be-friend it. Once you start perceiving it as an "always existing" to-do, you will start designing permanent solutions for it. My very first hour in my day is a "Follow-ups" calendar item. I send reminders to all my "follow-up contacts" or give them a call to find out.

Sending a PENDING Status Mail

I send an email with the Subject line as PENDING. It is little bit rude, but I find it working.

Fix an interval and keep reminding

Fix up an interval like 1-2 days or 3-6 hours or any limit depending on the criticality of the process and keep reminding.

Highlight the impact and also the benefit of finishing on time

Make sure you highlight the impact of the delay to them. Also highlight the benefit of finishing it on time.

I use one of these techniques to get my followups closed. But I still struggle, because it needs a lot of patience.

I made a big mistake. Farewell is as important as Introduction.

I made a big mistake. When I signed off from my previous project, I didn't send a "Farewell email" at the right time. I sent a week later.

I worked out of my client's place. I sent an email to all my colleagues onsite (the term used to refer to client's location in the offshoring business) the day I left from the place. But somehow missed to send to my counterparts at offshore. I just sucked.

I didn't realize till one of my colleagues was surprised that I had left the project and I hadn't even conveyed my move. I felt miserable.

Sending a farewell email at the right time communicates a lot of emotions. It says that you care to communicate your decision and you respect them. It says that you would want to stay in touch and finally it says how much you will miss them when they are not around you.

I realized that farewell emails are equally important as an introduction email and it has to be drafted in a nice manner at the right time and not for the sake of sending one.

Cost of Default - A "Derisking" technique

I parked my car in my usual Park-Ride facility and was walking to catch my light rail to my office. I had to enter the parking lot # to buy my tickets. I remembered it, but I was reluctant to take a chance. My train had arrived, but I was prepared to miss it and go back and check my lot#. I walked back to the lot and verified it. My memory was right.

When I reflected back on that incident, I thought it was too risky to rely on my memory and the cost of default was not proportionate to the risk that I take (The cost of towing and the frustration that accompanies with it was just too much to take). The imbalance made me to go and verify it.

Why don't we do it for our own projects? Before we release a piece of code, do we think if it is worth releasing a buggy piece of software? Do we weigh the cost of default to the urgency? Probably, if we start to, it might help us to avoid a lot of unnecessary chaos that we are causing to the IT services industry,

Smaller teams vs Larger teams - What should you work in?

I have been always faced with one dilemma throughout my career of 8.5 years. "Working in smaller teams" vs "Working in larger teams".

Ok !! Let me define first...

Smaller teams - not more than 4.
Larger teams - more than 6.

I have experienced both these worlds, but I keep toggling always thinking the grass is greener on the other side. Or probably its paler on the current side...

I would prefer to work for smaller teams because

1. A smaller democratic setup.
2. Easier to steer the ship. Don't have to worry about too many moving parts.
3. Work gets noticed/criticized/rewarded immediately.

I would prefer to work for larger teams because

1. Highly dynamic and challenging environment.
2. Complex human chain.
3. You will learn scalability (I was born in India).
4. Most of the interviewers ask you how big was your team size and not how small was your team size.
5. You will learn to be more realistic.

Hence, at the end of a project, just like TamilNadu politics, I just vote for the other side. I think both the kind of projects are necessary for the evolution of IT services. And if you bias your opinions towards one of them, you will soon be gobbled by the nature of the game...