Tag: insights

The Trouble with Management Consulting

While I was pumping iron (I know, I know!!) at the gym on Wednesday evening, I got a call from a client seeking to confirm our meeting yesterday afternoon. “Why don’t you put together a presentation with all the insights you’ve gathered so far?”, he suggested, adding that he was planning to call a few more stakeholders to the meeting and it would be good to give them an insight into what is happening.

Most of my morning yesterday was spent putting together the presentation, and I’m not usually one who bothers that much about the finer details in a presentation. As long as the insights are in place I’m good, I think. I had also worked late into the night on Wednesday trying to refine some algorithms, the result of which were to go into the presentation. In short, the client’s request for the presentation had turned the 18 hours between the phone call and the meeting topsy-turvy.

It is amazing how many people expect you to have a powerpoint (or Keynote) presentation every time you walk into a meeting with them. For someone like me, who doesn’t like to prepare power points unless there are specific things to show, it can get rather irritating. Some presentations are necessary, of course, like the one to the CEO of another client that I made last Thursday. What gets my goat is when people start expecting powerpoints from you even at status update meetings.

Preparing presentations is a rather time-consuming process. You need to be careful about what you present and how you present it. You need to make sure that your visualizations are labeled well and intuitive. You need to sometimes find words to fill slides that would otherwise appear empty. And if you are not me, you will need to spend time with precise and consistent formatting and dotting the is and crossing the Ts (I usually don’t bother about this bit, even in presentation to the CEO. As long as content is there and is presentable I go ahead).

So when you have to make presentations to your clients regularly, and at every status update meeting, you can only imagine how much of your time goes into just preparing the presentations rather than doing real work!

The other resource drain in the consulting business is working from client site. While it is true that you get massive amount of work done when you are actually there and have a much shorter turn around time for your requests, spending all your time there can lead to extreme inefficiency and lack of thought.

When you spend all your time at the client site, it invariably leads to more frequent status updates, and hence more presentations and thus more time spent making presentations rather than doing real work. The real damage, though, is significantly more. When you spend all your time at your client’s site, it is easy to get drawn into what can be called as “client servicing mode”. Since you meet the client often, you will have to update him often, and you are always looking for something to update him every time you need to meet him.

Consequently, you end up putting on yourself a number of short deadlines, and each day, each hour, you strive to simply meet the next short deadline you’ve set for yourself. While this might discipline you in terms of keeping your work going and make sure you deliver the entire package on time, it also results in lack of real thinking time.

Often when you are working on a large project, you need to take a step back and look at the big picture and look at where it is all going. There will be times when you realize that some time invested in simply thinking about a problem and coming up with a “global” solution  is going to pay off in the long run. You will want to take some time away from the day-to-day running so that you can work on your “global” solution.

Unfortunately a client servicing environment doesn’t afford you this time. Due to your constant short deadlines, you will always end up on a “greedy” path of chasing the nearest local optimum. There is little chance of any kind of pathbreaking work that can be done in this scenario.

In my work I have taken a conscious decision to not visit my client’s office unless it is absolutely necessary. Of course, there are times when I need to expedite something and think being there will increase my own efficiency also and spend time there. But at other times, when I”m away, here in Bangalore, the fact that there are times when there are no immediate deadlines also means that I get the time to invest on “global” thought and on developing ideas that are long-term optimal.

The long-term productivity that emerges from spending time working off-site never ceases to amaze me!

Data Science and Software Engineering

I’m a data scientist. I’m good with numbers, and handling large and medium sized data sets (that doesn’t mean I’m bad at handling small data sets, of course). The work-related thing that gives me most kicks is to take a bunch of data and through a process of simple analysis, extract information out of it. To twist and turn the data, or to use management jargon “slice and dice”, and see things that aren’t visible to too many people. To formulate hypotheses, and use data to prove or disprove them. To represent data in simple but intuitive formats (i.e. graphs) so as to convey the information I want to convey.

