,

Not Invented Here

peacockIf you are part of the software development world, no doubt you are familiar with “not invented here” (NIH) syndrome. It is the scourge of the software development culture, the unfortunate tendency within a group of software-minded people to attribute value to the code that members of the group or the group itself has written, while devaluing code, modules or COTS packages that have not been written by members of the group.

“Not invented here” is so prominent that it has a wikipedia entry, with text that assures us that this tendency is indeed a facet of many a social, corporate or institutional culture. Bloggers and even Harvard Business Review have touted its benefits, suggesting that this characteristic of a culture may catalyze innovation.

Today, I attended a meeting where I had an even bigger revelation about NIH. About 10 people attended, and we talked about how to search a large archive of metadata across multiple data sources. Attendees spoke of the problem as something that really needs to be done, as something that our organization really needs to spend time on – and we need resources to do it. There’s only one problem with this picture – a couple of people within the organization have been working on this problem for the past 18 months, have produced a prototype that’s consistently getting about 100 hits a day (which is substantial given the problem domain), and have received positive reviews and helpful suggestions for moving forward from the user community. The releases have been published in inter-organizational emails, the company newsletter, and other venues where it would be very easy for everyone in this meeting to have learned of the new functionality and used it. But apparently no one has bothered to pay attention!

The moral of the story: when a NIH culture is observed, perhaps the resources and opportunities that are available to a group or an organization that could use them are truly invisible to the people who need them. The people can not see the opportunities because they are not looking; they are not paying attention.

Is paying attention to opportunities a value within your software development organization? It requires conscious effort.

5 responses to “Not Invented Here”

  1. John Hunter Avatar

    I actual find software developers the least likely to fall into this problem. They (in my experience) understand the benefit of learning. And in learning you take from the successes of others to allow faster success. There is no desire to not use calculus since it is outside knowledge. I find it hard to understand how a software developer can be any good at their job if they are not constantly learning and taking from ideas not invented by them. It is also required for managers but I see so many managers act that way that I can see how they can survive (the competition is not that great).

    The focus on results (and critical analysis of why results are not better) is one thing I love about working with good software developers.

    1. Nicole Radziwill Avatar
      Nicole Radziwill

      Hi John – I agree with you… the software developers who are the most competent *do not* have this issue, and are singularly focused on high quality results. Unless there is reinforcement within a team (managers + developers), continually encouraging one another to be aware of outside opportunities, there can be a risk of slipping into NIH mentality as a group. The key to me is… you have to pay attention to this process, and be committed to continuous learning (like you note).

  2. […] Not Invented Here by Nicole Radziwill – “when a NIH culture is observed, perhaps the resources and opportunities that are available to a group or an organization that could use them are truly invisible.” […]

  3. Greg Zimmerman Avatar

    The gap between what is occurring within an organization and the awareness or recognition of that activity or result is a common organizational issue, one that only gets bigger as organization size increases. A friend who works for a major multi-national spent the better part of 2 years building & managing a search tool that, in addition to finding existing applicable research outside the company, helped scientists within the company find relevant (or even duplicate) research from teams elsewhere in the organization that could help them shorten the product development cycle, solve problems, or innovate new products.

    I think this is where some type of social network or knowledge mining tool can come in handy. For example, Google requires their staff to maintain a profile of projects & ideas they’ve worked on or are currently investigating. When an individual decides to take on a new project, their first step is to search the internal profile space for similar work, then begin collaborating with the folks who can contribute something of value to the effort.

    It boils down to personal responsibility. If it’s important to you or your organization, stand up and ask the question: Have we already started looking into this and who should we talk with to learn more?

  4. […] /forrás, angol nyelven/ […]

Leave a Reply

I’m Nicole

Digital Transformation & Data Science for Performance Excellence since 2008

Let’s connect