Tag: discretion

Stud and Fighter Instructions

My apologies for the third S&F post in four days. However, this blog represents an impression of the flow of thought through my head, and if I try to time my thoughts to suit readers’ interests and variety, I’m afraid I may not be doing a very good job.

I came across this funda in one of the “sub-plots” of Richard Dawkins’s The God Delusion, which I finished reading two days back. Actually, there is another post about the main plot of that book that I want to write, but I suppose I’ll write that some other day, maybe over this weekend. So Dawkins, in some part of the book talks about two different ways of giving instructions. And thinking about it, I think it can be fit into the stud and fighter theory.

I must admit I’ve forgotten what Dawkins used this argument for, but he talks about how a carpenter teaches his apprentice. According to Dawkins, the carpenter gives instructions such as “drive the nail into the wood until the head is firmly embedded” and contrasts it to instructions which say “hold the nail in your left hand and hit it on the head with a hammer held in the right hand exactly ten times”. By giving instructions in the former way, Dawkins argues, there is less chance of the apprentice making a mistake. However, in case the apprentice does err, it is likely to be a significantly large error. On the other hand, with the latter kind of instructions, chance of error is higher but errors are likely to be smaller.

A set of “stud instructions” typically tell the recipient “what to do”. It is typically not too specific, and lists out a series of fairly unambiguous steps. The way in which each of these smaller steps is to be accomplished is left to the recipient of the instructions. Hence, given that each instruction is fairly clear and unambiguous, it is unlikely that the recipient of the instructions will implement any of these instructions imperfectly. What is more likely is that he goes completely wrong on one step, maybe completely missing it or horribly misunderstanding it.

“Fighter instructions”, on the other hand, go deep into the details and tell the recipient not only what to do but also how to do what to do. These instructions will go down to much finer detail than stud instructions, and leave nothing to the reasoning of the recipient. Obviously the number of steps detailed here to do a particular piece of work will be significantly larger than the number of steps that a set of stud instructions. Now, the probability that the recipient of these instructions is likely to make a mistake is much larger, though the damage done will be much smaller, since the error would only be in a small part of the process.

Dawkins went on to give a better example than the carpenter one – consider an origami model of a boat on one hand, and a drawing of a boat on the other. Origami gives a set of precise and discrete instructions. Drawing is as good as a set of “continuous instructions”. Dawkins talks about experiments where kids are made to play a version of “chinese whispers” using the origami and the drawing. I won’t go into the details here but the argument is that the stud instructions are much easier to pass on, and the probability of the tenth kid in line producing a correct model is really high – while in case of a drawing, there is a small distortion at each and every step, so each final model is flawed.

Stud and fighter instructions have their own set of advantages and disadvantages. Fighter instructions require much more supervision than do stud instructions. Stud instructions enable the recipient to bring in his own studness into the process and possibly optimize one or more of the sub-processes. Fighter instruction sets are so-finegrained that it is impossible for the recipient to innovate or optimize in every way. To receive a set of stud instructions, the recipient may need to have certain prior domain knowledge, or a certain level of intelligence. This is much more relaxed in case of fighter instructions.

I personally don’t like supervising people and hence prefer to give out stud instructions whenever I need to get some work done. However, there was one recent case where I was forced to do the opposite. There was this IT guy at my company on contract and I was supposed to get a piece of code written from him before his contract expired. Given the short time lines in question, and given that he didn’t have too much of a clue of the big picture, I was forced to act micro and give him a set of fighter instructions. He has ended up doing precisely what I asked him to do, the only problem being that he has  written code in an extremely inflexible and non-scalable manner and I might have to duplicate his effort since this bit now needs generalization.

I have noticed that a large majority of people, when they have to give out instructions spell it out in the fighter manner. With a large number of micro steps rather than a small number of bigger steps. And until the recipient of the instructions has got enough fundaes to consolidate the set of micro-instructions he has received into a natural set of bigger chunks, it is unlikely that he will either be very efficient or that he will produce stuff that will be flexible. It might also be the case that a large number of people don’t want to let go of “control” and are hence loathe to give out stud instructions.

