Millennials are a different breed. Those of us in our 40’s, 50’s and 60’s find them difficult to understand. They are evasive, like to avoid conflict, and job hop like crazy, especially at BPO organizations. On a brighter note, they care about social causes — at least until their short attention span fades and then they care about something else.
In America, millennials jump from job to job. But, in India, the problem is even worse. People who work at BPO programming houses jump boat so often, their management structure was designed to accommodate this type of behavior. Programmers in India are seen as being replaceable parts.
If you are working on a serious project involving ten programmers and Rahul jumps boat because he got a better job offer at another company, it might take a while for another programmer to get up to speed at what Rahul was doing. And if the other programmer doesn’t do the same quality work, or can’t do the work at all, then your entire project could be on the rocks for a while. You could lose a critical client in the mean time because a millennial decided to jump boat on a whim. So, what is the solution?
Screen before using on critical projects
If you are a large programming house, you might have different types of projects. If you have smaller, simpler, less critical projects, and huge team projects, you can choose which programmer you put on which project. If you have someone new, it is advisable to put them on something simple and quick just to see if they do it, and if they can do it, and how punctual they are at meeting deadlines and getting back to people. If a programmer does well on an easy project, you can upgrade them to a more complicated project. However, I would not put anyone on a critical project on salary, here’s why.
Salary just doesn’t work with critical projects, try contracts & bonding
If Ramesh is working on salary on a critical project with a team, the entire team’s work would be compromised if Ramesh drops out. Therefor, it is critical to make sure that Ramesh doesn’t leave the project until it is done, and possibly until bugs are worked out after its completion. The question is, how should you harness Ramesh? Deferred salary is one strategy. If Ramesh gets a small portion of his salary while working on a longer project, but doesn’t get the main payment until its completion, then he would be less likely to quit and begin work for a higher salary down the street at some other hi-tech company. It might also make sense to take it a step further and penalize the programmer for jumping boat as he would not only be failing at his part of the programming, but his failure would influence the timeliness and quality of the final output for all ten programmers as his piece of the puzzle might be critical interfacing with others. Not all programmers would agree to this type of contract, however, without a contract, the programming house is doomed.
Paying more for reliability makes sense
Many BPO companies in India want cheap, but don’t calculate the cost of people leaving. If you add up the damages incurred when a critical player leaves, you might realize that it is cheaper to pay good people more, and also to pay mediocre people more if they can guarantee reliability with a contract and perhaps a bond. Reliability is the key factor in programming project failures — so, if you can eliminate reliability issues such as leaving bugs around, leaving project half-done, and missing deadlines, you can excel as a programming outsourcing company!
A case study from a courier company
I used to work for a courier company when I was fresh out of college. I was started out doing “distribution.” I delivered people’s fake teeth to dentists and back from dentists all over Massachusetts. The work was not ultra-time sensitive and the materials I was handling were not life-threatening if lost. They put me on this type of work until I proved myself. Then, they tested me on time-sensitive work for a few months. After I had proven myself, I was awarded with a route. I went to seven banks in Boston (generally in bad neighborhoods) and delivered the checks to Providence, RI. I was handling millions of dollars in checks every day and had keys to go into banks at night. I actually set off the alarm once (oops!) In any case, the moral of my delivery days story is that I was not put on a critical task until I have proven that I was a reliable and trustable candidate. I was put through two types of reliability tests for months before given any meaningful work. Programming houses need to find some type of short-term work to give to people while they are proving themselves. That way, when someone is put on a critical job, they will be less likely to screw up or leave — especially if they are under a bonded contract!
