The other day, I was watching a YouTube tutorial on something to do with AWS SageMaker and happened to glance at this comment out of the corner of my eye:
It’s not particularly untrue. With a history in more business-oriented roles, I can definitely remember many times when technical jargon flew right over my head. Couple that with arbitrary acronyms that I didn’t realize are arbitrary at the time, and my eyes would glaze over like a Krispy Kreme donut. (I’m hungry as a write this. Can you tell?)
I see the other side of the story, too. These acronyms and jargon are helpful to describe the matter at hand in the most efficient way possible. A few posts back, I talked about how words are merely signposts to other ideas. So I could say “the environment that helps me orchestrate Docker containers” or I could say “Kubernetes,” which is the formal name of that thing I just described. Heck, I might even abbreviate it down further to the commonly used “K8s,” where that number represents how many characters sit between the “K” and “s” in Kubernetes. All of those are correct and point to the same concept, but one of them is clearly much faster to communicate than the other.
But we do unfortunately lose some communicative power with our friendly business folks. The question is, do we force our techy folks to speak with a stronger “common language,” or do we allow them to babble on in what might as well be Klingon to most people? With the exception of crazy acronyms (which even Elon Musk famously decried in Tesla), I’m actually going to side with my techy friends on this one. I’m not trying to be exclusionary here; I love explaining technical terms to interested students. It’s just far more efficient for a technical person to speak this way.
And technology isn’t really the important part anyway.
Does it surprise you to read that? I hope it did, because that’s the purpose of this post! Let me illustrate by talking about an older piece of technology, one primarily used by only the Amish these days: the horse-drawn buggy. Around the 19th and 20th centuries, this was the go-to form for getting to place to place. It was certainly rudimentary by today’s standards, but it got the job done until the invention of the car later.
And it’s probably a no brainer why we pivoted today cars. Amongst their many benefits, they were faster and didn’t rely on live animals to pull them. Another comical effect that you don’t have to necessarily worry about with cars is a horse manure problem, which actually became quite the epidemic in New York City around the turn of the century. Of course, cars aren’t the only way we get around today. We have a full transport system of trains, buses, and airplanes, all more less centered around one goal: getting you from Point A to Point B.
That said, it’s conceptually not impossible to envision a day without cars. Conceptual because this probably won’t ever actually happen, but imagine if we ever successfully invent Star Trek-like teleported. Getting from Point A to Point B just got a heck of a lot easier! I could live here in Illinois, work in California, and pick up groceries in New York without a problem. My car would only become a hindrance to my transportation then.
(Of course, I’m sure cars would stick around for hobbyist sake, but by and large, they’d disappear.)
This is certainly true for all industries. Most things serve as metaphorical “vechicles” for what you actually want to do. This is why Blockbuster failed. Blockbuster failed not because people stopped caring about movies. I don’t know this for a fact, but I would imagine that people now watch more movies than ever! It’s just that Blockbuster’s tired business model of renting movies at a brick-and-mortar store got usurped by the convenience of Redbox locations or the even stronger ease of digital rentals on things like iTunes.
Information technology is held to these same concepts. Technology is simply a means of physically manifesting concepts that transcend the technology itself. I entitled this post “Keeping IT Real” partially because it’s a bad dad-like joke but also because it drives home what all people need to remember about technological efforts. Spotify might have a wonderful backend system, but it’s useless if people magically stopped caring about music. You have to remember that these IT solutions are always tied to something real.
And the thing about technology is that it’s ever changing. The technology we used to build websites is vastly different than what it is today, even if the websites themselves don’t necessarily look a whole lot different aside from design aesthetics. You can bet that things will probably change a whole lot more in the next ten years, too.
So for my business friends here, ask yourself two questions. First, is the technology supporting the needs in the way you are expecting? This is particularly important for artificial intelligence projects that mandate a deep subject matter expertise to ensure ethical, correct results. There are certainly efforts that help broadly make things more efficient for a technological enterprise as a whole, but if you’re ultimately doing something technologically that doesn’t connect to a business driver, you ought to stop doing it.
The second question is, how do I minimize technical debt? If you’re not familiar with that term, it’s this idea of coping with older systems that don’t fare well with newer ones over time. Sometimes, this simply a matter that technology has evolved enough that it was sort of out of your control. (I’m thinking about mainframe databases created in the 1980s that aren’t exactly up-to-snuff with modern databases.) But often, technical debt comes as the result of a poorly architected system. Generally speaking, if you’re building something with a hyper specific purpose, that solution will likely create technical debt for you.
I will say… if you’re a leader working in a technological environment, I do think you need to have some level of technical expertise. I don’t think you need to be an expert coder, but if you’re going to be making decisions that may or may not add to your company’s technical debt, it would be prudent for you to get a basic education on those systems. Fortunately, there are a lot of excellent resources across Udemy, Udacity, LinkedIn Learning, and even YouTube that will quickly explain technical ideas on a conceptual level in ten minutes or less. Nice!
And that wraps up this post! If you’re a business-oriented person, I hope you’re a little encouraged by this post. We often get so into the weeds with these techy things that it’s hard to remember that they map to real world concepts, but I assure you that they do! And it’s very fulfilling when you can understand how your technical piece is driving your business’s success. Thanks for checking out this post. Catch you in the next one!