Showing posts with label management. Show all posts
Showing posts with label management. Show all posts
| 1 comments ]


Animesh » Blog Archive » Who is your employee?
Animesh has an interesting post on it. I've added my thoughts here:

I think the family model is very well suited to a startup, mostly
because it is almost a necessity: in a startup, the boundary lines
between work and home and not well defined. In my experience, it is
true even if not all employees are white collar workers.


But keeping the same model as the company evolves into a bigger
organisation is probably not suitable and not feasible. You *want*
people to clearly delineate their professional and personal lives for a
better balance. And the returns to all stakeholders from the family
model become much lower.


Treating employees as customers is definitely the way to go. To me,
there is no other option. At least for the support functions, it should
be obvious that the rest of the organisation is their customers,
because, well, what else are they supporting?


Unfortunately, at least in India, that is often not the case.
Support functions often run as their own fiefdoms, and I think that
often goes on because the executive team doesn’t pay much attention to
them. I think the way to resolve this is to measure performance based
on customer feedback, as for the ‘core’ function. (But that’s
digressing…)



| 1 comments ]

Just read the cover story of Business World of 6th Feb. They have rated the top 25 places to work at in India. Across industry sectors. Here are some excerpts I found interesting ( in that I've been trying to get some of these through at my workplace.) Here's some validation that these things do happen in India.

Many of the organisations in our list have unlimited sick leave, no attendance recording system and self-supervision as the norm.

True collaboration goes beyond employees setting the menu for the canteen… It requires an ability to share 'real power', as is reflected in RMSI's decision to empower employees to calculate their own performance bonuses.

Sasken prides itself on its 'single status' policy… All employees, including the co-founder, and eligible for the same travel benefits.

Amex… shares details of the salary ranges, how these were evolved and what comparator companies were used to determine them.

There is a direct relation between great places to work and superior financial performance…. During the period 1998-2002, an annually updated index of Fortune's 100 best companies to work for would have yielded a return of 9.86%, compared to -0.56% from the S&P 500.

(This one, of course, is US data)

At RMSI, when negotiating with those who leave, managers are forbidden from offering higher salaries as an incentive to stay back. At best, they can offer a different assignment or more responsibilities.

At JW Mariott, revenue and profit and loss figures are shared with all employees across levels, eve dishwashers.

At Aztec, to engage employees, CEO… sends out regular emails to them that are presonal, inspirational, and at times, even philosophical.

Sapient's senior-most bosses, its two managing directors, do not have their own rooms. Seriously. They do not even have their own cubicles or work stations.

At PSI Data Systems, employees were constantly kept updated of the company's true financial picture, orders that were in the pipeline and stragies that would change the company's performance. ( Even when the company was in the red.)

| 3 comments ]

A few days back, in an internal management forum, we were talking about the increasing attrition and importance of retaining people. One of the PMs talked about how a few people in his team asked him " Why should we stay?"


That's really it. That's what we need to answer. If we don't have an answer to that (besides the nonsense about it being a challenge, and a fast growing oganisation etc.), then we don't have much of a chance.

What are the reasons for people to stay? Or, what do people look for? Here's the regular list:
  • Compensation: includes salary and stock options
  • Quality of work
  • Role
  • Quality of life ( relates to work life balance and the city you work in)
  • Brand
Let's consider a small services organisation that does not have the best pay scales, does not have much to offer in terms of work content, and where teams often come under schedule pressure. Is obviously not a recognized brand, and is located in Chandigarh ( Great quality of life, but not very relevant to most of the target employee group.)

What does such a company do ? Does it have no hope?

I think it does. It can do one thing that is relatively easy for a small organisation to do, and which can potentially make a big impact on employees, (although probably none on prospective employees.)

Try and be the best place to work at.

