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.
- People who want to know about our stuff.
- People who want to know if OUR stuff can help with this OTHER stuff they just heard about and/or are buying.
- 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?"