I can count my last three jobs (including my current one) as being results of my quest to become better at data science and modeling. Unfortunately, none of these jobs have turned out particularly well (this includes my current one). The problem has been that in all these jobs, data science has been tightly coupled with software engineering, and I suck at software engineering.

Let me stop for a moment and tell you that I don’t mind programming. In fact, I love programming. I love writing code that makes my job easier, and automates things, and gives me data in formats that I desire. But I hate software engineering. Of writing code within a particular system, or framework. Or adhering to standards that someone else sets for “good code”. Of following processes and making my code usable by some dumbfuck somewhere else who wouldn’t get it if I wrote it the way I wanted. As I’d mentioned earlier, I like coding for myself. I don’t like coding for someone else. And so I suck at software engineering.

Now I wonder if it’s possible at all to decouple data science from software engineering. My instinct tells me that it should be possible. That I need not write production-level code in order to turn my data-based insights into commercially viable form. Unfortunately, in my search around the corporatosphere thus far, I haven’t been able to find something of the sort.

Which makes me wonder if I should create my own niche, rather than hoping for someone else to create it for me.

Arranged Scissors 15: Stud and Fighter Beauty

Ok so here we come to the holy grail. The grand unification. Kunal Sawardekar can scream even more loudly now. Two concepts that i’ve much used and abused over the last year or so come together. In a post that will probably be the end of both these concepts in the blogging format. I think I want to write books. I want to write two books – one about each of these concepts. And after thinking about it, I don’t think a blook makes sense. Too  many readers will find it stale. So, this post signals the end of these two concepts in blog format. They’ll meet you soon, at a bookstore near you.

So this post is basically about how the aunties (basically women of my mother’s generation) evaluate a girl’s beauty and about how it significantly differs from the way most others evaluate it. For most people, beauty is a subjective thing. It is, as the proverb goes, in the eyes of the beholder. You look at the thing of beauty (not necessarily a joy forever) as a complete package. And decide whether the package is on hte whole beautiful. It is likely that different people have different metrics, but they are never explicit. Thus, different people find different people beautiful, and everyone has his/her share of beauty.

So I would like to call that as the “stud” way of evaluating beauty. It is instinctive. It is about insights hitting your head (about whether someone is beautiful or not). It is not a “process”. And it is “quick”. And “easy” – you don’t sweat much to decide whether someone is beautiful or not. It is the stud way of doing it. It is the way things are meant to be. Unfortunately, women of my mother’s generation (and maybe earlier generations) have decided to “fighterize” this aspect also.

So this is how my mother (just to take an example) goes about evaluating a girl. The girl is first split into components. Eyes, nose, hair, mouth, lips, cheeks, symmetry, etc. etc. Each of these components has its own weightage (differnet women use different weightages for evaluation. however for a particular woman, the weightage set is the same irrespective of who she is evaluating). And each gets marked on a 5-point likert scale (that’s what my mother uses; others might use scales of different lengths).

There are both subject-wise cutoffs and aggregate cutoff (this is based on the weighted average of scores for each component). So for a girl to qualify as a “CMP daughter-in-law”, she has to clear each of the subject cutoffs and also the total. Again – different women use different sets of cutoffs, but a particular woman uses only one set. And so forth.

I wonder when this system came into being, and why. I wonder if people stopped trusting their own judgment on “overall beauty” because of which they evolved this scale. I wonder if it was societal pressure that led to women look for a CMP daughter-in-law for which purpose they adopted this scale. It’s not “natural” so I can’t give a “selfish gene” argument in support of it. But I still wonder. And my mother still uses scales such as this to evaluate my potential bladees. Such are life.

Don’t use stud processes for fighter jobs and fighter processes for stud jobs

When people crib to other people that their job is not too exciting and that it’s too process-oriented and that there’s not muc scope for independend thinking, the usual response is that no job is inherently process-oriented or thinking-oriented, and that what matters is the way in which one perceives his job. People usually say that it doesn’t matter if a job is stud or fighter, and you can choose to do it the way you want to. This is wrong.

