Leadership is support....

Do you feel like calling your boss when you are in a problem hoping he is there for you?


In my opinion, leadership is about the support you can provide to the community that you touch upon - your team, your customer, your vendor, etc, when they need you.


I want to take an example of one of my colleagues, who is basically an account manager. His role doesn't demand him to fix a java or a shell script, but in case of one, I feel like reaching out to him. His role doesn't demand him to take care of low quality conference bridge issues. But in case of one, I reach out to him. And he does all this without a fuss. For me, he is a leader.


I know whom to reach out in case of an issue. Are you one of that kind? A supportive leader or a tyrant boss.

Working with your competitors...

The IT Services business is very very tricky. And to win business, you are supposed to do anything...


You need to stay competitive. And you need to stay with competition...


The latter part is a very unusual situation when you are supposed to work with competition to deliver value to the customer. Now, how do you do that? You would have won the deal against the same competition and post that you need to work along with them. 


To give an example, take a Manufacturing services company getting serviced by multiple IT service vendors. Nothing unusual about it. Now, typically in a datawarehousing project, the data is pulled from multiple sources and then integrated into a datawarehouse and then reported from this environment into a presentation layer. 


We have 3 distinct ecosystems- sources, data-warehouse & presentation. Now, if each ecosystem is driven by a separate IT services vendor, and all 3 of them compete against each other for every project, how can you expect harmony to exist between the 3, which will naturally flow into the application that is getting built. 


Lot of times, projects get delayed not by the team performance, but purely by such strange de-risking practices followed by organizations to make the competitors work together. They never can. There will always be the line where information sharing will be seen as an "evil act".

Learning to document..hmmm...no...communicate

We document something or the other everyday. 

We document for "formality" purposes. 

We document to "save our asses". 

We document for "milestone deliverable" purposes (payments would be dependent on it).

But how many times have we documented to communicate?

Every time, I compose a design or an architecture document, it starts on a good note. I enter the "table of contents", with a lot of thought and structure and then as the documentation progresses, the interest wanes. The objective starts with "communicating the design" and then finishes with "documenting the design". A more deeper thought on it revealed that when I start documenting, I start with documentation, not communication...High level design documentation, low level documentation, support manual documentation, etc...These are all boring words to anybody. Who cares to read the disclosures? Who cares to read the "Conditions apply?". Because these are all documents. Their primary purpose is to save themselves and not to communicate something to their customers. That's why they are a failure..

Now documentation is a boring word...I researched the two keywords - documentation & communication on Google's Ngram Viewer and this was the graph...

(Communication vs documentation)

It is a nice comparison between the 2 words. One basic inference is that "communication" has been in use for a long time. Documentation seems to be a word of the post-40s. And communication has been used in a lot of books compared to documentation, illustrating the fact that its communication you would want to do rather than documentation in your projects.

Once you start thinking in terms of communication, your whole perspective towards composing any kind of artifact changes. You would want to communicate your design process, challenges you faced, your solution, benefits and drawbacks. Its like selling your design process. This will free you from MS Word documents. It can be a simple presentation or a movie or an audio file too or just a diagram.

Documentation..hmmm...no...Communication is an art..Its one of those pieces when done right, the satisfaction is fulfilling. Ask the book writers and scholars.

Formal meetings in informal setups

I entered this field of pre-sales/sales without any kind of formal education, so you can expect me to be a bit rusty. One month ago, I was in a casual dinner setting with a potential prospect. We were having dinner, chatting about projects, states and their cultures, etc...It seemed like everything went well that evening. I was giving my usual DW and BI story, maturity, roadmap, etc...I was invited into this meeting to primarily impart some potential pitfalls about a tool that the customer was planning to buy.


It has been more than a month and we didn't hear back from them, in spite of repeated followups. I was wondering why. Today, I received a call from my sales manager, who was also in that dinner meeting that evening. He told me. 


"Senthil, I would like to give you a small piece of useful tip. Never use your mobile during such a meeting, even though it might be a casual dinner meeting. Either excuse them and use it or don't even use it". 


After some analysis on that particular incident, I recollected that I used the mobile to text my wife that I will be coming home late. And some more analysis revealed that I had taken the dinner meeting with the prospect a little too light. After I was done with my job of educating the prospect on something that they were looking for, I was relaxed and forgot that I was still with a prospect and not a customer. I should have been more careful.


