My experiences with the chief developer at E5 (henceforth, “CD”) lead me to think in terms of what happens when a medium-sized fish (like CD) is put in a small pond (E5), what happens when an actual big fish appears, etc. This came to be a semi-important concept in my evaluations of my previous experiences; and, with hindsight, I found a number of examples of medium fish, including the VP of product management at E4. The below is an outline of the core ideas.
Note that I typically use the term “medium fish” as a short-hand for “medium-sized fish, who is incorrectly taken to be a big fish in the small pond he resides in”, not as e.g. “medium-sized fish, irrespective of pond”. Further, that I will typically refer to intellectual ability or area-specific competence when I speak of size; however, other types of sizes and ponds exist—if we look at influence, instead of ability, then most middle-managers are medium fish.
Subsequent to my original writings I have stumbled across the somewhat similar (but not identical) Big-fish–little-pond effectw, introduced by Herbert W. Marsh. An important difference in terminology is that I use “medium” to emphasize that the fish is not truly big, while Marsh uses “big” to emphasize the perception of size. His use is probably closer to the original meaning of the expression “big fish in a little pond” (which in it self contains the underlying principle of both his and my version).
If a medium-sized fish is put in a small pond with only small (or on the outside medium-sized) fish in it, he will likely grow to believe that he is, in fact, a big fish. Examples include the village boy who is the number one in every sport in his school of thirty students, but would not rank in the top percentile nationally; the man with an IQ of 120 in a team of average-IQ colleagues; a school teacher with too little contact with adults; ...
This medium fish was originally hired as the first web developer of a very small PR/promotion agency. He had very little, possibly no, relevant previous experience, had not seen significant quantities of work from more senior developers, etc.; but was of above-average intelligence. As time went by, the agency grew to about a dozen developers, most very young, all (?) from the lower salary brackets. The result was that he remained the biggest fish around, while the environment grew from a one-fish aquarium to a small pond; but he did so without truly developing. Notably, because PHP was the language used for all development, his outside influences were pre-dominantly poor: A poorly thought-through language, public modules written by incompetent web-hackers, whatnot. (This lack of incentives to develop is one of the greatest dangers with medium fish—I suspect that he would have managed to reach the top tenth, had he been given the right support and influences sufficiently early.)
The PHP under discussion is PHP 4, first released in 2000, and nowhere near what I would consider a professional-level language. Even PHP 5, while well short of good, was a considerable improvement. At the time of this addendum (2023), 8.2 seems to be the current version, and I am not sufficiently up-to-date to make any judgment of this version.
The end result was that he seemed convinced that he was a big fish—and that most others in the agency believed him. At best, however, he was a medium fish; and, frankly, from some of the very naive solutions he used, statements he made, etc., I would have rated him junior level on the scale of e.g. E3. (This included endless repetitions of identical and hard-coded strings, pre-mature micro-optimizations, functions that filled several screens each, poor or non-existent documentation, awkward and inefficient development setups, ...)
The typical reaction of a medium fish when he encounters a bigger fish, is to assume that the bigger fish is, in fact, smaller. He is used to other fish being smaller, he is used to being right (or, at least, less wrong than others), and he naturally assumes that this applies to the new fish too. When the bigger fish tries to communicate a different opinion, or when events seem to indicate the truth, the reaction is often one of denial—possibly even anger or aggression. Notably, I have made the experience that the more incompetent someone is, the greater the risk of a negative reaction—and the greater the risk that his self-image is overly positive.
A particular issue here is that people of unusually high intelligence tend to take leaps that others do not, come to conclusions that seem counter-intuitive to many others, and look further ahead (a decision that looks good in the short-term is often far from the best in the long-term), which can create the misapprehension in both medium fish and small fish that the bigger fish has some ideas that are “obviously” faulty. The hitch is that this is a result of the less intelligent, so to speak, being more short-sighted, and unable to see the complications, opportunities, dangers, etc., that are present beyond their field of vision—not of an an actual fault in the more intelligent.
A particular danger for the bigger fish is that the medium fish is likely to have significantly more allies and influence than the newcomer. (The medium fish is, so to speak, significantly larger in the influence pond of the organisation.) Correspondingly, even constructive attempts to bring about changes, stop bad practices, bring in new ideas, or similar, can end badly for the big fish (even lead to a firing). Deliberate attempts to de-throne the medium fish, or otherwise attempt a confrontational policy, are typically doomed to disaster—even in those cases where they are firmly in the best interest of the organisation.
Similarly, in a twist, it will often be the medium fish who evaluates the early work of the bigger fish. Being human, the medium fish is likely to consider the bigger fish’s dissent a sign of incompetence, and he might also engage in retaliatory rejection (cf. TODO).
A particular annoyance is that medium (and big) fish from one type of pond (in particular the influence pond) often automatically assume that they are equally big in ponds of other types. Consider e.g. the middle-manager who assumes (typically contrary to the opinion of his employees) that he is the number one in the local competence and intelligence ponds.
A related case is the fish who is large in one pond, but not in another of the same type, e.g. the upper-manager who presumes to order people around in situations where he has no formal power. An interesting example is found in C. S. Lewis’ “The Horse and His Boy”, where the evil prince Rabadash tries to intimidate his captors with grimaces that used to terrify his country-men—only to find out that their effectiveness was not inherent, but a side-effect of his, now absent, ability to order decapitations. Others are found in Erich Maria Remarque’s “Im Westen nichts Neues”/“All Quiet on the Western Front” where both Himmelstoß and Kantorek see their once authority turned into the opposite by a change of pond—despite the individual fish being, at least partially, the same in both ponds...
The medium-fish syndrome can strike anyone, even someone who by most standards would be a big fish: Move him to an even bigger pond and he will look less impressive. Consider e.g. athletes on the city, region, country, area, and world level.
Correspondingly, it is very important for everyone who considers himself a big fish to pay attention to his self-estimate, to try to preserve humility, to be open to the possibility that another party is the rare exception of an even bigger fish, etc. I, for example, am a noticeably bigger fish than CD: I am more intelligent, I am better educated, I am more experienced, I have a much deeper understanding of software development. This does not make me the biggest fish around, just bigger than he. If I were to claim to be among even the top-1000 fish in the global pond of software development, I would likely be wrong—quite possibly, in a laughable manner. As Qui-Gon Jinn put it: There is always a bigger fish.
Once someone believes himself to be a big fish, he almost invariable stops any active efforts at further improvement: He is content with his size and stops growing, e.g. by not reading enough, not listening to the opinions of others, etc. Minor growth might still occur through the slow gathering of new experiences and insights during daily work; however, the rate will be much slower than for someone of equal skill and talent who still deliberately strives for growth. In fact, his best chance of future growth is a disillusionment, e.g. by being proven decisively wrong in his size estimate (which will likely involve a non-trivial period of denial—or even perpetual denial) or by slowly gaining sufficient self-insight and maturity until a critical threshold is reached (a process that might take two decades—or never complete at all).
Beware, however, that exceptions to this can exist: I have myself not seen any clear-cut cases, but it is highly likely that they occasionally exist. Also note that many medium fish do in various ways take measures, but that these typically are ineffective: A seminar every now and then brings nothing, one or two books a year is far too little, digging deeper and deeper into the same manuals suffers from severe diminishing returns and fails to expand horizons (notwithstanding that a solid knowledge of the manuals is highly beneficial, and that most people do not read them enough), etc.
However, there are other reasons why development can slow down: Re-reading this text in 2023, maybe fifteen years after writing the first version, I note that I have, myself, read no more than one or two books a year in my main area for long stretches of the interim. This is partially because there has been a shift in where to find worthwhile content (the Internet is an alternative source of ever greater importance, while books seem to be more and more dumbed-down for every year). However, there is also the issue of saturation:
Firstly, reading more on the same topic brings diminishing returns, and digging deeper into one area does not necessarily bring the right return on investment. (However, software development has many areas and my readings over all areas have been well above two books or book equivalents.)
Secondly, I have many interests that have nothing to do with software development, and my personal satisfaction and my overall personal development (as opposed to my development specifically as a software developer/consultant/whatnot) have both benefited more from the many, many works in entirely different areas that I have read.
This does raise the question of what has caused others to slow down. It might relate to a feeling of being a big fish; it might be something very different.
Likewise, if someone has slowed down, is that a permanent change? I note e.g. three major phases of exploring new professional areas during these “maybe fifteen years”, viz. my switch from Java to Oracle, my exploration of Scrum, and my switch to writing fiction. They were all associated with study far above the “two books per year” mark. Might it be the same with many medium fish, if they moved to new fields?
(But, of course, reading books or various web pages is just one aspect of self-development, be it professionally or privately.)
In particular small employers, like E5, are in great danger of creating medium fish. Avoiding this danger can be very hard, because factors like lack of money, the wish to reward early employees for loyalty, and the early employees greater internal knowledge and internal network, play in. A few reasonable tips include:
Do not become too reliant on one single person.
Try to slowly upgrade the overall competence level by hiring more competent people over time; in particular, avoid going just by the price tag (salary) without giving due weight to value.
Make sure that everyone (including the chief this-or-that, vice presidents, etc.) continually works on his competence level, broadens and deepens his theoretical knowledge, is exposed to outside influences, ... (But beware of seminars: They are typically both over-priced and of little value.)
Avoid undue flattery towards a potential medium fish. Sincere compliments by qualified judges is valuable; superficial praise just for the purposes of generating good-will can do more harm than good.
Do not automatically promote a semi-competent long-time employee when e.g. a position as chief developer opens up/is created. Strongly consider hiring someone new or taking a highly competent employee with a shorter time in the organisation.
Be wary of too young employees in leadership positions; be very wary of young people who have never had more junior positions in other companies. They might deserve the chance, they might do the job sufficiently well, but they also stand a considerable risk of becoming medium fish—and, thus, reduce their long-term value severely.
Welcome a competent new-comer who disagrees with the internal consensus: Firstly, it is quite possible that his ideas are valuable and/or better than the consensus; secondly, consensus is often, in and by it self, a bad thing. (In addition to the danger posed by medium fish, consider clubs of mutual admiration, group thinkw, and similar phenomena.)
I would actually go even further: In a situation where no dissenter is present, it might be a good idea to deliberately institute a position of “devil’s advocate”, possibly on a rotational basis: Whoever holds this position should then deliberately seek to dissent from the majority during meetings, look for flaws in lines of argumentation, and similar.
Should preventative measures fail, then some of the below tips might help with damage control:
Have an awareness that a perceived big fish might be a mere medium fish; in fact, this is highly likely to be the case.
Try to deliberately increase the competition for the position of biggest fish, e.g. by sharing responsibilities and supporting smaller-but-promising fish. In particular, make sure that the medium fish does not monopolize all qualified tasks.
Consider confronting the medium fish with the possibility that he might be a medium fish. He is likely to react negatively in the short-term, but in the long-term both he and the organisation will benefit from this.
In a worst case scenario, get rid of the medium fish. (Note that this measure should not be taken lightly, but only for incurable and destructive cases. Also beware that this might cause disruptions in the team spirit or remove crucial know-how from the team.)
Beware that the cost/benefit ratio of a medium fish might change radically as the situation changes, and consider changing his responsibilities accordingly: A problem with e.g. CD was that he wrote solutions that did work reasonably for sufficiently small projects, products, teams, whatnot, but simply did not scale well. For a quick-and-dirty solution, they might even have been preferable; however, already at my time, they had become an accumulated burden on the software, which would have required large-scale refactoring—and in the long-term they were untenable.
Similarly, a medium fish often has some degree of success as long as his work (be it software or something else) can be kept in his own head; however, as others become heavily involved, their lack of his extremely intimate knowledge (together with poor documentation, hard-to-read code, illogical designs, whatnot) will severely hamper them. In a twist, this will make the medium fish look good, because he is able to do things faster than others within his own, undocumented, framework.
Consider any attempt, irrespective of by whom, to rationalize the size of the medium fish an alarm bell, and be very careful to check it for accuracy in reasoning. The complications are basically the same as above.
To exemplify with CD: As I tried to point out to a colleague that CD was very inexperienced, he became positively offended, and talked of the several dozen projects that CD had successfully completed. These, however, proved nothing: They were mostly small projects requiring little qualified work and thought, and mostly concerned installing, configuring, and tweaking a CMS software. I am certain that he could do that well; but, as proven by the code he produced and his opinions of what constituted good development, it is clear that he was not up to the task as chief developer of an actual, professional level, application.
Do not automatically take the word, opinion, or evaluation of a long-time employee over that of a newcomer. In fact, generally, try to judge an issue based on the arguments presented for and against—not on who does the presentation.
While medium fish cause many unnecessary problems, it is important to bear in mind that they are mostly victims of circumstance, and only partially victims of their own lack of rationality. Most (all?) of us have fallen into this trap at some point of our lives—even be it for a short period of time or in a specific setting. Small lapses should be forgiven and forgotten, and even persistent medium fish should normally be forgiven (forgetting could be dangerous, however). Only the most inveterate and destructive cases should be condemned.
The following is an automatically generated list of other pages linking to this one. These may or may not contain further content relevant to this topic.
The 48 Laws of Power
Issues relating to education
How to handle bug tracking
Sitemap