Building Your I.T. Career: Do Not Let Your Title Define You
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
I hear it all the time: Ask a technologist what he does and he will answer proudly, “I’m a PHP developer,” “I’m a Cisco network engineer,” or “I’m a help desk manager.”
Although I understand the need to clearly articulate your skills and the tools you use, I worry that technologists often sell themselves short in their career by defining themselves by either the technology they use or the job title they currently possess.
Perhaps more concerning is that by defining themselves by the tools they use, they undermine future opportunities and actually hinder their ability to learn and adopt new technologies.
I refer to this as a tool-driven mindset because the tool is placed front and center as the most critical piece of their arsenal.
If all you have is a hammer, everything looks like a nail.
The above phrase succinctly identifies why this is a problem. If you define yourself by your title or the tool you use, every business challenge is viewed in relation to how your tool of choice can solve the problem. It is better for business challenges to be viewed and analyzed separately of any tool or technology. When there is a conceptual understanding of what will solve the problem, the tool or technologies to use become more apparent.
And certainly, existing tools are a great choice, so perhaps their tool of choice will be used. But often the solution may require a different direction. This can be seen and understood only if the business challenge is viewed outside of the tool or technology.
Tool-Driven Thinking Locks You In
What I’ve found with technologists who define themselves by their technology is that they believe they are, in fact, that thing. If they are asp.net developers, they develop only in asp.net. If they are Cisco network engineers, they build networks using Cisco products and technology.
Furthermore, they find learning technologies more challenging. It is as though they place a mental barrier between themselves and the new technology.
This often leads to self-inflicted career stagnation. When new opportunities arise, they have a hard time picturing themselves in the new role. They have predetermined what they are and therefore overlook opportunities that do not specifically match that. Over time this locked in mindset becomes more ingrained. It manifests itself as a distrust and disdain for new technologies.
With the advent to PC, many mainframe and midrange developers found themselves in this situation.
So how does an I.T. pro avoid being tool-driven and let their title define them?
View and Understand That Broad Concepts Are Critical
If you have found yourself caught in this type of thinking, step back from the specific tool you use and look at that tool for the common elements between it and similar technologies. Find articles that discuss your technology in relation to other technologies.
PHP Versus asp.net, for Instance
You might learn that your technology is superior in ways that are critical to you. But I suspect you may find merits in the other technology presented as well. Comments on these articles can also be revealing. First, you’ll recognize the tool-driven thinkers almost immediately. But second, the discussions may include links to other articles and even tools and technologies that are similar to those you are reading about.
This helps you develop a broad concept perspective.
Don’t be a Brand Snob
There are technologists who adamantly maintain their product or tool is the best and only way to solve the technical challenges of the companies they serve.
The truth is, there are typically, in any given space, several technologies or tools that can solve a problem. By failing to recognize this and being a sort of X technology snob, you necessarily limit your ability to look at and adopt any other technology.
The challenge is, as Cobol programmers faced in years past, both time and tool will pass you by. Suddenly, you will find yourself many years and many projects removed from anything remotely seen as current.
Although you can overcome this, the amount of effort necessary and the negative career impact may be substantial.
Try One or Two New Tools Each Year
I’m not suggesting you become an expert at two new technologies each year. That might be overwhelming…then again, it might not be. But at minimum, spend some time learning a new technology. Not a library or subset of your current toolkit but an honest-to-goodness new technology or tool.
Worst case: You learn something that helps you understand what is out there and what people are using. Best case: You are left with a greater conceptual understanding of tools being used, and you have, in fact, added one of those tools to your arsenal.
Fraternize with the I.T. Pros Using Different Tools
If you spend some time working with talented I.T. pros who use similar, but not the same, tool, it is likely you will see the merit and the reason why they use their technologies. Furthermore, this can help you see the broader, conceptual similarities between your current tool of choice and theirs.
This broader conceptual understanding is your key to more quickly adopting new technology and also seeing how you can undertake roles that stretch you beyond your current tool or technology.
Also, by doing so, you begin to train your brain on the process of rapidly adopting new technology. As you see conceptual and functional similarities between two or more technologies, you begin to realize that many concepts and skills transfer directly to the new technology.
Rather than learning a bunch of new facts, you are merely learning the differences between the technologies. There is no need, for instance, in programming to spend a LOT of time learning an if/then control construct. In fact, most programming languages are identical when it comes to control constructs…except for the differences. And those end up being largely the semantics of the language.
The same is true for networking: routers, switches, wireless technologies, and so on. Some terminology changes, but concepts tend to have a longer shelf life. Understanding this is good for your career and greatly reduces the stress associated with learning new technologies.
Many years ago, I was speaking to a group of technologists who focused on IBM midrange systems (AS/400 and iSeries). I suggested that an iSeries was similar to a PC running Windows 98.
I nearly had to flee the stage. But I ended up backing up my statement. I was NOT suggesting that they had the same power or capability to run hundreds and even thousands of simultaneous users.
I told the audience that, at their core, there was a processor, memory, storage, apps, and data. The job of the professional in charge of those systems was to ensure reliability of the system and effectively get data into and out of the system.
At the time, I worked on both iSeries and PCs as well as mainframes, Netware servers, Windows NT Servers, and Macs. In all cases, I started with a conceptual understanding of what I needed to achieve on each system. I then had to learn the particular interface and commands to achieve that objective.
I still maintain that they are all conceptually similar except for the differences.
What I have unfortunately experienced is I.T. professionals who, when faced with a new, largely unknown system, balk at the idea of rapidly being able to effectively work with it.
However, I’ve found that those who identify the broader conceptual similarities approach the new technology with far less fear. This, by itself, increases the speed at which they learn and become reasonably effective with new systems.
Concept First; Process Later
When I first wrote, Chapter 22, “Concept Over Process” (in Building Your I.T. Career), this was part of the paradigm. Although process (the functional talent of using a technology in this case) is important, I push my coaching clients and those who work with me on projects to think more conceptually about all of it.
Although some have suggested that there is NOT enough time to step back into this conceptual mindset due to the pace of change in I.T., I maintain that the pace of change makes this conceptual mindset absolutely necessary.
As I repeatedly say, this isn’t an either/or situation. It is a both/and requirement.
If you want to have greater success over the life of your career, you need concept and you need process. Or as I like to say, become concept driven and process savvy.