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.