It’s another T-SQL Tuesday! This month, Josephine Bush (b | t) hosts our T-SQL Tuesday discussion. Her invitation is about the data platform job titles.
I wrote a post thinking about this topic a few years ago as I was switching jobs. In my career, I’ve had job titles such as DBA, Senior DBA, Senior Database Architect, Senior Database Developer, SQL Developer, Data Engineer. This list may also be (more or less) in chronological order that I held that position. As you can guess, the titles have been a bit of mix but in many ways, my work never really changed. What changed was my skills and expertise as well as my ability to have some influence in the direction we took as a team. Plus the titles are a reflection of what was used at each company. For most of my career, my primary team didn’t consisted of other other data professionals but software developers, QA, business analysts, product and project managers, etc. When I was on a team of other data professionals, you could say our “clients” were those other roles because we worked to support those teams. If I was called in to production issues, things were going wrong.
I’ve always felt that the roles I do never really fit in when talking with other data professionals because I’ve always worked on the development side of the “house.” If you go to different sessions, when people ask if you’re a DBA, they start talking about availability groups and HA\DR or backups or server configurations, etc. While I need to understand that to do my job better, that’s not the area I work in day to day. If people ask if you’re a developer, it feels like the conversation is then geared towards those who are traditional software engineers who have to work with the database and here’s how to do these in these different languages. It’s not quite where I live either. When I said I was a DBA, I always threw in the word “development” in front to clarify. These days, I’m very careful to say “data or database professional” because of the way the industry has expanded to include so much more than your traditional RDBMS system.
Josephine’s list of titles in her invitation aligns a lot of what I imagine the list of titles for the database professional in our world looks like. But when you look at Kendra Little’s post (which Josephine also referenced), you notice that it’s a lot scaled down and a little difference. My initial reaction reading it was that the developer DBA or database developer still isn’t represented. But I find those job duties are in all of the overlaps of her Venn diagram. I follow Kendra online so I read some of the responses she was getting along the way. (Sorry for being a creepy lurker, Kendra!) If you take some of that information along with what you see described in the jobs with the various titles on LinkedIn for example, it seems like the title Data Engineer is no longer seen as the traditional database developer but responsible for the movement of data with pipelines, etc. I feel like Josephine and I see things differently than where the industry is going with titles. And as person with that title (Data Engineer), where does that leave me for the long term? Yet again, I feel like I’m that square peg for a round hole. Maybe the fact is that I am in a minority but even with that, I’m sure I’m not the only one who’s in this position.
Another thought with this: Traditionally, we tend to use job titles as a way to define a career path. If you’re just getting started as a data platform professional, what titles do you look at to get started and where do you go once you have your foot in the door? And of course, with the rapid addition of new functionality and new skills that are needs, we have to change to our titles and roles to adapt. But I wonder if there’s a more thoughtful way to categorize things to cover the different aspects.
Perhaps there is a better way to represent those who work on keeping systems up and running as well as those who are designing and implementing the different systems. How should we include the data scientist or the enterprise level architects who cover not just database design but the set up and implementation of where all of the databases need to live and fault tolerance and how data should move through the ecosystem? And is this where I ask the question about why does data modeling and governance always fall on the analytics side of the data platform when we need to care about it on the operational side as well? (OK, that last one may just need to be a separate rant blog post…)
Job titles are never easy and it feels even trickier these days. I could try to come up with what I think works so we could cover the different categories such as operational vs development as well as operations\relational vs analytics and whole other host of combinations, but it would take too much time for me to do and I’m sure I’d leave someone’s job description out. I fear we may have to do something really “radical” going forward – like make sure we have really good descriptions of what the job entails as we give some leeway to variations for a given title. We also should do a good job of level settings in terms of junior\mid-level\senior positions. While some titles really do sound better than others, we should also make sure that we don’t lose sight of making sure the other pieces are in place.
At this point, I think I’m going to go back to my original suggestion from years ago: can we just have “Deb the DBA” stand for “Deb the Database Bad A$$”?
Deb the DBA 