I realized that it was a bit rude from my end for having used my mobile. I wouldn't have certainly used my mobile, had I been in a conference meeting room or more of a formal setup. The restaurant made me feel that it was a very casual meeting and I felt it was okay to give up some of the "formal" rules.

Formal meetings in informal setups can be tricky. Never fall for the casual ambiance. It is still a customer meeting. I screwed up that day and I am thankful to the gentleman who called to correct me.

Internal competition & scarce resources

On our lunch table, we were having quite an interesting discussion. The question which was under scrutiny was

Why am I locked to one project? When will I be released? Hope I don't retire in this project.

Lot of organizations practice what is called as "Internal Competition". Internal fights are primarily instigated by the top management layer to get the best of the products from different project teams. In some cases, the same product might be developed by 2 different teams and the best version will be given the chance to continue it further.

This culture of internal competition can also be noticed in a lot of IT Service companies. For any IT Service company, their product is their people. They sell people and their experience on the projects And you will find that most of these companies would have services/offerings compartmentalized by "industry" groups. So, they sell people with good technology and industry skills. 

Now, when competition is induced between these groups, they fight for the scarce resource's (people's) time. They wouldn't want to release these people to other opportunities in other divisions. Its a classic example of "Controlled Labor", where the allocation of scarce resources is not controlled by the demand, but by "internal competition". And whenever this imbalance in economics happen, we know the result is not desirable.

Let's say I want to rent out 5 houses. Should I rent it out on the basis of the market(demand) or should I rent it out on the basis of some kind of rent control scheme ( like renting out to only bachelors who are vegetarians)? We all know the ill effects of rent control schemes. That's what is setting out to happen in IT Services industry. Technology skills are getting locked. And they are locked hoping that their skills would be required for future usage in the same industry group, whereas another industry group might potentially lose a deal, unable to staff the skill set. And in effect, the organization stands out as a loser.

Internal competition is good, but not in a way that it locks the scarce resources that the entire market is dependent on.

Filling timesheets

I am sure a lot of us would have had a tryst with the "nonsensical" work of filling up time sheets. This was initially introduced to keep a track of how long does an employee spend his time in a project, so that it could help them for 2 purposes

1. Bill the customer for the exact amount of time the "employee works".
2. Calculate exactly how much time he works so that it will help in future estimation of projects.

But how effective is this process? Measuring productivity has always been a great challenge. Because productivity is not just about time. It is about quality, efficiency, growth, etc.... And what is the solution that we have today? Time-sheets.

Why would I want to enter that I worked only 5 hours? Because I know that if I enter 5 hours I will be questioned, even though I had finished my work. Its like the prisoners dilemma problem in game theory. You don't trust the system, because the system doesn't trust you. And the system also thinks the same way.

Now, what about entering more than 8 hours? That is also a tricky problem, because you will be questioned on your effectiveness to finish the job and on top of this there would be 100s of clauses in the SoW which would detail that you wouldn't bill the customer more than 8 hours a day. So the magical number of 8 hours a day was established and employees just enter that number.

So this madness continues on a week-week basis to enter 8 hours/day. And in this process, we are not solving both the issues mentioned in my first paragraph. We will keep billing the customer 8 hrs/day.

In my opinion, organizations should first open out this channel to accept realistic time lines from the employees and bill that same back to the customer. Yes, it will cut corners, but that's alright in the longer term of things. There will be certain unpredictability, but its alright.

I think CMM guys should make this as a mandate in their evaluations !!!

We belong to 2 parents

In this post, I want to address one specific case of attrition. Attrition of employees from their "biological parents" to their "foster parents". In IT services, we are bound to 2 sets of parents at any given point of time. And I guess that relationship is what causes these kind of fall-outs.


Biological parents

These guys are the ones whom you work for. They are the ones who recruit you and position you into projects. They are the ones who send your paycheck every month. You belong to them.

Foster parents
These guys are the ones for whom you perform the work. They are the ones who nurture your skills. They feed you with challenges & requirements. They are your customers. In fact, they feed you and your biological parents.


Now, when you spend a lot of time with your foster parents, your loyalty and faith starts tilting towards that particular organization. You will be honest to them. You will give them unbiased opinions. You like them. What happens to the biological parents? They still own you.