That's it. Everything else pretty much follows. I think one can start by putting together a few guiding principles. Use them to check each action and policy: if they don't fit into the principles, then they are acceptable. Here are some that I believe would be good ones:

  1. The small guy always wins: Whenever a decision can go both ways, err on the side of the employee. When creating a policy, use one that leans towards the employee.
  2. Believe in people: Create policies based around faith in people. Assume that people are honest. In most cases, they are, and the few dishonest instances will be far outweighed by the benefits of faith. For instance, don't count leaves from attendance on a daily level: just inform the manager on a monthly level, and let the manager take a call. If an employee asks for the ability to make business calls from home, accept that she needs it.
  3. Be pound wise, penny foolish: Don't bother with small expenses. A 200% hike in a shoelace price means nothing compared to a 1% hike in the shoe price. Don't put a tight control on RAM purchases while not controlling PC purchases.
  4. Don't always be an accountant: Not everything needs to fit exactly. If a team party budget is Rs. 300 per person per quarter, it is OK for it to go above 300 once in a while: it will balance out on the whole. (Other projects will use less. If everyone is using more, perhaps the budget needs to be increased.) If a little above 300 is not OK, people will ensure they never let it be a little below 300 either: they will use all of it!
  5. Communicate: Provide people information. Where are we, where are we going, how are we doing. Perhaps revenue and profit numbers. Definitely new accounts, new initiatives. Have executive management address people once in a quarter, send out mails regularly. Ask for feedback. Act on feedback. Keeping people informed encourages the belief that they matter.
  6. Empower: Involve people in decisions. Allow them to suggest and take ideas to completion. For a small company, having entrepreneurial employees is essential. You will keep them only if you empower them.
  7. Be open: Believe in transparency. If you have a cost constraint, admit it. Share with people the logic of decisions.
  8. What others do is not important: Don't look at what other companies are doing: that will at best make you the average. Do what fits in with your guiding principles. If you must compare, compare with the employers that top the employee satisfaction charts!





| 2 comments ]

Obviously, I'm not talking about motorcycles or cars :-)

I was having a chat last week about setting up a new office, and I was asked if a software services firm could go from 0 to 100 in 2 months in Chandigarh. I said no, and that 4 months was possible, adding that it might be possible in Delhi.

This was all on a hunch. Later, I started thinking about what would it take. Let's see. First, let's start on the less ambitious goal of making 100 offers in 2 months. I'll make the following assumptions:

  • We pay at the 60th percentile
  • We do at most 2 rounds of tech interviews, and most people who get to the 2nd round are selected.
  • We work only weekdays.
  • 1 in 5 candidates who get to round 1 get selected.
  • 1 in 5 candidates the recruiters talk to get to round 1.
  • 1 in 5 resumes recruiters look at are called up.
Here are some numbers:
  • 100 offers in 2 months mean 2.5 offers a day.
  • 2.5 offers a day = 3+ 2.5*5 = 16 interviews a day = 80 screenings a day
  • 16 interviews daily mean at least 7 interviewers
  • 80 screenings mean at least 7 recruiters
  • In all, over 2 months, talking to 3200 candidates, and sourcing 16000 resumes!
If the recruiters can generate this sort of number, it doesn't look so bad.

Now let's see how this converts to offers accepted and joinings.

  • Not more than two thirds of the people you make an offer to will join. This includes people who reject the offer and people who accept but do not turn up.
  • To end up with a pipeline of 100 joinings, you need to therefore do about half as many interviews more than you needed to for 100 offers.
  • That takes the total interviewers to 11, and recruiters to 11 as well.
If you're starting from zero, it gets worse, because it takes a while to recruit your interviewers! But let's say you already have 100 employees. It would be a scramble, but you just might be able to make 11 interviewers out of them.

Take the target to 4 months, and things start to look a little easier: you need only 6 interviewers and recruiters, with the time lag also providing bandwidth to do other stuff, like running the business, training people, building the brand, etc.

Do the numbers sound feasible ?

| 2 comments ]

I've seen this in a lot of organisations: they 'pro-rate' salary revisions. The latest, of course , was an internal policy about pro-rating increments based on when the employee's anniversary appraisal took place. Here's what it means:

Say the salaries are revised every Decemeber. If I joined in March, and in December the company decides that I should move to a 10% higher salary, I actually get a 7.5% hike. (10%*)9/12.

To me, this makes absolutely no sense. I can see that you would want to do it for bonuses that are linked to company performance, project success and individual performance, because the employee's contribution was limited by the period she was there.

However, for salaries, the same does not apply. After all, what is a salary revision exercise? It is about revising salaries to make sure that they are in-line with your wage bill goals, keeping in mind the following factors:

  • market rates, and your company's positioning
  • the wage bands for various levels in your organisation ( which would have been redefined by the new hires in the last year)
  • review of the employee: past performance, future projections, potential
  • the employee's value to the organisation.
  • and perhaps, where the employee is currently at.
So, a salary revision, in my mind, is not about deciding a percentage hike: it is about deciding a target number. You first get to that number, and then work out the percentage from there.