So there are two kinds of jobs – stud (i.e. insight-oriented) and fighter (i.e. process oriented). And you can do the job in either a stud manner (trying to “solve a problem” and looking for insights) or in a fighter manner (logically breaking down the problem, structuring it according to known formula and then applying known processes to each sub-problem). So this gives scope for a 2 by 2. I don’t want this to look like a BCG paper so I’m not actually drawing a 2 by 2.

Two of the four quadrants are “normal” and productive – doing stud jobs in a stud manner, and fighter jobs in a fighter manner. There is usually an expectancy match here in terms of the person doing the job and the “client” (client is defined loosely here as the person for whom this job is being done. in most cases it’s the boss). Both parties have a good idea about the time it will tak e  for the job to be done, the quality of the solution, and so on. If you are in either of these two quadrants you are good.

You can’t do a stud job (something that inherently requires insight) using a fighter process. A fighter process, by definition, looks out for known kind of solutions. When the nature of the solution is completely unknown, or if the problem is completely unstructured, the fighter behaves like a headless chicken. It is only in very rare and lucky conditions that the fighter will be able to do the stud job. As for “fighterization”, about which I’ve been talking so much on this blog, the problem definition is usually tweaked slightly in order to convert the stud problem to a fighter problem. So in effect, you should not try to solve a “stud problem” using a fighter process. Also, as an employer, it is unfair to expect a mostly fighter employee to come up with a good solution for a stud problem.

The fourth quadrant is what I started off this blog post with – studs doing fighter jobs. The point here is that there is no real harm in doing a fighter job in a stud manner, and the stud should be able to come up wiht a pretty good solution. The problem is wiht expectations, and with efficiency. Doing a fighter job in a stud manner creates inefficiency, since a large part of the “solution” involves reinventing the wheel. Yes, the stud might be able to come up with enhanced solutions – maybe solve the problem for a general case, or make the solution more scalable or sustainable, but unless the “client” understands that the problem was a stud problem, he is unlikely to care for these enhancements (unless he asked for them of course), and is likely to get pained because of lack of efficiency.

Before doing something it is important to figure out if the client expects a stud solution or a fighter solution. And tailor your working style according to that. Else there could be serious expectation mismatch which can lead to some level of dissatisfaction.

And when you are distributing work to subordinates, it might also help to classify them using stud nad fighter scales and give them jobs that take advantage of their stronger suits. I know you can’t do this completely – since transaction costs of having more than one person working on a small piece of work can be high – but if you do this to the extent possible it is likely that you will get superior results out of everyone.

Bangalore trip update

The recent inactivity on this blog was mainly due to my inability to log on to wordpress from my phone and write a post.  I had gone home to Bangalore for an extended weekend (taking Friday and Monday off) and the only source of net access there was my phone, and for some reason I wasn’t able to log on to NED from that. During the trip I had several brilliant insights and brilliant ideas and wanted to blog them and finally such NED happened that I didn’t even twitter them. Deathmax.

The main reason I went to Bangalore was to attend Pradeep (Paddy)’s reception. I think this is an appropriate time to share the funda of his nickname with the world. Before he joined our school in 9th standard, there was this guy two years senior called Pradeep, and for some reason not known to me he was nicknamed Paddy. I vaguely knew him since I used to play basketball with him, and after he graduated there were no more Paddys in school. So when this new guy came from the Gelf, it presented a good opportunity to get back a Paddy into school. It turned out to be such a sticky nickname that not even IIT could change it.

Friday was Ugadi – yet another reason to be home in Bangalore – and was mostly spent visiting relatives. When they heard about my impending market entry, all of them brought up stories of not-so-successful marriages of people they knew well, and put fundaes to me about avoiding certain pitfalls. These fundaes were liberally peppered with stories. Mostly sad ones. Mostly of people who have chosen to continue in their marriages despite them clearly failing. It is amazing about the kind of stuff people I know have gone through, and yet they choose to not run away.

