5 lessons I learned in 41 years of IT

On an early spring day in 1976 fresh out of college with a math degree in my pocket. I entered the IT workforce. I sought out a more technical job landing a position as a basic assembler language programmer. COBOL seemed too lame for a nuts and bolts mathlete like me. It didn’t take long for the reality to set in that my IT career would not resemble my vision as a college student.

IT has been very good to me. My career has taken me down a path through large corporate America IT shops. I grew my experience and was able to shape my career. In the late 80s, I began dipping my toes in the data waters. Data quickly sucked me in and by the early 90s, it was not just my job but my passion.

Next week I leave the IT world for retired life. With that in mind, I wanted to share some of the lessons I gained over 40+ years. They by all means are not limited to life in the data architect world. I hope that they give my followers something to think about.

(1) You control your destiny but have to take action.

After my first thirteen years in IT, I was at a crossroads. My employer was relocating. I was offered the chance to relocate. I examined my career and decided to jump ship and explore uncharted territory. That leap of faith gave me confidence and forced me challenge myself to learn new technologies, work with new people, and be receptive to change.

I have seen many IT folk lament that they have no control over their career. The truth is they have great control. It starts by leaving that comfort zone. It is about having open conversations with your manager. It’s about being more vocal in your position. It’s about knowing when to leave and move on.

(2) Ideas can come from the bottom up but must be supported from the top down.

I learned early on that I am an ideas guy. My ESTJ personality cultivates my innovation and leadership. I am an over-committer in volunteerism. My ESTJ traits have placed me in the leadership role of many visible teams and initiatives over the years. I was able to deliver results and implementable actions.

At the same time, I learned that these efforts often died on the vine when placed into practice. The culprit was almost universally lack of management support. Many of my employers valued the bottom up approach of employee innovation. What they did not value was the top down support of employee results by management. Most managers are uncomfortable with playing the bad guy on enforcement.

(3) Everyone chases things that are bright and shiny.

I am guilty. Most people are guilty. It was easy in my world. Large IT initiatives during the 80s, 90s, and post-Y2K involved a relational database design. That placed me firmly in the high visibility seat. I hopped from one shiny project to the newer shiniest project in the house. The shiny ball always gets more training, more raises, and much more recognition. I liked that!

That may seem good. There is a problem with focusing on “the shiny”. Every shiny project leaves behind work; work what just does not have the luster but must be done. Many IT leaders focus solely on the bright lights not realizing that the legacy of projects is just as critical to their enterprise.

This is very evident in the data world, legacy databases and data from disparate projects are critical to keep the lights on. They are increasingly becoming visible to both internal and external customers. Sure, IT management needs to focus on moving the enterprise ahead but most also focus on the legacy on which this forward movement is built.

(4) Technical skills alone do not an expert make.

In the early 90s, I was an IT consultant. I was fortunate in my early assignments to be trained on and gain experience in many new technologies. I distinctly remember one of my client interviews where the interviewer repeatedly called me a technocrat. I found it amusing and at the same time a badge I could wear proudly.

As my career unfolded, I saw that technology alone did not define success. I am a pretty amiable person. I learned that success is mostly about partnerships you build, the team as a whole, and not the individual. This is difficult for the typical techie. I have seen many a data architect fail when they failed to nurture their soft skills and teambuilding skills. When you become a team player, you become a winner.

(5) Good communication is the root of success.

If I were to call out the biggest shortcoming of data and IT professionals I have seen through the years, it would be poor communication. Maybe you don’t recognize it but things like: “No one uses my data models”. “No one values what I do.”, “I am never involved early enough.”, and “My boss doesn’t have a clue what I do.” All of these have poor to no communication as the root cause.

I won’t just call this out for techies. I know fear of communicating is prevalent in the analytical quadrant where communication is something you do when you have to. This is a problem across corporate America. I have seen it for 41 years. No one talks, I mean really talks.

Workplaces are becoming more open and more distributed. That will force all team members to concentrate on their communication skills. At the same time, leaders need to make it clear they value open and constant communication.

Tom Bilcze
Soon-to-be the retired data guy

Leave a Reply

Your email address will not be published. Required fields are marked *