Dealing with change: NIH Syndrome, institutional exceptionalism and isomorphic mimicry

The ways in which we can be wrong in considering calls for improvement in institutions

Spend some time in any institution and I bet you would notice at least one of these issues crop up. Sometimes people might push back against a a change too hard, or they might end up copying glitzy approaches without really thinking things through.

The issue deals with how do institutions react to suggestions for change. One of the most important things to consider while leading institutions is how they deal with changes to itself. By institution I mean any collective. It could be your school, university, company, team, or even government. Depending on the nature of the institution, its current and historical context etc it can be quick moving, pretty lethargic or downright hostile to change.

NIH Syndrome

The NIH ('Not Invented Here') syndrome is a disease - Linus Torvalds

NIH ('Not Invented Here') syndrome is a tendency for collectives to not use products, systems or advice from an external source. The idea being stems from the assumption that in-house resources would develop the solution in a better way, since they have more knowledge of the organisation or team they are part of.

To be fair, this is not always a bad way of thinking. Joel Spolsky wrote an article on it two decades ago which is still relevant and goes into detail about it. It's main point being: If it is something which is core functionality or something really differentiating you're offering in a way that's offering a competitive advantage, then it's probably not a good idea to use an external solution for it. However, if it is something which is not really core to what you do, then it's probably worth it to save your time and effort not doing that and getting an external solution there.

There are also issues to consider regarding how far down the stack do you want to have ownership and control. Joel Spolsky mentioned the Excel team making their own C compiler. If you're working on a software project, would you do the same, even if performance and memory optimisation are super important to you? The answer often would also depend on the resources you have at play (size of the team, how much money and time you can put into investing in the team) as well as the potential return on investment etc. For Apple, they for long used microchips provided by external vendors like Intel - but they see a need to own the performance sphere as something really core to them, and have the resources to invest in developing their own chips and they see a return on investment on it in terms of competitive advantage. So now their lineup is featuring their own chips.

Having said that though, in many cases NIH syndrome is a symptom of inertia and an aversion to systemic change.

Institutional exceptionalism

I couldn't find a proper term for it so I've made one up myself - Institutional Exceptionalism. In large organisations especially, you might encounter a feeling of resistance to change. Even if someone mentions something they could learn from others, often the response is that it won't work inside their institution.

I remember almost a decade ago I went and did a workshop on web standards and best practices for a bunch of people in the government. Most of them were people working on the department responsible for that government's national websites. These websites were extremely poorly designed and seemed to use a lot of practices which were, even at that time, considered bad.

