What is Your IT Legacy?

alvaro-serrano-133360-unsplash.jpg
Where are you in your career arc right now? Trusting simple statistics, I can say that the majority of you are either just starting out, or somewhere in the middle. Relatively few of those reading this essay will be at, or near, the end (whether that means retirement is on the immediate horizon or you are looking at pivoting into something completely different).
So, for that majority of you who are not-done-yet, I want to ask you: what will you leave behind? How are you planning for your graceful exit? How are you ensuring that your colleagues (those who also aren't-done-yet) will continue to be successful without you to call on?
To be honest, this wasn't a question I’d considered very much, until I met a very special person in the SolarWinds booth at Cisco Live! last year.
He had clearly been around the data center a few times, about a decade and a half ahead of me, career-wise. We spent a few minutes amicably playing what I call "IT sonar"—where you get the depth and breadth of someone's experience by reminiscing on the tech you've seen come and go.
But then he turned to the demo station, because he had a few questions. The things he wanted to know were interestingly specific. They didn't center on the latest-and-greatest. He'd heard about our most recent features, and he and his team were using them. He was at Cisco Live!, and knew about THEIR most recent announcements, but wasn't particularly concerned about how WE could monitor THAT.
This was notable because, if I'm being honest, people visiting the SolarWinds booth usually fall into three categories.
  1. People who want to know about our stuff.
  2. People who want to know if OUR stuff can help with this OTHER stuff they just heard about and/or are buying.
  3. Fans who just want to say, “HI,” bask in the orange glow of #MonitoringGlory, pick up our latest buttons or stickers, and pose for a selfie.
Curiosity piqued, I asked him what was up. What was he REALLY trying to do? His answer came as a surprise, "I built this thing, but I'm going to retire one of these days," he said.
By "this thing" he meant all of it. The whole IT environment at his company. He took them from dumb terminals to PCs running Arcnet to Novell servers on Ethernet and all the way to today. He had a hand in all of it. He knew where the important bits were and where the cables were buried.
What got me most was the WAY he relayed this. He wasn't bragging. He wasn't justifying himself. He wasn't bringing up long-forgotten accomplishments as a way of proving he was still relevant. He was calm, confident, and clearly didn't need to prove anything. He told me he'd found his niche at the company long ago, and worked hard to gain and keep the trust and respect from both management and his peers. This gave him the freedom to make decisions in his lane, as well as reach out and help folks whose work fell outside that lane. He also described how he had worked to keep his skills sharp through the successive waves of IT trends, without falling into the bad habit of chasing the latest fad.
The problem, he told me, was that he realized there was no way to teach his coworkers—some of whom were young enough to be his grandchildren—everything that was in his head. And he realized it would be a waste of time to do so.
"There's just stuff," he said, "that isn't worth anyone's time to learn, or to carry around on the odd chance that it will be important a year or three from now. But even so, that stuff is still running. And it's going to break. And they'll need to know about it when it does."
I started to make a joke about documentation, and he told me that was just as bad as trying to teach it to somebody. Burying a piece of information, whether in a binder on a shelf or on a page in a labyrinthine SharePoint site, is a great way to feel good about knowledge that nobody is ever going to read.
He explained that his idea was to replace historical knowledge—what he called "tribal memory"—with tools that would keep track of the "what" (the devices, applications, and elements); handle the "when" by notifying the right people at the right time (meaning when something had gone wrong); and then point them in the direction of "how" by including links to walk-throughs, diagrams, or even just having very clear descriptions in the body of the alert message or ticket.
His job was to understand the "which." Which of the tasks and technical areas under his purview were repetitive busy work that could be automated (mostly) away, and which were skills that he needed to ensure the team acquired.
I joked about how the cool kids today would call it “technical debt.” He took that gag and ran with it, explaining that his goal, like lots of folks contemplating retirement, was to pay off his entire technical mortgage and have a title-burning party.
With that frame of reference, we had an amazing conversation. I'd like to think I was able to help him out a little.
But when he walked away and I started scribbling the notes that would eventually turn into this essay, I could think of just one word to describe what it all represented: "Legacy." For IT practitioners, that has some very specific connotations—technology from a bygone era that’s still around, still requires support and maintenance, but is no longer a platform on which new solutions can be built.
But of course, there’s the more universal meaning to “legacy:” The things (whether physical or intellectual) that we leave behind after we’re gone. And I realized that our documentation, our code, our integrations, and our installations are no less a legacy than the money, photos, investments, homes, cars, antiques, artwork, or businesses left to others when we die.
And as I was scribbling my notes, I thought about making THAT the end of this essay—something like, "What will be left behind when you leave? Will you leave your inheritors saddled with your technical debt? Are you thinking about how that legacy reflects on you?"
But then it occurred to me that, as impressive as the tools and automation this guy was building was, it wasn't the most important thing he was leaving his team. That wasn’t his legacy at all, not by a long shot.
I remembered the impression he left with me: calm, confident, not needing to prove anything... of having found his niche... of having gained and kept the trust and respect from both management and his peers. Recognizing how to make decisions in his lane, and using his secure position to help others.
Maya Angelou famously said,
“I've learned that people will forget what you said, people will forget what you did, but people will never forget how you made them feel.”
So NOW I will ask you, all of you "not-done-yet" readers as well as the "almost-there" ones, to take a moment before you close this essay and ask yourself, "What is MY legacy going to be? What am I doing, today, that will be left behind when I leave?"
Anonymous
  • In Sun Prairie Wisconsin, a backhoe hit an improperly marked gas line, blew up an entire building, burned down several more, and killed a firefighter. In the end, an entire city block was destroyed by it.

    https://www.jsonline.com/story/news/politics/elections/2018/09/07/no-answers-two-months-after-deadly-explosion-rocked-su…

  • We have the same solution here in Minnesota.  They call it the "Gopher State One Call."  Call Before You Dig - Gopher State One Call

    I'm not sure, but I THINK it's illegal to dig without calling and waiting for someone to get out & spray/flag the buried assets first.

    Many mistakes and outages could have been avoided if people would be patient and learn the right procedures.  That's ALSO part of the training budget--getting the right word out to the public, training them to call before digging.  When I can rent a backhoe and tow it to any site and just start digging, what a mess of the public infrastructure I might make.

  • Well said, Rick. I work in the O&G industry and in Colorado, as in other states, we have the dialing shortcut 811, which routes to a locator switchboard for OneCalls.  If people are going to do any excavating, they are encouraged to call 811 beforehand and have the locators for the various and sundry utilities (phone, cable, etc.) come out and "tag 'em and flag 'em".  That way, there is less of a likelihood of something happening as is depicted in the above photo.

  • Agreed, again.  Documentation and labeling is where it's at.  Best practices everywhere.

    And you don't get there without training budget, and spending that budget on EVERYONE equally.

    All it takes is ONE person to miss the understanding, to NOT get the memo, to not understand policy and best practices, and you end up with a disaster.

    It's why we have GIS--to help us avoid digging where we ought not.  If we don't call before digging--or if someone doesn't record when they laid copper or fiber--it's all going to cause problems for someone in the end.

    pastedImage_0.png