Tag: insight

Shrinking deadlines

I’m reminded of this old joke/riddle, which also happened to feature in Gowri Ganesha. “If a 1 metre long sari takes 1 hour to dry in the sun, how long will and 8 metre long sari take to dry?”.

The instinctive answer, of course, is 8 hours, while if you think about it (and assume that you have enough clothesline space to not need to fold), the correct answer is likely to be 1 hour.

Now this riddle is completely unconnected to do with the point of the post, except that both have to do with time.

And then one day you find, ten years have got behind you.
No one told you when to run. You missed the starting gun. 

Ok enough distractions. I’m now home, home again.

Modern workspaces are synonymous with tight deadlines. Even when you give a conservative estimate on how long something will take, you get asked to compress the timelines further. If you protest too much and say that there is a lot to be done, sometimes you might get asked to “put one more person on the job and get it done quickly”.

This might work for routine, or “fighter” jobs – for example, if your job is to enter and copy data for (let’s say) 1000 records, you can easily put another person on the job, and the entire job will be done in about half the time (allowing for a little time for the new person to learn the job and for coordination).

As the job gets more complex, the harder it gets. At one level, there is more time to be spent by the new person coming into the job. Then, as the job gets more complex, it gets harder to divide and conquer, or to “specialise”. This means there is lesser impact to the new person coming in.

And then when you get closer and closer to the stud end of the spectrum, the advantage of putting more people to get the work done faster get lesser and lesser. There comes a point when the extra person actively becomes a liability. Again – I’m reminded of my childhood when occasionally I would ask my mother if she needed help in cooking. “Yes, the best way for you to help is for you to stay out of the kitchen”, she would say.

And then when the job gets really creative, there is a further limit on compression – a lot of the work is done “offline”. I keep telling people about how I finally discovered the proof of Ramsey’s numbers (3,3) while playing table tennis in my hostel, or how I had solved a tough assignment problem while taking a friend’s new motorcycle for a ride.

When you want to solve problems “offline” (to let the insight come to you rather than going hunting for it – I had once written about this) – there is no way to shorten the process. You need to let the problem stew in your head, and hope that some time it will get solved.

There is nothing that can be done here. The more you hurry up, the less the chances you give yourself of solving the problem. Everything needs to take its natural course.

I got reminded of it when we missed a deadline last Friday, and I decided to not think about it through the weekend. And then, an hour before I got to work on Monday, an idea occurred in the shower which fixed the problem. Even if I’d stressed myself (and my team) out on Friday, or done somersaults, the problem would not have been solved.

As I’d said in 2004, quality takes time.

Bayesian Recognition

We don’t meet often, but every time we talk, she reminds me that I had failed to recognize her the first time we had met after graduating together from school. Yes, I could claim in my defence that I was seeing her for the first time in over six years. While that might be a valid excuse for most people, it doesn’t apply to me, since I normally claim to have superior long-term memory. If I’ve seen you somewhere before, I ought to recognize you. The only times I don’t I’m pretending, since I don’t want to embarrass you (and myself) by recognizing you while you don’t recognize me (see this incident for an example of this).

The reason for my failure that cold Bangalore evening in December 2006 was that my Bayesian system had failed me. Let me explain, in the process giving you an insight into my Bayesian system which I use to recognize you when I meet you.

About a month or two back, I was at a friend’s wedding, which is where I hit upon this term “Bayesian recognition” to explain this phenomenon  (which I’ve been practicing for ages). Now, this friend whose wedding I was attending was one year my junior at two different schools. As you might expect at an event where you and the host share more than one social network, there were a lot of familiar faces. Some people I knew fairly well, and could easily recognize. But the others had to go through a “Bayesian search”.

So when I saw someone who was one of three people I know – let’s say X, Y and Z. In order to determine which of these this person is, I would ask myself two questions – firstly, what were the prior odds that the person I saw could be each of X, Y or Z. Secondly, what were the odds of each of X, Y and Z being there at that event. Note that the latter is important. For example, if someone at the event looks like you and I know (for example) that you are currently in another country, despite the strong resemblance I can discount the possibility that that person is you, and go ahead with my search.

Note that this differs from “frequentist recognition”, where I only look at the person’s face and try and understand who he/she most resembles, without any thought to the odds that that person is there. Frequentist recognition can lead to a large number of false positives, and after a few rounds of embarrassment, you start giving up on recognizing, and many a possible reunion thus gets missed. Bayesian recognition, on the other hand, restricts your field of search (to the people who you give good odds of being there), prevents you from being distracted and increases your chances of making a good recognition.

So why did Bayesian recognition fail me when I met this former classmate back in 2006? The problem was her company. She had come for this Deep Purple concert with another friend of mine, who was my classmate in another school (and who I had been in touch with, and so easily recognized). I had no clue that these two were friends (it turned out they didn’t know each other that well – they had come there with a common friend). So when this girl (the one I didn’t recognize) popped up with “Hey SK! Do you remember me?” I assumed that she was someone I knew from the same school as the other girl I was meeting, and that wrongly restricted my search space. And so my mind was trying to map her to my friends from school 1, while she happened to be a friend from school 2. And my search returned a blank, and my legendary long-term memory skills were embarrassed.

I must mention here, though, that this is possibly the only time that my Bayesian recognition model has acted up, and refused to recognize someone I know. There have been 2-3 false positives, but this has been the only negative. And when you consider the sample size to be all the people I have recognized in different places, this is small indeed.

Oh, and after failing to recognize her then, I’ve kept in touch with this friend.

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!

“But she is a really nice person”

That is the reply I usually get when I tell someone that someone else is dumb, or is an imbecile or is boring. And now I think I have some insight into why people who are otherwise idiots or irritating or boring are also extremely nice people, with “big hearts”.

