Tag: kaam

Theory of comparative advantage and chutiya kaam

Suppose you and me together have to do two tasks A and B. We need to decide who does what (let’s assume that we need to pick one task each). Now I’m a stud and you are a chutiya so I’m better than you at both A and B. So how do we split? It all comes down to the degree to which I’m better than you in each of these tasks. Suppose I’m marginally better than you at A, but significantly better than you at B. Theory of comparative advantage (commonly used to describe international trade) says that I should do B and you should do A – this way, total productivity is maximized. I suppose this makes intuitive sense.

You have a number of people cribbing about what is popularly knonw as “chutiya kaam” – approximately translates to bullshit work. Work that is uninspiring for them, but which they need to do because it needs to be done. Sometimes you have otherwise fairly intelligent and efficient people assigned to chutiya kaam – with the explanation that there is no one else who is well-enough equipped to do it. And these people find that less intelligent nad less efficient people are being given better work.

The reason the more intelligent and efficient person might get the chutiya kaam is that he is better at that than his colleagues, even if he is better than his colleagues in the more intelligent stuff. So I suppose if you want to avoid chutiya kaam altogether, one of the ways of doing it is to prove yourself to be a chutiya at that. To be inefficient and incapable of doing that, and in the hope that it will then get palmed off to someone else who is perceived to be better.

But then this is a double edged sword. There are people who believe that all kinds of “chutiya kaam” are inferior to all non-chutiya kaam. And that if you are not good at chutiya kaam you cannot be good at everything else. I’m reminded of this guy in my class who was captaining the class team for a day and who refused to let me open the bowling because I’d dropped a catch. “You can’t even catch properly, and how can you expect to bowl?” he had asked.

The unfortunate thing is that a large number of people are like this. They refuse to accept that chutiya and non-chutiya kaam are not comparable, and require different skill sets, and that they will neeed to apply trade theory to figure out who does what. They look at your skills in one and use that to judge you in another. And allocate resources suboptimally. And when faced with this kind of people, the strategy of trying to be chutiya at chutiya kaam may not work.

So I suppose the key is to figure out what kind of person your boss is. Whether he appreciates that different jobs can take different skills, and no one job “dominates” another. And whether he applies trade theory when it comes to work allocation. If the former, you can’t really do anything. If the latter, you can try being chutiya at chutiya kaam.

Postscripts

“chutiiya kaam” is not a homogeneous term. Some jobs are chutiya for some people but non-chutiya for others. It varies from person to person.

I have grouped all “chutiya kaam” together just for the sake of convenience. There are differnet kidns of chutiya kaams and all of them require different skill sets.

Each non-chutiya kaam also requires its own skill set. I’ve again grouped them together for the sake of convenience of argument

I firmly believe that principles of economics that can be useful in real life (such as demand and supply, trade theory, game theory, etc.) should be part of the 10th standard economics syllabus, rather than teaching kids to mug up GDP growth rates for different states for different decades

I have resisted the temptation to bring in the studs and fighters theory into this analysis

Process

A couple of days back, I was debugging some code. And yes, for those of you who didn’t know, coding is a part of my job. I used to have this theory that whatever job you take, there is some part of it that is going to be boring. Or to put it in the immortal words of a brilliant co-intern at JP Morgan “chootiya kaam”. And in my job, the chootiya part of the kaam is coding. That doesn’t mean that I’m not enjoying it, though. In fact, for the first time in nine years (note that this takes me to a time before I’d started my BTech in Computer Science) I’m enjoying coding.

Coming back, I was debugging my code yesterday. It was one of those impossible bugs. One of those cases where you had no clue why things were going wrong. So I started off by looking at the log files. All clean, and no bugs located. While I was going through them, I got this idea that the strategy sheet might offer some clue as to why things aren’t doing well. Half the problem got diagnosed when I was looking at the strategy sheet. Some problem with cash management.

And when I thought looking at the trades might help. The bug was presently discovered. And then it hit me – that I’d unwittingly followed what seems like a “process”. Everything that I did had been guided by insight and instinct. Yet, the steps that I followed – 1. look at the logs; 2. look at the strategy sheet ; 3. look at the trades – seemed so much a preset process. It seemed to be like one of those things that I’d just ended up reading in some manual and following.

I realize that most “standard processes” that are followed by  various people in various places are stuff that were initially not meant to be processes. They were just an imprint of somone’s train of insights. It was as if someone had a series of insights that led to a solution to whta might have been a difficult problem. And then, he realized that this kind of a process could be followed to deal with all such similar problems. And so he wrote down the process in a book and taught a set of people to implement them. The field thus got “fighterized“.

The argument I’m trying to make here is that a large number of so-called “standard processes” are just an imprint of someone’s insight. They just happened to get into place because the inventor noticed this pattern in a bunch of things that he was doing. They need not be the best way of doing what is supposed to be done. Maybe there isn’t even a single best way of doing it that might work every time.

People who are likely to have worked on processes later in their life cycle are likely to have been people who are process-oriented themselves, and given how these kind of people work, it would have been likely that they would have resisted changes that could make the process worse in the short term. They are more likely to have been incremental in their approach. With a succession of such people working on improving the process, the process of refining the process would’ve ended up taking a hill-climbing algorithm and is likely to have ended up in a local maximum.

Once again, the large changes to the process would’ve happened when someone who was willing to take a large step backward worked on them, and it is again likely that such a person would be driven more by insight rather than by process.

My hypothesis is that most processes are likely to have been largely defined by people who are themselves not very process-oriented, and who thus will expect a certain level of insight and discretion on the part of the person implementing the process. And one needs to keep this in mind while following processes. That it would be good if one were to take a critical view of every process being used, and not be afraid to take a backward step or two in process development in order to achieve large-scale improvements.