Saturday morning was rexerved for my first ever “market visit”. I was taken to this bureau in Malleswaram and asked to inspect profiles. “There are profiles of hundreds of girls there”, my uncle had told me “so let us go there before ten o’clock so that you have enough time”. The profiles were mostly homogeneous. The number of engineering seats available in Karnataka amazes me. Every single profile I checked out over there had studied a BE, and was working in some IT company. Things were so homogeneous that (I hate to admit this) the only differentiator was looks. Unfortunately I ended up shortlisting none of them.

One of the guys I met during my Bangalore trip is a sales guy who lives in a small temple town without any access to good cinema. So he forced me to accompany him to watch Slumdog (in PVR Gold Class – such an irony) and Dev D. I agree that Slumdog shows India in poor light, but filter that out and it’s a really nice movie. We need to keep in mind that it was a story and not a documentary, and even if it were the latter, I think documentaries are allowed to have narratives and need not be objective. Dev D was simply mindblowing, apart from the end which is a little bit messed up. Somehow I thought that Kashyap wanted to do a little dedic to his unreleased Paanch.

There is this meet-up at Benjarong which is likely to contribute enough material to last six arranged scissors posts. I’ll probably elaborate about the discussions in forthcoming posts but I must mention here that several arranged marriage frameworks were discussed during the dinner. The discussions and frameworks were enough to make both Monkee and I, who are in the market process, and Kodhi who will enter the market shortly to completely give up in life.

One takeaway from Paddy’s reception is that if you can help it, try not to have a “split wedding” (and try not to have a split webbing also) – where different events are held at diferent venues, on disjoint dates. In that case you won’t have people lingering around, and you will lose out on the opportunity to interact with people. Note that there is zero scope for interation during the ceremonies, and the only time you get to talk to people is before, and after, and during. And it is important that there is enough before or after or during time to allow these interactions. In split weddings guests are likely to arrive and leave in the middle of an event and so you’ll hardly get to talk to them.

One policy decision I took was to not have breakfast at home during the length of my stay. I broke this on my last day there since I wouldn’t be having any other meal at home that day, but before that visited Adigas (ashoka pillar), SN (JP nagar) and UD (3rd block). The middle one was fantastic, the first reasonably good except for bad chutney and the last not good at all. Going back from Gurgaon it was amazing that I could have a full breakfast (2 idlis-vada-masala dosa-coffee) for less than 50 bucks. Delhi sorely lacks those kind of “middle class” places – you either eat on the roadside or in fine dining here.

Regular service on this blog should resume soon. My mom has stayed back in Bangalore for the summer so I’m alone here  and so have additoinal responsibilities such as cooking and cleaning. However, I think I should be having more time so might be writing more. I can’t promise anything since blog posts are generated by spur-of-the-moment thoughts and I never know when they occur. Speaking of which I should mention that I put elaborate fundaes on studs and fighters theory in my self-appraisal review form last week.

Fighter Batsmen and Stud Bowlers

Insight of the day: Batting is inherently fighter and bowling is inherently stud. Of course there are severral stud batsmen (eg. Sehwag) and fighter bowlers (eg. Giles) but if you look at it broadly – a batsman needs to get it right every ball, while a bowler needs only one ball to succeed.

The fundamental idea is that bowling success can be more lumpy than batting success – for example the maximum that a batsman can do if he has one great over is to score 36 runs – whcih in the context of the average game won’t amount to much. However, if a bowler has one great over and picks up six wickets, the impact is tremendous.

The bowler can afford to be much more inconsistent than the batsman. He might get a few balls wrong, but he can suddenly make an impact on the game. For a batsman to have a significant impact, however, he should be able to carry it on for a significant amount of time. An “impulse”  (a large force acting for a small time period) will do the batting team no good, while it can be a tremendous boost for the bowling team. On the other hand, steady unimaginative play by the batsman is good enough, while a bowler needs to necessarily show patches of spectacularity to have an impact.

