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.