In the general case, however, my recommendation would be to give stud instructions, but have a set of fighter instructions ready in case the recipient of the instructionss wants things to be more specific.

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.

Arranged Scissors 2

One of the greatest sins in the normal relationship process is tw0-timing. If your statistically significant other figures out that there is yet another other who might also be statistically significant, she is not going to take things lying down. The most likely scenario will be that the yet another other will indeed become statistically siginficant – since the original SSO puts ditch. It might be a stretch but I’ll anyway say that tw0-timing is probably the worst mistake you can commit in the course of a relationship.

The arranged marriage market puts no such constraints. Even if you are ten-timing, people won’t mind. Especially if you are an NRI. The typical NRI process goes like this. Boy lands and is given a “shortlist” – a sheaf of CVs and photos. During the drive home, the shortlist is made shorter. The next day, “interviews” are arranged with each girl in the shorter list, typically at her house. End of the day, after sampling data from various sources, boy picks the one that he thinks will be likely to be most statistically significant in the long term.He takes her out for lunch the next day, puts a ring on her finger the following day and flies off, promising to return in a few months for the wedding. Occasionally, he claims he can’t get leave from his employers for another year and so puts off thaaLi also before he returns to vilayat. Girl can follow him later. For now she’ll follow him on Twitter (sorry, bad PJ).

Local boys don’t have it that lucky. At least, it is unlikely that they ten-time. There are two quirks of the arranged marriage market which pull in opposite directions when it comes to two-timing. On one hand is discretion. You don’t announce that you are “seeing someone” until it’s all fixed and proposal has been made and accepted. Discretion also means that you don’t want to be caught together in public. It also means that you can’t write funny things on each other’s facebook walls. And it obviously rules out PDA – in fact, all forms of DA are strongly discouraged until the contract has been signed. Heck, my cousin was putting DA during her engagement and that led to much gossip and condemnation. So no DA till marriage.

So yeah – one of the “advantages” of this discretion is that it allows you to two-time. What tugs from the other side is the time to decision. Due diligence in the whole process is outsourced, to the bankers. Typically it is finished even before the parties concerned get a chance to  explore each other – and in this, this process differs from the typical M&A process. So now that the due diligence has already been done, bankers prefer that the parties reach a decision quickly.

I don’t know how this happened, but the time to decision is fairly short. In olden days, I’m told that the due diligence was the beginning and end of the deal process. All that the parties had to do was sign. Things slowly improved – to showing photos, to being shown glimpses, to being allowed to talk for two minutes. I don’t know where things stand in terms of the general market, but I’ve been trying to insist on a proper blading process to allow enough time for tiki-taka.

Ok here is the grand unification for this post. The time to decision is a function of discretion and ability to two-time. Given the discretion that has normally been practised (i suppose this came about because societies were tightly knit and small and things would become awkward for all parties involved if each expression of interest were made public), the cost of two-timing became quite low. Thus, in order to make sure that the counterparty is not two-timing their kid, parents started demanding that decisions be made early. This cut both ways – the counterparty’s parents also wanted to make sure their kid wasn’t being two-timed. From the point of view of bankers, the short time-to-deal was an absolute win.

From the point of views of the interested parties, all it did was to increase the incentive for Common Minimum Programmes. Time allotted is generally too short to properly check out the counterparty, and you need to prioritise. You want to check for obvious mistakes. In the short time, you want to make sure that the counterparty is not an obvious misfit. Realizing that you will never have that time to figure out propely if a prospective counterparty has those “spikes”, you settle for someone who “clears the basic cutoffs”.

You thus get yourself a common minimum programme spouse.

Earlier in the series:

Arranged Scissors 1 – The Common Minimum Programme