Avoiding Oblivion in Your Tech Career
Pages: 1, 2
The prospects aren't good in the long run. Shakespeare's comical, mocking tone is a wake-up call to stay young and vital, retain your position as soldier or justice, and keep your teeth. Granted, in every career, and in life itself, obsolescence is inevitable. But technology careers progress far too fast, and the eventual derailment needn't happen so soon. Oblivion is avoidable (or, more realistically, can be deferred); if you are in the seventh phase, you got there because you lost your edge.
The reason technologists fade so quickly is that they stop practicing their craft. They stop writing source code, they stop modeling systems in detail, they miss the paradigm shifts and use dated jargon, they brag about the old days, and (I have observed) they break their ties with the young development community. They fly at 30,000 feet, as you will hear them say often, alongside executive stakeholders.
Technology is unique in this regard. The senior surgeon performs landmark surgeries, the conductor plays brilliant piano, and the building contractor runs out to grab the toolbox from the back of his truck. In medicine, music, and construction, senior contributors are practitioners, who never part with their instruments. And they aren't reluctant to use jargon. Surgeons, for example, never tone down their medical talk unless the patient asks them to. With many decades of experience, they write articles in medical journals that only other doctors can understand, and they help the screenwriters of ER and M*A*S*H build credible doctor dialogue. Never hire a senior technologist to help write your computer lab screenplay!
The following tips will help you sustain technology excellence well into your golden years:
-
Conduct the code base. Learn the latest programming languages and practice coding in them. This will enable you to follow along with the implementation of entire systems. The conductor, a superior reader of sheet music, can follow a score more broadly than any of the musicians. Beethoven's Ninth cannot fit on a PowerPoint slide. The senior technologist must be able to navigate through an entire code base.
-
Oedipus on bugs. Be the best at solving the most puzzling show-stopping bugs, especially those that lie on the boundary of the system and cannot be traced to a particular developer. Be the project's resident Oedipus, treating these killer "Priority 1"s as riddles of the sphinx.
-
Hawk tech to non-techs. When communicating technical ideas to laymen, rather than descending to their level and reinforcing their fear of technology (as old-timers do), elevate the concepts by presenting them clearly and intuitively, as Stephen Hawking does with the concepts of astrophysics in his popular books for general readers.
-
Be a tough audience. Be the sharpest reviewer of others' work. Be the quickest to challenge fine points. Like a "justice," ensure that code and design work makes an airtight case.
-
Hegel.com. Like the philosopher Hegel did with human history, study the evolution of technological ideas over the past decades, and use this knowledge to understand current trends more fundamentally than others. Apply this all-encompassing vision to system design. Defend your technology choices by positioning them as lessons learned by previous failures (e.g., ESB as a culmination of MOM and SOA).
These points describe a job that is fundamentally more challenging and more valuable that the one performed by technologists in the sixth or seventh phases. Not only does it help you survive and thrive, it also helps produce better technology. It makes for a better play, in which all actors make a significant contribution.
That's my soldier's opinion.
Michael Havey is an architect of several major BPM applications and author of magazine articles on BPM and process-oriented applications.
Return to the O'Reilly Network






My employer is moving to a new business model with new a business system being put into place. It will require rethinking the existing business model and processes. This is good. The end result of which will be a better company at the end of the road that will be better equiped to move forward globally.
The result of this rethinking is going to be a remaking of what the company thinks of IT staff. The plan is to recerate IT into Business Analysts that can relate to businesses, analyze business processes, document necessary process changes, write specifications to implement those changes and generate testing plans. The actual coding effort is being outsourced, for the most part, to a low cost providers. The result will be a group of technologists that fly at 20 to 30 thousand feet and talk business speak with the business customers. For my company, that is a paradigm shift for IT.
This model is the future for my company. It creates a more challenging position for sure, more valuable positions from the company's perspective, it does provide a better implementation of technology for the company, and, as you state, all actors make a significant contribution. The difference in this reality and what your article describes is that the actual coding, developer stage and up a few levels, is considered a thing of the past, better done off shore.
I fear that we are moving innovation off shore and then, as a servide oriented group of technologists, we will fall to the wayside, requiring more and more off shore consultants to tell us how to do things that we used to be able to do well ourselves.