It’s the second Tuesday of the month again, so that means that it’s time for another T-SQL Tuesday. Our host is Josephine Bush, and she wants us to talk about the often confusing job titles in the data world.

And while I will (of course) share my thoughts on that topic, I have decided to also include a short rant about a very much related topic: tracks on conferences. Those who have submitted conference talks before will probably immediately understand why I call that a very much related topic. The rest will have to read on!

Job titles

I advertise myself as a “Database consultant”. That job title is pretty vague, and that is intentional. Even though I have chosen to heavily specialize, I still also have a broad understanding of a large number of data and database related topics. Sure, I can use execution plans to optimize the heck out of your slow queries. But I can also write fresh T-SQL code, create a perfectly normalized data model and database design, set up maintenance and data recovery, set up and oversee a data migration project, design a new application architecture, hunt and fix bugs, install a new database server, and much more.

While I have had clients that actually made me do all of the above, it is more common to be hired for my key skills. And that means that most of the time, I find myself designing and implementing database changes, writing and maintaining T-SQL code, and, of course, optimizing slow queries. So when I know that that is my role in a company, then I can of course also give myself a more specific job title. Right?

Well … no. Not exactly. I do tend to call myself “database developer” internally in those companies, because I personally feel that this best describes what I do. But not everyone agrees with that. And there are two reasons for this.

Who does what?

Something I have ran into far more often that I would like, is that there simply is no single standard to define what elements of a job description go into which “job title” bucket.

Sure, some things are clear. Nobody will doubt that the DBA should run backup and restore, do consistency checks, guard available disk space, etc. Nobody denies that an architect is responsible for the application architecture. And everyone agrees that an application developer should write application code that, for complex operations, calls a stored procedure written by a database developer.

But even then, there still are many grey areas. Who is responsible for designing the tables? Is that the architect, of (if there is one) the data modeler? Or does their responsibility end at the conceptual design, and should a DBA convert that data model to an implementation-specific optimized database design? And then there are also companies where development follows a code first philosophy, meaning that effectively the application developers do the database design, and all the database developer and DBA can do is try to fix the mess.

And who should we look at for query performance? Does the task of the DBA end at identifying performance bottlenecks, that they then hand over to the database developer to fix? Or should the DBA be the one to look at execution plans, redesign indexes, and rewrite queries to improve performance? Heck, I have even seen companies where only the DBA was allowed to touch indexes, but the database developers were in charge of the query code. Which provides for a nice separation of duties, but leaves a huge gap in the responsibility matrix when it comes to query performance.

Vague boundaries

And even when the job descriptions for each job title are clear, it can still be hard to exactly map activities to job titles, because in practice, the boundaries of each job are always a bit vague.

Partly this is because of the nature of our jobs. If I am a database developer who will write the code for a new application, I want to sit at the table where the architects discuss the data model, the functionality of the application, and the boundaries of the application and database layers. Not because I want to do their job, but because their choices affect mine. And with almost forty years of experience in this business, I believe I can provide valuable insights that I want to be heard.

And the other reason is just everyday reality. Very large companies with a whole DBA team, several development teams, and a separate architecture department may not run into this. But smaller companies do. One day, the DBA is sick, or on leave, but something needs to happen anyway. I can stubbornly sit in my cubicle and refuse to step up, because my job title is database developer, but the right thing to do would be to assess whether I have the skills to do what the company needs, and then offer to do it.

And it gets worse for even smaller companies. One of my clients just had a single person who understood databases enough to be safe around them, and that was me. Sure, my job title was “Data migration lead” (because I was hired for a database migration project, that was canned after a few months). But my actual activities were a combination of architect, data modeler, database developer, DBA, and even a bit of support.

Conference tracks

Job title versus actual activities is not the only unclarity in our field. For someone who likes to present at user groups, Data Saturdays, and larger conferences, there is a similar confusion when it comes to submitting talks.

Almost all conference organizers ensure that there are multiple tracks during their conference. That helps attendees to quickly filter out talks that don’t interest them. Someone who is always working in the BI stack, or who wants to learn about BI so that they can find a job in that area, doesn’t even need to look at presentations in the “Enterprise database administration” track. Those will never be interesting for them.

But one challenge for speakers (and to a lesser extent also for attendees) is that ever conference seems to have its own collection of tracks. One conference might have “Analytics”, “Architecture”, “DB Management”, “Development”, and “Professional development” (which by the way does not suggest that “Development” is for amateurs, “Professional development” essentially means improving your soft skills and other non-core skills that contribute to how well you can do your job). Another conference offers tracks such as “Cloud”, “Data Analytics”, Data”, and “Professional development”. And yet another one could offer “DBA”, “BI”, “Data science”, “Data developer”, and “Professional developer”.

SO let’s say that you submit a talk about how to choose whether to host your database on premises or in the cloud. For the first of the conferences above, that would go into the “Architecture” track. For the second, you should probably submit it for the “Cloud” track. And for the third … well, I’m actually not even sure what track it would go into, since it fits neither. Or perhaps it fits three of them, depending on how loose you draw the boundaries.

And that brings me to the second point. Even if all conferences would use the exact same tracks, there would still be a lot of situations where a speaker has trouble deciding what track to submit their talks to. And that ties in very closely with the unclarity of job titles above, because in many cases, the conference tracks more or less loosely tie in with job titles.

Looking at my own experience, most of the conference talks I submit are about query tuning, usually using execution plans as a starting point. But as already mentioned above, I don’t even know what job role is responsible for query tuning. Is that the DBA or the (database) developer? Well, many conferences have one track that is targeted at the DBA role, and another track targeted towards developers. Which track should I select when I submit “Execution plans … where do I start?”. And which track should an attendee check in the session list when they want to learn about query tuning?

Conclusion

There are many job titles in the field of data professionals. Most job titles have a clear defined core set of activities, but a very rough boundary, where that job title overlaps with activities of other job titles. Lack of standardization means that this can vary from one employer to another, and everyday reality means that people often have to do work that is not formally part of their job, but that still needs to be done.

Conference organizers try to organize their content in tracks, that often align with job titles. Which means that it is often just as vaguely defined as those job titles are. And which means that any expertise that lives at the boundary between multiple job titles, does not neatly fit into any one track either.

Twenty years ago, I would have said that the unclarity of job titles is due to immaturity of our field. But we’re in the twenties now. Our field should not be immature anymore. In many aspects, it isn’t. But in the area of job titles, we have been slacking. Job titles and the associated work should be standardized, so that someone who loves to tune queries will finally know whether to apply for the DBA role or for that database developer role.

Of course, that does not mean that employees should rigidly adhere to those boundaries. If there is a need to do a job, you can do it, and nobody else can … then just do it! Even when it’s not formally part of your job description. As long as it does not become a fixed part of you job, of course … because if that happens, then you should also receive the associated raise.