tattooeddr.ai
Recently, someone who had seen my LinkedIn profile asked me: “do you have experience in data engineering?” Lol, facepalm emoji, and an animated gif of a drag queen making the tongue pop sound (#AlyssaEdwards).
Why the reaction?
I started in data and analytics in the late 90s.
Yep, the nineteen-nineties. Back then, we thought that at midnight on December 31, 1999, subway trains, elevators, airplanes, power plants, and the like would suffer catastrophic failures due to a computer programming practice that had become the norm in the 1980s. I lived in Sydney Australia at the time, where on New Years eve the subway had a scheduled closure from 11:30pm to 1am to avoid the danger of trains running as the clock ticked over to 2000. So, let’s just say it was a different time, maybe even a golden era (#SarcasticEmoji).

My point is, at that time, we (i.e. data people) were all data engineers. We were also data modellers, QA analysts, data stewards, architects, data visualization specialists, data storytellers, and business analysts. My first job title in an analytics role was PeopleSoft Specialist—data wasn’t even in my job title, although my job was to produce reports and analytics from PeopleSoft ERP.

So, what about today?
Today, we focus on specializations in data: engineering, architecture, Data Modelling, Data Governance, etc… please don’t get me wrong; I am all for it since it creates opportunities for people to go deep into one space (that they presumedly love). People can spend the entire day focusing on one (or a few) very defined activities.
However, I also ask what we might give up in our pursuit of specializations. In business management, we often think in terms of value chains, i.e., how we create value. Playing that forward means we work in teams of specialists. We transition work from one specialist to another—and to quote a colleague—in a factory-like production line. Some people deal with raw resources, others transform those resources into products, and others market those products to consumers.
And here’s my point:
A) Intergenerational Workforces
Well, I have three points—and each of them is actually a question. First, in intergenerational workforces, we might have to question our assumption that people are one thing (e.g., a data engineer) versus another (e.g., a data architect). This also raises the spectre of functional resumes—should we, in the data space, structure our resumes around our technical expertise and focus less on our job titles and accomplishments? And then, what should I look for when I am hiring someone?
B) what should leaders do
The second is that if we transition work from one specialist to another (and there’s nothing necessarily wrong with that!), then the role of the supervisor or manager probably includes ensuring that the hand-offs are efficient and effective. So—the higher you go in management, then the more generalist knowledge you need. So—how are people in their early careers learning the skills and gaining an appreciation of what happens in the other specialty areas? How do current leaders create these opportunities for the next generation? And how good are colleges and universities at teaching this to students? While it’s true that in mega-corporations, you can find an SVP of Engineering role (and arguably, you might not need to understand the other specialist areas in data), I think in the vast majority of companies, that’s not the current reality.
C) what do early career data-focused people want?
My final point is I’d love to know what early career data people would ask of me or someone like me. From a development point of view, I’ve had valued technical mentors, and I’ve had (and continue to have) people who are influential business mentors, too. What’s one thing (or two) that people with long experience in the data field, or others who have established themselves in this space, can do to help you get a leg up and propel your career in the direction you want to head?

Leave a comment