Realizing I am an Old Dawg: Thoughts from a CTO of a Technology Company

So about 15 years ago I am sitting in the hockey locker room after a game drinking a beer. The guy sitting next to me is in his mid-fifties. I think back to the game as I say, “Hey nice goal tonight, sure hope I can play like that when I’m your age”.  In my mind I was being respectful and complimentary. Now 15 years later some smart-ass 35 year old kid is sitting next to me and I’ll be damned if he doesn’t say the same thing to me (of course I see more of a smirk on his face then I had on mine).  I can tell you it doesn’t sound as good on the receiving end as I had meant it on the delivery side. What I really heard the kid saying was, “aren’t you about ready to hang up your skates?”  Strangely enough, as my hair continues to thin and grey, I find a similar pattern occurring in my day to day role as the CTO. The younger ones, which is pretty much everyone else in the company now, full of energy and ideas and impatient to get the latest and greatest technology, always want to know why we aren’t doing this or why we aren’t doing that. The culmination of these on- and off-ice events have started me thinking a little deeper about what it means to become an Old Dawg and how my expectations and perspectives have changed along the way. This introspection has made me focus on the following question: am I slowing the technology development and adoption in the company or I am truly guiding the technology direction of the company through seasoned experience? Allow me to share my thoughts as I wrestle with this question.

I remember, as I was preparing to start my doctoral research, sitting in my advisors office passionately trying to convince him that I HAD to go to a GIS training class being held at Texas A&M to learn the “state of the art” technology in GIS.  He was somewhat dubious but I think looking back, he did not want to curb my enthusiasm and agreed. The training was being run by the National Park Service on a home grown system called SAGIS.  Anyone ever hear of that one?  I never did again either.  Now I did learn a good bit about the underlying processes in line command GIS, but as for SAGIS itself, it was a waste of time.  I started to learn two things from this (this lesson was repeated several times in my career); first, I might want to put a bit of a governor on my own excitement when making decisions like that, and second, to pay attention to your advisors’ words and even nonverbal signals. They have been there and usually truly do understand.

Another lesson I have picked up on the way is that the experts don’t always know what they are talking about (a central theme in the book The Black Swan by Nassim Taleb, which is why it resonated with me).  Some of you might remember when ESRI released MOIMS, followed shortly thereafter by ArcViewIMS, and then finally IMS.  Despite all of the experts touting how MOIMS was going to take the industry by storm because it was “just simple vb” so your existing programming staff could develop with it, it never got a foothold. The pitch for ArcViewIMS was that “your GIS Analysts could publish internet applications.” Alas, that did not stick either, but not without significant investment by the organizations I was working with at the time.  Now IMS did hit the mark and to this day seems to provide some capabilities and ease of use that ESRI is struggling to match with the AGS API technologies – damn those map services. Technologically there really wasn’t any reason the first two systems didn’t take hold. Looking back I think that it was more of a disconnect between the user base and the technology itself (a primarily desktop and client-server community base struggling with a developing internet solution). None of this was predicted by the industry experts.

Gartner Research published the Hype Cycle concept in 1995, which charts out the progression of an emerging technology through its lifespan. http://www.ask-force.org/web/Discourse/Linden-HypeCycle-2003.pdf  I think this chart helps put into context the experiences I have described. As a new technology hits the street the community gets over-excited and pressure to try it or adopt it is high – especially by the techno-curious. The problem is that if you get caught at the peak of the hype and it turns out it is all hype and the technology is no good, for whatever reason, you have lost money, time, and credibility in one fell swoop.

So as I have progressed through my career evolving from the techno-curious guy getting caught on the false upward slope, through the skeptical road-worn warrior that appears to be the curmudgeon that likes to say “no”, I have subconsciously developed a mental attitude towards new technology that I think became clear to me as I read The Black Swan. Taleb describes the mindset of a skeptical empiricist which to simplify for me means, believe the facts just don’t trust them.  So a couple of concepts in that short definition are key. Facts have to be truly validated as facts and not opinion of the over-enthused. Belief and Trust come from understanding where the facts have been derived.  You can believe that a piece of information was actually truly derived under the circumstances, but can you trust that the same information would be valid if the circumstances were repeated or slightly changed.  And what would be the impact if the answer is no.

This Empirical Skeptic concept is at the heart of why you might have been asked by your leadership team to provide requirements and/or develop a business case for the technology you are recommending.  They are trying to ensure a logical thought process has been followed, the available information has been vetted appropriately, and the benefits of success and risk of failure have been thought through. These requests, at times, may seem like a wet blanket thrown over the fire of enthusiasm; I can assure you that is not the intent.

The reality is that leading a technology company presents some real challenges in balancing technology adoption with fiscal constraints and employee satisfaction. While we want to be constantly evolving to keep pace with technology and keep employees intellectually challenged and satisfied, we must balance that with making full use of the technology investments we have made.  I can’t tell you how many times I have championed implementation of a specific technology based on recommendations from a techno-curious employee, only to be told (by the same employee) within days of implementation that there is this new great tool out there we need to be using instead.

So let me go back to my hockey metaphor to wrap up my thoughts around all of this.  As I have gotten older, I have transformed how I am a productive team member on the ice. I am not the one scoring the goals, in fact just the opposite; I am a defenseman where my current skills are more appropriate.  One of the most important roles as a defender is to make the first break out pass – get the puck to the skills guys leaving your own zone at full speed. That’s how I see my role as a CTO, get the technology to the guys that know how to use it best. But to do this you have to be able to see the entire ice so you don’t throw a pass up the middle right to an opposing forward, or perhaps worse, right to your guy just as he is about to get crushed by the other team’s defender.  I am responsible on the ice and at the office for setting up my teammates for success – not failure.

 

 

 

 

 

 

No, not me. This is Charles Schulz (Peanuts Cartoonist) who played competitive hockey until his death at 78.