Basically I’ve found that whenever I’m low on confidence or self esteem I end up being more sensitive, both with respect to myself and others. I display greater empathy, I care more about how people would feel and react to things I would do, and my usual buffalo skin disappears and I get affected by any adverse comments or remarks or incidents. Actually, I’ve seen a two-way implication here, but again you need to remember that I’m extrapolating from one data point here. Back in 2001, I had received extensive feedback (from various parties) that I had become too arrogant and self-centered, and that I needed to make an effort to be nicer and more sensitive towards people. I did make that effort, too successfully I think, for though I consequently became more popular, I entered into a prolonged period of low self esteem. Anyway, I digress.

So, based on the one strong data point that I have, which is myself, I hypothesize that low self esteem leads to greater empathy. People who you are likely to normally consider to be “boring” or “stupid” are likely to know that people think of them as that, and are consequently more likely to have low self esteem. And going by my hypothesis, that means they are more sensitive, have greater empathy, and “have big hearts”. And so, the remark “but she is a really nice person” in the context I mentioned largely holds true.

Shopping in New York

When I went shopping in New York on Friday I was reminded of this article by Tim Harford that the bofi had posted as part of a comment on one of my earlier posts. The basic insight in the article (which draws upon some widely cited research – I’ve read about it in several other places) is that too much choice may not be a good thing. That basically if presented with too much choice you are likely to just put NED rather than put effort into making the choice, and so it makes sense on behalf of the marketer to restrict choice.

So on Sunday evening, after having spent most of the day with a bunch of friends I know through an online group, and an hour or so with RG Mani, a very tired me walked into Macy’s, which claims to be the largest store in the world. I don’t dispute that claim – there are some six floors with each floor being the size of an average Big Bazaar. And there are clothes. And clothes. And shoes. And clothes. And more clothes.

Since I was trying to shop not only for myself, I ended up spending a considerable amount of time in the women’s section also. And the problem there was one of plenty. There was so much stuff to look at that it caused intense NED. I ended up just giving up on large sections of the store, and not even looking at even a sample of price tags there (yeah, I’m a cheap guy and was looking only for heavily discounted stuff). I won’t elaborate further on this “too much choice => NED” funda. Read the Harford article for more on that.

I don’t know what the strategy of the store is and whether they had deeply discounted stuff at all. The sample of clothes that I happened to check the price tags of were all extremely expensive. Perhaps the store did have some cheap stuff, but I don’t understand the policy of hiding it somewhere. Is the thinking that people on the lookout for cheap stuff are going to look more carefully and will hence find it? Which means some kind of “skimming” in terms of people’s attention spans? But the problem with this strategy is that by not displaying the cheap front up front, you may end up turning away a lot of people who look for cheap stuff!

Looking through all the huge floors of Macy’s caused me so much NED that when I saw an excellent looking reasonably priced Tommy Hilfiger sweater I didn’t even bother trying it. Maybe if I’d seen that sweater earlier I would’ve owned it now! So much that choice, and size, can do!

On Monday I went to this store called Century 21 near my office and had a more productive shopping experience. They also had both cheap and expensive stuff but they prominently advertised the cheap stuff with prominent “sale” signboards. Much more targeted, much more convenient for the cheap shopper, much more sales which means much more profits. Only thing I wonder is if this strategy of theirs turned away people looking for the higher margin expensive stuff..

Interview length

When I interviewed for my current job four months back, I was put through over twelve hours of high-quality interviews. This includes both telephonic and face-to-face processes (on one day, I was called to the office and grilled from 1030am to 630pm) and by “high quality”, I’m referring to the standard of questions that I was asked.

All the interviews were extremely enjoyable, and I had fun solving the problems that had been thrown at me. I must mention here that the entire process was a “stud interview” – one that tried to evaluate me on my thought process rather than evaluating what I know. I’ve also been through a few “fighter interviews” – ones where the interviewer just spends time finding out your “knowledge” – and I don’t remember taking a single job so far after passing this kind of an interview.

So recently I read this post by Seth Godin that someone had shared on Google Reader, where he says that there exists just no point in having long interviews and so interviews should be kept short and to the point. That way, he says, people’s time gets wasted less and the candidate also doesn’t need to waste much time interviewing. After reading that, I was trying to put my personal experience into perspective.

One thing is that in a “stud interview”, where you throw tough problems at the candidate, one of the key “steps” in the solution process is for an insight to hit the candidate. Even if you give hints, and mark liberally for “steps”, the “cracking” of the problem usually depends upon an insight. And it isn’t fair to expect that an insight hits the candidate on each and every question, and so the way to take out this factor is by having a large number of questions. Which means the interview takes longer.

The other thing about the length of the interview is signaling. Twelve hours of hardcore problem-solving sends out a signal to the candidate with regard to the quality of the group. It gives an idea to the candidate about what it takes to get into the group. It says that every person working in the group had to go through this kind of a process and hence is likely to be of high quality.

Another thing with the “stud interview” is that it also directly gives the candidate an idea of the quality of the people interviewing. Typically, hard math-puzzle based interviews are difficult to “take” (for the interviewer). So putting the candidate through this large number of math-problem-solving interviews tells him that the large number of people interviewing him are all good enough to take this kind of an interview. And this kind of interviews are also ruthless on the interviewer – it is usually not hard for a smart candidate to see through it if he thinks the interviewer has just mugged the answer to a question without actually solving it.

All put together, when you are recruiting for a job based on “stud interviews”, it makes sense for you to take time, and make the candidate go through several rounds. It also usually helps that most of these “stud interviews” are usually fun for the candidate also. On the other hand, if you are only willing to test what the candidate knows and are not really interested in the way he thinks, then you might follow Godin’s suggestion and keep the interview short.

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.