If you do it that way, which I think is really done everywhere, where's the logic for pro-rating? At any point that you are revising a salary, you revise it to the 'right' number based on the factors listed. The fact that the employee has spent only 9 months with the company, or that he had got a revision only 6 months back, is of no relevance to the number that is 'right' today.

Following a percentage hike approach also results in communicating it the same way to the employees, which has the following problems:
  • it fosters and shows a mindset where salary hikes(revisions) are treated as perks/rewards, rather than adjustments.
  • it encourages comparisons between employees by employees. People can compare in any case: converting into percentages is easy. However, with the percentage approach, you are inviting them to compare.
There's only argument I've seen in favour of pro-rated revisions. I consider it a weak argument, for reasons outlined below, but even then, it works only in situations where you're on a secular hike path - that is, ALL revisions are hikes. Which is mostly true today, but doesn't make for a good policy because it is a temporary situation.

Here's that argument:
- people who joined or got a hike less than a year back, got the 'advantage' of a revision early, while the other employees wait till the next revision.

And here's my counter:
  • How do you know what part of this person's 'higher' salary is due to change in market, and what part is due to his skillset?
  • The right number today does not change by that fact. Remember that this person would then also be 'below' the right number for a full year. So if you have to pro-rate, the right approach would be to ensure that the 'gain' this person got is dissipated in the next 12 months. If you just pro-rate it, this employee ends up losing over the total period to next year. But doing this kind of math is probably impractical.
  • If the salary situation is changing at such a fast clip that you are think pro-rating is needed to balance it, then you should think about doing salary revisions at six monthly intervals rather than annually. ( You probably anyway end up doing that on a ad-hoc basis, for reasons such as managing attrition.)
  • If the new person is getting this extra advantage, remember that he is also losing because of the switch - he will need to invest in establishing himself again at a new place, with new people.
  • Even if you want to pro-rate, don't present it as such. Use that as one more factor when calculating the number, and tell the employee the number along with the various factors.
So, my plea: Don't talk of percentages when revising salaries!

| 2 comments ]

Here are some thoughts I shared with my development teams yesterday. ( I work in a software services firm based out of Chandigarh, India). Some of these might be unique to my organisation, but some are definitely very common in the Indian services industry, specially the first one.

These few thoughts, to me, are the undercurrents beneath a number of issues and problems that we keep getting into at work.

Does this sound familiar ?

The customer is better than us: (also known as the customer is happy with this)

To me, there really is no basis for this, other than perhaps that we are giving the customer what they have done in the past, or what they are happy with. But there are lots of pitfalls in that reasoning. The badly designed code supplied by the customer could have been written by a fired employee/contractor. It could have been written by employees new to the technology when they wrote it. Current team at the customer could be replaced by people who know better. Any customers expect us to be masters of our technologies. At , we have had a customer who knew nothing about junit, so there we no requirements to write junit tests. But he heard about it in a conference, and was rather angry at us for not having suggested its use ourselves. This customer had been very happy till then!

Ultimately, in todays world, most often, most ideas can be argued. And with google, you can also add references to support your position!


2. Everyone here does it this way, so this is right: (also known as: in all my jobs, everyone has done it this way): Your universe is too small here. Try google to find a bigger universe.

A lot of this is also related to #1: most places that you have worked at probably also suffer by number 1, specially as most work in India is maintenance/support work, where you live with what you get.


3. The app already has it this way, so we should continue doing it the same way: Consistency of implementation is important, but not in all situations. Think through whether consistency brings you some advantage beyond just consistency. In most cases, it does not, specially if the existing approach is just bad. Having a consistent style of braces is useful, because it is only a matter of style. But eating up exceptions is plain wrong. I can present other reasons, but I think this should be enough.

4. Ctrl-C Ctrl V, (also known as: Ill copy this design without understanding its context): Sort of self explanatory. We look at a design/implementation approach at one place, and copy it blindly into other contexts. When confronted with a why?, we often only have the answer that this is being used at place x. Thats no answer. If you agree with its use at place x, AND you can argue that x and your place are similar, ONLY then is it a valid answer, otherwise not.

5. Google does not exist (also known as: we cant look for other opinions/ head in the sand/ how do I validate this): Fortunately, google does exist.

6. The problem will go away if I ignore it (also known as: no one else will notice it): unfortunately, someone always does!