I have seen a lot of my friends leaving their biological parents for a more stronger relationship with the foster parents. Is it unethical? No. I don't think so. It's purely the way this industry works. When there is osmosis, we will have reverse osmosis too. Its talent here. And it will move towards higher concentration. If the "biological parents" have to somehow stop this osmosis, they should be gearing for better people policies, which will attract their employees to stay back. Ideally, they should be more concerned about their people leaving to join their competitors more than their customers. Because when your own employee leaves to join your competitor, you have leakage of your IP, whereas if he or she joins your competitor, you have promotion of your IP.


I feel its perfectly okay when your employee joins your customer. He will spread the good word of your organization.

Why should a techie do pre-sales?

As a technologist, I used to always stay away from the world of sales. I hated it. And I hated sales guys even more. Because they would always sell some kind of service which we would either not have or not have currently.

A couple of years back, my boss wanted me to realize how stupid I was to think like that. He asked me to do pre-sales. In my opinion, a pre-sales consultant's job is the most discretely defined of all the positions that lead into the executive management space. A pre-sales consultant's primary responsibility is to convert a lead into a customer. Never was I faced with such a challenge in my entire technical career. All I have to make sure is not to lose a customer by delivering some crappy piece of software. Now that's preservation and not conversion.

This posed me immense challenges because my mindset had to change completely. From a cubicle-guy to a board-room guy. From a SQL-Editor guy to a Powerpoint-guy. From a internal-guy to an external-guy. The last point is very important. Pre-sales makes you more of an external guy. An external guy is one who understands the market. He is the one who understands the customer. He finds problems rather than solves problems.

So now, why should a techie learn pre-sales? Simple. To find problems. The more and more you grow up in your expertise ladder, you realize that you need to find problem patterns. As a senior consultant you are expected to know the problem before hand itself. And have a pattern available for the same. And pre-sales helps you to get into this mindset. Pre-sales will help you to lookout for problems before problem finds you. It will make you think in terms of broader problems and even broader solutions.

You talk to a pre-sales guy. He will give you the problem, design considerations and solution. You talk to a techie. He will ask you the problem and then he will give the design considerations and solution.

I need supervision.

Can you supervise yourself? One of my company's co-founders had published a book called 'The Professional' and he talks about professionalism is about self-supervision. A professional is about a person who knows when he has completed his job; he shouldn't be relying on somebody else to approve the completion of his job. If he does, then he is an amateur or apprentice.

Somehow, I am not convinced about this principle. And the reasons are as follows

1. The world of IT services is ever-changing. In that case, how do I know what is complete? I need some more eyeballs to tell me whether what I have done is correct or not, whether I have completed it or not. I need supervision not only to tell me if I have completed my work, but also who can monitor me on a day-day basis. To track my progress. To tell me if I am on track. To tell me if with this rate, whether I will miss the bus or not.

2. Our requirements are not as static as an undertaker's job. Its pretty fluid. We have to adapt and change. In such a changing process, you need expertise to validate your work. You need supervision to watch over your direction.

We all know the importance of reviews and followups. A world without reviews and followups is a highly idealistic world. A world of programs. Speaking realistically, I wouldn't let my own team self approve their own work, no matter how brilliant the team is. I will certainly get into some amount of detail and followup. I will certainly want to track their progress and not wait for the last day to get a status. Its not because I doubt their capabilities, but because I know that only constant feedback and tracking improves the quality of work.

Getting stagnated...

I have spent my past 8.5 years of my career doing Data-warehousing and Business Intelligence. What next is something that I keep asking to myself, almost everyday? One of my managers stopped by and asked me.

"Are you getting stagnated?"

I was taken aback. I wanted to know why did he feel so. He told me - "Because you are working on the same thing for 8.5 years".

In Indian IT Services, we have this strange theory engulfing every software engineer -

"Every 2 years you need to get promoted and become a Project Manager very soon".

And once you become a Project Manager, you should become a Delivery Manager and then an Account Manager and then...It depends on tall the corporate ladder and how wide it is....

This phenomenon is affecting the whole technology arena. The IT Services industry in India wants an engineer to transform from an "Innovate-new-things-guy" to a "Get-things-done-guy". An "Innovate-new-things-guy" has a lot of technology background and a "Get-things-done-guy" has a lot of management background. I would say the latter is the Supply part of the equation and the former is the demand part of the equation. And the equation needs both the parties. Somehow our IT Services managers are causing an imbalance to this equation by drying up the "Technology pool".

There is never stagnation in the technology pool, because technology itself is not stagnant. Do doctors get stagnated? They sit in the same chair for years and years and do the same kind of diagnosis, though every case would have its own complication.

There is always a career for specialization.

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

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?