Hence, batting is fighter and bowling is stud.

However, what the advent of one day cricket has done is to invert this. By limiting the number of overs, and creating conditions where a team need not be bowled out, it has turned things upside down. Of course, a stud performance by a bowler (say a hat-trick) can have a significant impact on the game, but inconsistent and wayward bowling is likely to cost the bowling team significantly more than it does in Test cricket.

Similarly, with the game getting shorter, an impulse by the batsman (say a quick 40 by Sehwag) has a much larger impact on the game than it does in Test cricket. And on the other hand, dour batting  – which is so useful in Tests – may actually be a liability in ODIs. Similarly the mantra for bowlers has become containment, and thus fighterness in bowlers has a greater impact – and so people now do respect bowlers who can bowl long spells without taking wickets, but just containing.

Remember that even now, to succeed in Test cricket, you need to have the correct characteristic – Sehwag’s batting might appear stud and risky, but he has the ability to play really long innings which is why he is a really good Test batsman. If he didn’t have the “longevity gene”, he would’ve still remained a one-day wonder. Yes – now teams do pick a fourth bowler to do the “holding role” – keeping one end tight while others attack. Still, the holding guy needs to have some ability to pick up wickets by himself.

Preliminary reading on studs and fighters theory:

Studs and Fighters

Extending the studs and fighters theory

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.

On how blogs have changed the way I look at books

I have more than a hundred feeds on my Google Reader. It could be much more, just that I haven’t bothered to keep track. Apart from these hundred odd feeds, I also read posts which have been shared by people on my GTalk friends list. And then, you have people who send you the odd link to some strong post or article, and I usually end up reading them too.

The point I’m trying to drive at is that most of my reading time nowadays is spent reading blogs and news articles and magazine articles. The kind of stuff that promises to offer a strong insight once every 1000 words or so, and usually delivers on that promise. Which, in effect, has spoilt me.

So, in effect, whenever I read something, I end up expecting an insight every few hundred words (no, i’m not that jobless to count words. this is just an approximate estimate). And this is the reason why, I think, I’ve stopped reading fiction. Fiction simply doesn’t offer the same kind of insights that blogs do. Yes, stories can be insightful. They do help you learn stuff. They definitely help you “develop as a person”. But if they are longer than a few hundred words (i still have appetite for short stories), they end up boring me. I quickly lose interest. I find no point in reading them.

Whenever I look at a book now, I end up comparing the experience to reading blogs. I see if the book can promise insight at the same rates that blogs can. Which is why I hate single-idea books. i had recently read this book called Why Popcorn Costs So much at the movies. My crib with that was that it didn’t offer enough insight for it’s length. What could have been explained in 20 blog posts had been stitched into a book.

In the era before blogs, such books made sense. There was no quick fix way to get insights, and you would be willing to plough through long books in order to get some insights. And for the author, there was no quick and profitable way of disseminating insights – he was forced to write long books. It was a sustainable market.

Blogging seems to have changed all that. There is a quick and possibly profitable way of disseminating informationn. There is a quick and easy way of receiving it. Some books that were great ideas in an earlier era simply can’t hold up now. In these times, if you are to write a book, you need to make sure that there is actually enough material to hold up all the pages that it’s written on. That even if the main idea can’t hold for so long (it usually can’t), you put in enough sub-plots and side-stories to sustain it.

I want to write books some day. Maybe even take that as a full-time profession – though it’s too early to call on that. However, when I do get down to writing this, I need to keep this concept in mind. That I will need to fill the book with enough insights to sustain it.

PS: i don’t feel the same about movies. I don’t mind the slow buildup and long periods where nothing happens at all. maybe it’s because the movie lasts only about two odd hours in its entirety.