Tag: headless chicken

Planning and drawing

Fifteen years ago I had a chemistry teacher called Jayanthi Swaminathan. By all accounts, she was an excellent teachers, and easily one of the best teachers in the school where she taught me. Unfortunately I don’t remember much of what she taught me, the only thing I remember being her constant refrain to “plan and draw” while drawing orbital diagrams (I’ve forgotten what orbital diagrams look like).

Now, I remember wondering why it was that big a deal that she kept mentioning “plan and draw” while drawing or asking us to draw such diagrams. This question answered itself a few days later at my JEE factory, where the chemistry teacher started drawing an orbital diagram which soon threatened to go outside the blackboard. A friend who was sitting next to me, who was also from my school, quipped “this guy clearly didn’t plan and draw”.

The reason I’m mentioning this anecdote here is to talk about how, when faced with a deadline, we start running without realising what we are doing. I can think of a large number of disastrous projects from my academic and professional life (till a couple of years back my academic and professional life was rather disastrous), and looking back, the problem with each of them was that we didn’t “plan and draw”.

I especially remember this rather notorious “application exercise” as part of my marketing course at IIMB (btw, since the wife is doing her MBA now I keep getting reminded of IIMB quite frequently). We had a problem statement. We had a deadline. And we knew that the professor demanded lots of work. And off we went. There was absolutely no coherence to our process. There was a lot of work, a lot of research, but in hindsight, we didn’t know what we were doing! Marketing was my first C at IIMB (and the only C in a “non-fraud” course, the other being in a rather random course called Tracking Creative Boundaries).

Then I remember this project in my second job. “Forecast”, I was told, and asked to code in java, and forecasting I started, in java, without even looking at the data or trying to understand how my forecasts would solve any problem. Six months down, and forecasting going nowhere, I started coding on Excel, looked at the data for the first time, and then realised how hard the forecasting was, and how pointless (in context of the larger problem we were trying to solve).

There are several other instances – see problem, see target, start running – like the proverbial headless chicken (as made famous by former Indian ambassador to the US Ronen Sen). And then realise you are going nowhere, and it is too late to do a fresh start so you put together some shit.

That piece of advice I received in chemistry class 15 years back still resonates today – plan and draw (pun intended if you are in a duel). Its is okay to take a little time up front, knowing that you will progress well-at-a-faster-rate once you get started off. You need to understand that most projects follow the sigmoid curve. That progress in the initial days is slow, and that you should exploit that slowness to plan properly.

Sigmoid Curve

I will end this post with this beautiful video. Ilya Smyrin versus Vishwanathan Anand. Semi-finals of the PCA candidates tournament in 1994 – the tournament that Anand won to face off with Garry Kasparov at the WTC. Anand, playing black, gets only five minutes to play the whole game. Watch how he spends almost a minute on one move early on, but has planned enough to beat Smyrin (Anand only required a draw to progress, given the rules).

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.