The Great Specialization Fallacy

We should always have in mind this question: “Are we working on the best solution to meet our needs or goals?” Many times that is not the case. Most people are blissfully unaware of this as they imagine that their colleagues wouldn’t suggest anything but the most adequate solution. That assumption, however, is incorrect more often than not.

Over the past couple of decades, we have seen a curious phenomenon arise: extreme specialization.

Today, tech professionals are dividing themselves up into classes such as .Net developers, Java developers, front-end developers, etc. People working with IT infrastructure are also split into the categories of Microsoft or Linux professionals.

This behavior is incentivized by tech companies which employ every means available to convince professionals that their great products should always be used in conjunction with some of their other products. These companies create what are called Stacks, sets of applications that combine their various products with one another and/or with open source components.

But what’s the matter with that?

This leads us to a problem which might not be immediately obvious but which is growing. When a professional who has specialized in a particular technology, from a particular vendor, is tasked with coming up with a solution for a specific situation, he will do so in light of what he knows. This means that whatever solution he comes up with will use one or more of those products, whether it is the right tool for the job or not. It just happens that those are the tools that he is most comfortable with.

This approach might be sincere, due to a belief in the gospel that has been preached to him by the vendors or even by his own colleagues, or in some cases it may be cynical. The cynical attitude is that of the bad professional who doesn’t really care about the quality and adequacy of the solution he is proposing as long as it is something in which he can continue to be involved.

Whatever the root cause of this attitude, it is ever more present, leading to scenarios where we frequently have professionals who are unprepared to work in defining solutions, yet they are doing exactly that. This situation is made worse by companies who publish job descriptions which support the preaching of the tech vendors without taking note that it may not be in their own best interests in the long run.

When a company states that they are looking to hire a .Net architect, a Java architect, or a Cisco certified professional, for instance, they might unwittingly be condemning themselves to being chained to a specific solution or set of products. The company may find itself chained to a software development or hardware platform, even when those platforms aren’t the best solutions for the company’s needs.

This trend is taking us to an increasingly fragmented future where professionals know more and more about less and less, until eventually they will know everything about nothing.

This situation has been in the making for decades, and so it goes mostly unnoticed for most of us going about our daily business. This reminds me of a story about frogs and boiling water…

If you put a frog into a cooking pot filled with boiling water, it will instantly jump out. If you, however, put the frog into a cooking pot filled with water at ambient temperature and light a fire under the pot, the frog will remain there until it’s been cooked to death.

Just like the hot water creeps up on the frog, this super specialization crept up on us and is becoming ever more present in the industry. In the Brazilian technical market, specialization has now become the norm (though this issue is far from being restricted to Brazil.).

We need more professionals who don’t define themselves based on a product or specific technology, but who have a more broad view of the technology landscape. We need people who can really look at a problem and dispassionately evaluate the best techniques and tools to be applied to its solution.

Can you imagine how you would react if you were going to build a new house and your contractor told you that you could choose any color as long as it was white? Or any kind of light fixtures, as long as they were from brand X? It’s likely that you wouldn’t be very happy. Why would you settle for a brand dictated by the contractor before looking at all the available options?

If you wouldn’t settle for this kind of attitude in your personal life, why should you be willing to do so in your professional life?

A quote that always comes to mind when I consider this kind of biased attitude towards tech solutions is the one about the person who’s only got a hammer:

“To anyone who’s only got a hammer to work with, anything and everything looks like a nail.”

That is a common enough approach in many an IT department these days when considering databases, programming languages, operating systems, networking equipment, etc.

Recently I saw a reference to this sorry state of affairs in Richard Sheridan’s book,Joy, Inc. In it, the author comments on attending a convention with a colleague who drew uncomprehending stares from two developers (who identified with two different platforms) when she responded to their question about what kind of developer she was by saying she was a software develope. She went on to explain that she used whatever tool was most appropriate for the jb, or the tool that was asked for by her client. This must have seemed like totally alien behavior to people who define themselves professionally as being a platform X or platform Y developer.

I have been working professionally with technology for 21 years, though I started programming 10 years before that. Since then I’ve had the opportunity to work with an assortment of tools and technologies. Even though I have written books about some of them, I never defined myself professionally based on any of them. Whenever I worked on a project, I always looked forthe best solution available for the situation at hand, looking up and studying how other companies and groups addressed similar problems.

Over the years I’ve had the privilege to assemble teams of people who work in this manner, with excellent results. These people would always look into what products and tools might be applied to the problem and then evaluate the pros and cons of each one.

If you are a tech worker, always question whether you are using the right tools for each job. Question whether you took enough time to really understand the problem at hand and what products and tools are available that might be applied before you settle on what is the best solution.

If you feel that you have fallen into the trap of identifying yourself with one particular solution, product or platform, don’t wait until it becomes obsolete to wonder what to do. In the 21st century, technology is moving ahead at a very strong pace, and if there is one thing about which you should have no doubts, it is that no matter what you know today, it will be obsolete tomorrow.

If, on the other hand, you are part of the management team of a company, remember to question your IT team on whether or not other options were looked into for a particular project. If so, question as to why the chosen solution is better than the others which were considered.

In today’s fast-changing tech scene, the most important thing is to learn how to connect the dots. If you can adopt a broader way of looking at things and see how all the pieces can fit together, you will be much better prepared to adapt as the market changes.

fallacy |ˈfaləsē| noun (pl. fallacies)*

a mistaken belief, esp. one based on unsound argument: the notion that the camera never lies is a fallacy.

Logic a failure in reasoning that renders an argument invalid.

• faulty reasoning; misleading or unsound argument: the potential for fallacy which lies behind the notion of self-esteem.

* Source: Apple’s OS X built-in dictionary.

If you liked this post, please share it with your friends and colleagues. You can follow posts my posts by simply following me on LinkedIn, or through the following Twitter accounts: @mauricioblongo and @mauriciolongo.

This post was originally published on LinkedIn on March 31st, 2014.