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...

Leaving a mark...

I have been playing the role of a DW Architect for a large financial services organization over the past 6 months. When I reflect back on my duties and responsibilities, one aspect came out very strong that gets missed out in the job description.

"Leaves his Unique Selling Proposition trace in the project"

There are often a lot of other crap that the organizations look for like..Coordination between the business and IT....Owner of data models....Provides strategic direction to the IT team...etc...

Do you think Emperor Shah Jahan would have given a big job description to his architect,Ustad Ahmad Lahauri, when he set out to build the Taj Mahal? He described the Taj Mahal as

Should guilty seek asylum here,
Like one pardoned, he becomes free from sin.
Should a sinner make his way to this mansion,
All his past sins are to be washed away.
The sight of this mansion creates sorrowing sighs;
And the sun and the moon shed tears from their eyes.
In this world this edifice has been made;
To display thereby the creator's glory.

If you read the last line, it stresses the need to display the creator's glory. An architect should leave behind his glory after he is long gone from the project. That should be the true job description. It should be the one thing that the people would still talk about after he has resigned. The rest of the responsibilities are just enablers for the ultimate glory.

Celebrate even the journey and not just the result

I am a great fan of Aamir Khan, a fine actor in Indian cinema. But more than his acting prowess, what impressed me was his "own opinionated" view on movie making. His one little belief helped me realized a lot in my day-day activities. He has indicated that he believes in the process of film-making - the thrills, the sufferings, the enjoyment, the sacrifices, etc... more than the end result itself.

We do envision the end result, but a lot of us bury our minds in the end result so much that we don't enjoy the day-day process. For example, when we make software, we are so engrossed in meeting deadlines, living up to stakeholder expectations, daily status reports, that we forget to celebrate or appreciate the tiny successes like completing a unit of code without any bugs, writing a nice piece of documentation, being near your team member when he/she has a problem in her personal life, tuning a SQL query to less than 10 times its original running time. We lose all such fun events in the search of the end state, that even when we achieve the end state, it just doesn't taste that great. We pat our backs and are on-board the next "deadline train".

I am planning to introduce a "Success or Failure Celebration" event once a week in my projects going forward where people can celebrate their daily successes and failures. They get recognized for their daily successes. They can talk about their moments when they punched their fists. They can talk about the moments when their hands were there for their friends.

I will keep you posted on my results.

Ownership - Problems end with it.

Often, I find a lot of skilled and talented software engineers, who get stunted in their careers. Reason. Not skills. Not IQ. It's lack of ownership. They become more of "problem announcers" rather than "problem-killers". They just want to tell that there is a BIG, BIG problem ahead, but they don't want to solve it. Because solving is taking risk.

So, how do you get these kind of people to shape up? They are talented, because they find problems for you. Finding problems are like finding opportunities. So, what do you do ? Give them ownership. Give them the task of closing it out. Ask them not to just bring problems. But to "close" it with solutions. Once you give them the ownership, back off. Let them do their job. Don't micro-manage.

Nobody would like the auto-mechanic, if he just says there is a big engine failure in your car. But since the car mechanic has his business to run, he supports it with a big "Resolution" kit, which makes you feel to just leave the keys to him and then just pick the car when it is ready. He has ownership. He will complete it.

Productivity is just not about oneself

Last week, I have been trying to reduce my total # of work-hours to see if my productivity improves. It did, because I knew I had few hours to wrap up my work, so I wouldn't waste my time on long lunch hours discussing about Kanimozhi's arrest or taking multiple tea-breaks to vent my frustration on my boss.

But I am slowly realizing that productivity is just not about oneself. Its about the entire ecosystem. I had to elevate a piece of my code to User Acceptance Testing environment. And this was quite an urgent requirement and so wasn't a planned one. Now, even though I finished testing the code; the code couldn't get moved because of the frustrating bugs in a software development life cycle - "processes". So my productivity was based on the "process" productivity. There is "system" productivity, "team" productivity, "hardware" productivity and "off-shoring" productivity.

If your manager asks you to improve your productivity,ask him to:

1. Bring shortage or scarcity into the team
2. Show proof that its because of one person's productivity, the results are not achieved.

Is adopting scarcity a good strategy?

Yesterday, my apartment management stuck a poster which read

"Tomorrow, shutdown of water services between 8 AM and 12:30 PM due to repairs. Inconvenience regretted".

This water scarcity for 4 hours made me to wake up early and take my shower quickly. It forced me to use water conservatively for the next 4 hours till the supply was back. When I reflected back, I noticed that my day was productive, because of one little thing. The shortage. The scarcity.

So if I bring in scarcity into my everyday working style, will it improve my productivity? If I reduce my work time to 5 hours, will it improve the way I do my things? If I reduce my team size, will the output be better? If I reduce my commute time to work, will it help me to reduce my working time even further?

My strategy for the next few weeks would be to implement a "scarcity" based working model

I am my own management institution

I am not an MBA. Nor am I pursuing one. I wanted to get one. But unfortunately, we have too many constraints to get a good MBA degree in my country. The first one is CAT. I don't understand why should one be so sound in English vocabulary to be good at management. Why should I know what "Ennui" means when I can always use the word boredom? And even if I use the word "ennui" to a prospective customer in India, what are the chances that he will understand it? My sister would always argue saying that I sucked in English and these are excuses for not scoring good at CAT. I ignored. The second big constraint is time, if you are working. So I decided, that I will be my own management institution. I decided I will learn my own management lessons. And also experiment them.

This blog is all about my personal "practical" experience learning & experimenting management lessons. Strategy is going to be my first experiment. I will be sharing my experiences implementing "Strategy" and watching its "Results" in the following weeks to come.

Identity for quality

American Board of Internal Medicine (ABIM), a non-profit evaluation organization periodically tests the quality of 1 on 4 practicing physicians in the United States every year. The pass rates on the initial attempts have been close to 86%, which I feel is pretty scary, assuming that 14% of the physicians are in the risk of not allowed to practice till they pass.

Amidst a lot of critical reviews about the evaluation system, I feel it is still a very reassuring practice to let the taxpayers know that the system cares for the quality of the practicing internists. When was the last time, we, IT professionals took such a professional re-certification? We do have internal exams/certifications that our organizations mandate to pass to get our promotions/hikes, but none of them stop us from practicing the work that we are doing.

Is such a re-certification required for our profession, when most of the problems we encounter are answered by Google anyways? Should we need a authority which puts rigorous control on the quality of professionals coding/designing/managing? Should our identity for quality be a certificate and not a resume?