My story on Terry Childs and the San Francisco City network "hostage situation" ran late in the day on Friday. Since then I've received numerous emails, some offering more information, some thanking me for providing some clarity to what is still a murky subject, and some asking more questions than I have answers for.
In order to keep things together in my mind, and perhaps for those looking for information on this story, I'm going to attempt to relay what I know so far, including some new information, some hypotheses, and -- unfortunately -- some more questions.
[ Follow the Terry Childs saga with InfoWorld special report: Terry Childs: Admin gone rogue. ]
Now that we have some background on Terry Childs, he seems somewhat familiar. In my life as an enterprise consultant, I've seen more than a few IT admins that fit his mold -- extremely intelligent individuals that lack the social tools or the will to conform within a highly political environment. The best thing that could possibly happen for people of this nature is to be left alone, trusted implicitly, and basically protected from the political machinations that seem to consume some organizations. This type of employee can be extremely valuable, but also tend to have short fuses, very little patience for the mundane, and are a high risk for burnout.
In fact, I must admit that I may share some of his traits, including the reluctance to allow marginal admins access to core network resources. While some may think that this is hubris or arrogance, in my case, it's based on experience. There are few things more frustrating than to complete a very complex network implementation only to have another admin blow it up through ignorance or incompetence. It's happened to me many times.
It's quite difficult to accurately convey the stress and effort required to build and maintain large complex networks to those with no real frame of reference. I've done it for years, building networks for city governments, universities, hospitals, and private companies. At some point, a network moves beyond "straightforward" complexity, and almost becomes a work of art. Whether it's a clever iBGP VPN failover for a large MPLS-based WAN, an OSPF-based ISDN dialback configuration, or a novel method of route injection through a third-party cloud, there are instances where network architects and admins need to color outside the lines to provide a needed service or measure of redundancy. It's at this point that the proverbial wheat is separated from the chaff in terms of network administration.