During my workshop, I showed and demoed a few government websites from other countries with the intention that it might inspire the group to raise their game and learn from how they could design and develop something similar. Afterwards a few of the engineers came up to me explaining how complicated the countries situation is (so many national languages) and how much traffic they are getting everyday (wasn't that much actually) and how much of a resource crunch there is etc. They were convinced that their situation was so unique that no industry best practices could be applied to them properly. I internally sighed and thought to myself 'Ah, that explains the state of their websites for the last 15 years'.

During some other meetings (again, unfortunately with government bureaucrats) I have come across the same devaluing of ideas. I remember one particular instance where a foreign diplomat was talking in a meeting with a bunch of people from the private industry, as well as bureaucrats from the home country in attendance. Afterwards, a bureaucrat from the home country just completely trashed the ideas of the foreign bureaucrat - just saying that their country is different so it’s not a valid comparison. If we go by that logic, we can't learn anything from anyone since nothing will be 100% the same between two institutions!

Some people tend to go on the defensive when hearing ideas from external sources thinking that it's some sort of attack on their own thought process and work. Sometimes people are just having the Dunning-Kruger effect and overvalue their expertise while undervaluing others.

I recently came across this article where you see the same type of behaviour of overvaluing their capabilities and undervaluing others by some bureaucrats in the US. A telling quote from it is the following:

The worst phrase I keep hearing: apples to apples. The idea is that projects can’t really be compared, because such comparisons are apples to oranges, not apples to apples; if some American project is more expensive, it must be that the comparison is improper and the European or Asian project undercounted something. The idea that, to the contrary, sometimes it’s the American project that is easier, seems beyond nearly everyone who I’ve talked to. For example, most recent and under-construction American subways are under wide, straight streets with plenty of space for the construction of cut-and-cover station boxes, and therefore they should be cheaper than subways built in the constrained center of Barcelona or Stockholm or Milan, not more expensive.

Another aspect of such thinking (including NIH) is resting on past laurels. An institution might have a grand history of producing great work in the past, but that doesn't necessarily mean that it will do so all the time in the future too.

Consequences of this type of thinking can range from just lack of innovation, to dangerous and foolhardy policy. For e.g, take this example of a university which brought back 40,000+ students in COVID times to campus based on a model created by 2 over-confident physicists, who said epidemiology was important but intellectually unchallenging. Turns out they said made flaws in basic assumptions and the result was a mass spread of COVID-19 cases in the university.

Having said that, there are instances of people going overboard on the other direction too.

Isomorphic mimicry

Isomorphic Mimicry is a term used in the field of biology dating back to as far as the 19th century. It was used as a term to describe one organism mimicking another to gain evolutionary advantage for themselves. A well-known example of this is the Scarlett Kingsnakes (which are non-venomous) mimicking the look of the Eastern Coral Snakes (which are highly venomous). Another example is of the Snowtail Butterfly, which mimics the look of some other toxic butterflies.

Over the years, this term has made the jump beyond biology and now essentially means the tendency to take a look at some other institution's successes and completely replicate every (or a large) aspect of their success - whether it's processes, systems, metrics, etc without really putting thought into whether it could serve the context of your institution or not.

It is meant to give the appearance of success or legitimacy, without actually necessarily solving deeper issues involved to achieve success. You get the benefits of appearing like a successful entity without actual being that thing.

To be fair, thats not always a bad thing. Meiji-era Japan in the 1800s sent a bunch of people to various western countries to learn from their systems of governance as well as their commercial, artistic and scientific advances. They sent officers to France to study its courts, army (they also studied Prussia for its army) and police. They studied the navy and the postal system in Britain. In the United States, their officers studied the banking and arts education system. All this laid the foundation for modern day Japan.

Vaccination of children has seen a great increase over the last few decades and, by and large, been a massive success. For the most part, this has relied on many countries just mimicking the approach of others in this field. This resulted in a dramatic lowering of the death rate for children dying from diseases which are vaccine-preventable.

However, if I had to guess, I would say that most significant successes would rarely happen just via absolute mimicry of another institution. You would need to adapt things to better suit your home institution. This would mean learning from others while synthesising it with the nuances of your home institution to come up with something much better fitted to you. Along with this, while looking at others, you might repeatedly ask about why a certain approach is taken by others to truly learn the real reasons behind the rituals, tools and processes of others.

Knock-on effects of isomorphic mimicry

"I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail." - Abraham Maslow

JavaScript developers are constantly exposed to the world of new frameworks and tooling. Often these frameworks and tools are built by some of the biggest companies in the world to solve their own problems (which deal with massive scale). While many developers have used these tools and frameworks to great success, a lot of it is also driven by what others are doing and jumping on the bandwagon. Often these are accelerated by recruiters who sometimes don't have that great of an understanding of the technological requirements of a role and end up driving the demand for certain skills in these frameworks and tools more than they organically would.

Over time you have a market demanding skills in the latest hot framework. You have an industry of courses and books selling training on it. Eventually you end up with a bunch of developers who are trained in it and willing to use it, even in situations where it may not make the most sense. For example, I have encountered plenty of framework-laden websites which were so trivial that I wondered why they would need to use a framework in the first place. I've seen people use certain build tools in needlessly overcomplicated ways too.

One of the knock-on effects of isomorphic mimicry at scale is a bunch of people nodding their heads about things which may not be actually suited to everyone. It could also lead it more disastrous and sinister effects. There are instances of people who are part of institutions with very exclusionary hiring criteria moving on and joining other institutions and then replicate the hiring criteria on those places too. The result becomes that people associate good institutions with just the kind of people who pass that criteria - which most of the time, puts minorities and economically struggling people at a disadvantage.

You'll find it everywhere

Once I started thinking of these things, I started experienced a Baader-Meinhof Phenomenon of sorts. I realised that there are many topics which have people on both ends of the spectrum. Agile software development is an example. I've encountered people who absolutely never want to work in an agile environment and others who never want to work without it.

For people who are apprehensive of Agile but who have never tried it themselves, a lot of it has to do with hearsay, fear of change, and feelings stemming from NIH syndrome and Institutional exceptionalism (and sometimes even hubris). On the other hand, there has been a large scale adoption of Agile practices in companies who don't fully understand it and end up adopting it in name but not really in spirit. They may perform all the rituals and ceremonies associated with it, but without really thinking of whether it would apply to their organisation or not, and whether adaptations to those might be needed to better suit their institution.

Somewhere in between are institutions who look at it, apply context and make a plan to adapt it to better suit their needs and execute well on it. They are the ones who would have more success with Agile than others.

I think at some point, everyone of us experiences these biases in some scale or another. I would reckon we all experience these more frequently than we would like to admit. Next time we instinctively push back on something, or instantly think something is a great idea to adopt - it might be good to pause for moment, and truly ask why.

Ambitious Leadership

What goes into leading a collective towards a goal much greater than themselves, and what to watch out for.

Do you know of Ed Catmull?

One of the people that I look up to for inspiration is him. To say that he did pioneering work in the field of computer graphics would be an understatement. The amazing special effects and graphics you see in the media today are the result of people standing on the shoulders of giants like him. He (along with Pat Hanrahan) won the Turing Award (considered as the Nobel prize for Computer Science) for 2019.

If you’re not familiar with his work in Computer Science, you might be more familiar with his work if I mentioned the following to you: Toy Story, The Incredibles, Wall-E, Ratatouille, and Up. These and more were produced by Pixar Animation Studios, which Ed co-founded. Ed graduated from the University of Utah in 1974 and already had done a bunch of pioneering work (texture mapping, z-buffers etc) in the field of computer graphics as part of his Ph.D. During his time there, his sense of purpose became clearer.

“I walked away from Utah with a clearer sense of my goal, and I was prepared to devote my life to it: making the first computer-animated film.”

A full-length feature film with 100% computer animated graphics had never been done before, and to even think of it was something so ambitious and out of the realm of the reality of the time, that it would take him more than 20 more years to make that vision a reality. Along the way to achieving this dream came a whole cast of amazing, talented people (including Steve Jobs) whom Ed had to convince and get on board (many of them who had the option to join anywhere else if they wanted). - but the dream was so exciting and full of unknowns, that it attracted the imagination of a certain kind of people with the expertise, agency and wherewithal to go for it.

These people weren’t going for personal ambition - Pixar was a small scrappy startup, always teetering on the verge of financial trouble for most of its existence before Toy Story came out; it wasn’t exactly the well-known darling of the industry that it currently is. It was this shared ambition, framed by Ed that really motivated people to join Pixar and stay in the good times and bad.

“If you want to build a ship, don’t drum up the men to gather wood, divide the work, and give orders. Instead, teach them to yearn for the vast and endless sea.”

- Antoine de Saint-Exupéry

Voyages, Marathons and Sprints

What Ed was going after was a voyage into the unknown. This would likely go into unexplored waters and making it back safely (i.e, achieving his vision) wasn’t guaranteed at all. It’s important to identify the scope of what we want to go for, and see if that would be a voyage into the unknown, a marathon or a sprint (and no, I don’t mean the agile definition!). None of those is necessarily better than the other - they just require different strategies and paces to achieve.

To illustrate this, let’s take a look at a literal voyage into the unknown. In 1915, the explorer Ernest Shackleton assembled a crew to go on the Imperial Trans-Antarctic Expedition - an attempt to cross the antarctic on foot. Shackleton was a veteran of the region already, having been part of previous crews which had been making major inroads in the discovery of the continent in past expeditions.

This time, things would take a turn for the worse. Just near the Antarctic, their ship Endurance, became trapped in the ice of the Weddel Sea. Far from civilization, they waited aboard the ship for nine months before the ship itself was crushed by the ice and sank. Shackleton changed his focus now to making sure all of the crew survive and reach home safely. They decided to keep drifting with the ice floes up north until it starts to melt, at which point they took their small lifeboats to the nearest piece of land (Elephant Island, which was desolate and uninhabitable). From there, they pondered their next move.

That’s the thing with ‘voyages’ (i.e, large ambitious initiatives): Things rarely go exactly how you plan it. Often there are uncertainties and unknowns - which need to be embraced, rather than fought. Things will change, often out of your control, and you will need to work with everyone to adjust and adapt, often dramatically changing focus to adjust to the new reality. You will need to convince people that this new way could work and be on board with it and give it a chance. They are also full of ups and downs. You will need to celebrate the wins when you get them, and hold morale for the inevitable lows in the journey too.

At Elephant Island, Shackleton’s crew discussed their options. They decided that their best chance would be for most of the crew to wait at the island and for five of them to take one of their small lifeboats (called the James Caird) and sail to the island of South Georgia, a big land mass where there was a whaling station. Once they reach human civilization, they could send over a rescue party to Elephant Island for the rest of the crew.

Unfortunately South Georgia was 1300 kilometers away and in between lay the Drake Passage, one of the most dreaded pieces of open ocean on earth, with frequent strong storms and terrifyingly tall waves. They packed enough rations for just four weeks. They ended up making it to the island in 16 days, in a journey that tested their physical and mental limits.

Launch of the James Caird from the shore of Elephant Island.

This was a marathon (though of course not in the literal sense of the word). They paced themselves, took turns with chores and conserved energy as much as they could during the trip. However, they landed on the exact opposite side of the island from where the whaling station was. Their boat was partially destroyed, so the only way to get to the other side was to go there by land - the only problem was that it had never been done before!

Shackleton’s crew took rest for a couple of days in a cave nearby, and decided to leave two men there, and the remaining three of them to walk to the other side of the island. In order to scale the many mountains which stood in their way, they had to travel light and not wear too heavy clothing. However, the place was known for its blizzards and the temperatures tend to be well below freezing. This meant this journey would need to be a sprint (again, not in the literal sense of the word). At one point Shackleton realized that if they stayed on a particular altitude, they would quickly freeze to death, so they desperately needed to climb down fast. However, the usual way to do it was just too slow. So he asked them to all slide down the ridge! It was a daring move, but it kept them alive.

Sometimes ambitious goals force us to think of radical new ways to achieve the objective. For example, a small improvement in something might require a small effort, a moderate one a bit more, but to achieve something hugely ambitious, you might need to even reconsider how to do things in the first place and come up with something completely different.

Finally after a lot more climbing and walking (and jumping down a frozen waterfall!) they arrived at the station. There, shocked faces greeted them and they had a rest. Soon, a part was sent to rescue the other two at the other end of the island, and later, Shackleton managed to secure a boat from the Chilean government, the Yelcho, to go to Elephant Island to rescue the crew stranded there.

This image has been created during "DensityDesign Integrated Course Final Synthesis Studio" at Polytechnic University of Milan, organized by DensityDesign Research Lab in 2015. Image is released under CC-BY-SA licence. Attribution goes to "Luca Ferrario, DensityDesign Research Lab".

People often seem to think that ambitious goals are when we are doing well and firing on all cylinders. However, ambitious goals can also work in situations of crisis - and in fact, it's in these situations where they might be needed the most. Usually the very fact that something is a crisis is because all ‘normal’ solutions to a problem are not applicable. It's in these situations that you want to go outside the comfort zone and go for something more ambitious.

Shackleton’s story was about how he and his crew failed to achieve what they set out to do, but due to his great leadership, had the crew achieve something even greater.

Next, we’ll see another example of a team who didn’t exactly do what they initially set out to do, and achieved something greater, but it led to some painful introspection afterwards. For this, let’s come back to Pixar and visit the story of Toy Story 2.

Pushing back and pulling within

Toy Story was a grand success. It was the culmination of Ed’s vision which took more than two decades to achieve. Critics were raving about the film and it achieved massive financial returns too, earning 373 millions dollars at the worldwide box office. It achieved three Academy Award nominations, and ended up winning a Special Achievement Academy Award.

Yet when Disney came back to Pixar to talk about a sequel, they made an unusual request: Instead of showing it in movie theatres, this time make it a direct-to-video film.

At the time, Disney, in its long history, had only released one animated sequel and it had flopped. Plus, the direct-to-video market had become quite lucrative (Alladin’s direct-to-video sequel reportedly earned 100 millions dollars!). The idea would be to just have a sequel made for this particular market with a lower artistic bar and earn some money. Pixar agreed to do it.

However, later they realized that it was a mistake. The team working on the project wasn’t happy since they considered it to be the ‘B-Team’, working on an inferior project (while the other team worked on a new project, which would be a theatrical release), and it was affecting the culture and environment in the company as a whole. They went back to Disney and pushed for a theatrical release. Disney agreed to do it.

Disney aimed low, and Pixar pushed back to aim high. Now after all that pushback, they needed to deliver. Unfortunately, the project was fraught with difficulties. The story lacked drama, tension or humor. Early ‘reels’ of the film provided little confidence of the film having the quality they wanted. The two directors brought to direct the sequel did not seem to gel with each other nor have enough confidence to drive the project directly. Ultimately, they had to be replaced, and one of the producers had to leave too.

As the date of release came closer, all-hands were on deck. Working long-hours became the norm, with many employees having very little time to spend with their families. Mistakes happened - like an employee who accidentally deleted the root folder of the project’s assets on the internal server (most of it was recovered later due to one of the employees working from home having a copy of it). Many employees ended up with carpal tunnel syndrome and RSI symptoms. One of the animators forgot to send in their child to daycare and forgot the child in the car, where he was found unconscious. The child came back to, and was okay in the end - but all this raised the question of whether it was really worth it.

Toy Story 2 nailed its deadline, and ended up even more successful than the original. Critics considered it equal or better than the first, and it grossed more than 500 million dollars at the box office. However, here is how Ed saw it.

“Toy Story 2 was a case study in how something that is usually considered a plus—a motivated, workaholic workforce pulling together to make a deadline—could destroy itself if left unchecked. Though I was immensely proud of what we had accomplished, I vowed that we would never make a film that way again. It was management’s job to take the long view, to intervene and protect our people from their willingness to pursue excellence at all costs. Not to do so would be irresponsible.”

Ambition, whether a personal one, or a collective one, can have a dark side. Good leaders are aware of this, and know the line between nudging others to go outside their comfort zone to achieve something they see as improbable-but-exciting, and shoving them (or not stopping them) on their way to exhaustion.

Sometimes though, it's difficult to notice until it’s too late. At that point, you might already be in the trap.

Beware of the capability trap!

“Sometimes to go fast, you need to go slow” - unknown.

A capability trap is when pressures to boost short-run system performance lead to greater work effort at the expense of investment in maintenance, process improvement, and learning.

Usually these happen when there is a system where there is an urgency (real or artificially created) to deliver - but instead of a one-off situation, it becomes the norm. You initially try to boost performance by various ways for the short-run, and leave out working on tech debt, infra capabilities, documentation, research, long-term process improvements etc. People are happy since performance is boosted - and it's really easy to learn the wrong lessons here.

However, over time this catches up with the team and its capability erodes. Employees might burn out or leave (or at least have high amounts of stress), amount and severity of bugs might increase, etc. Ultimately clients complain and may even leave.

How do we get out of such capability traps? The best thing would be not to fall into such a trap in the first place. However, if we are there, we have to first accept that we are in such a trap, and that making changes would require worsening short-term performance for longer term gain.

In other words, be prepared for the worse before the better while the organization re-invests to work on longer-term capabilities. This also means working on learnings and establishing processes where regular work requiring longer-term investments of time and effort is not met with high-pressure urgencies to deliver.

In order to reach ambitious goals, one of the most important things leaders must look to do is to see how to enable others to be capable enough to meet the challenge. That would require taking a hard look at things and making sure we invest in long term capabilities instead of always trying to go for short-term wins.

Sometimes to go fast, you need to go slow.


  • We’re talking about collective ambition here, not personal ambition.

  • Framing the problem in the right way is important to inspire and excite people, and for them to put their own stake into this collective ambition.

  • It’s important to know the scope of things - Voyages, Marathons or Sprints.

  • Voyages are large and long initiatives into the unknown. Things will not go 100% according to plan and it would be important to embrace uncertainty and change plans, tactics or even the initial objective. Highs and lows will both come as part of it, and we need to expect that.

  • In marathons, you need to pace yourself and your team-mates, and co-ordinate really well to achieve results.

  • In sprints (not the agile definition), the idea is to go full force and everybody giving it their all for a short period of time. Use this wisely.

  • Ambitious thinking is not just for good times, but also for times of crisis. In fact, it might be needed more in the latter than the former.

  • If unchecked, ambitious thinking can lead to negative effects too, and we should be cognizant of that.

  • It is possible to fall into the trap of always delivering on ambitious short-term goals at the expense of more longer term investments and projects. We all should watch out for that too.

Further Reading:

Insights about management and tech.

Welcome to Irregular Insights by me, Shwetank Dixit. Nuggets of thought provoking concepts, shared with you (ir)regularly.

Sign up now so you don’t miss the first issue.

In the meantime, tell your friends!

Loading more posts…