My dear friend Josephine Bush a.k.a HelloSQLKitty hosts this month’s T-SQL Tuesday. Josephine’s call to us is to share our understanding of the multitude of job titles available out there and what they mean to us.
![](https://curiousaboutdatacom.files.wordpress.com/2018/11/tsqltuesday.jpg?w=150)
While many job titles exist, each role’s essence is heavily shaped by the operational dynamics of the business and how responsibilities are allocated among individuals. A rough and high-level comprehension of these titles can be outlined as follows:
- Database Administrator (DBA): Responsible for High Availability/Disaster Recovery (HA/DR), Backups/Restores, security measures, including audits, storage management, code promotions, and sometimes even code reviews. Encompasses Continuous Integration/Continuous Deployment (CI/CD) and automation, and may also be referred to as a ‘Database Reliability Engineer’.
- Database Engineer (DBE): Tasked with managing database code, architecture, and data process flow. Engages in Extract, Transform, Load (ETL) processes, pipelines, and assumes responsibility for data integrity and health.
- Database Architect: Often involves a blend of DBA and DBE roles, with a substantial infusion of cloud architecture expertise.
- Data Warehouse Engineer/BI Architect: Primarily concerned with reporting, data warehousing, and data lake management.
- Data Scientist: Typically held by individuals with Ph.D. qualifications or similar expertise, focusing on algorithms and predictive analytics.
Having devoted close to two decades to the role of a DBA, I began experiencing weariness around 2018. The toll of being on-call was manifesting as severe health implications. In most settings, DBAs were perceived as reactive problem solvers—earning high remuneration but receiving little attention or respect unless a crisis demanded their intervention. In essence, proactive contributions were unacknowledged, and one’s worth was not recognized as value-added to the business. This prompted me to explore alternative roles. I authored a book for Apress, wherein I engaged with various community members to delve into their roles and responsibilities. After interviewing 29 professionals, I arrived at three viable options:
- Delve deeper into Business Intelligence (BI) and transition to reporting and BI-related responsibilities. While I had previously occupied a BI role, opportunities in this domain were limited.
- Cultivate skills in Product Management and transition into a PM or DBA management role. However, the steep learning curve and the prospect of becoming extensively people-focused gave rise to uncertainty. Additionally, I was skeptical of the fervor around Agile methodologies, as I noticed elevated attrition rates among PMs.
- Embrace a Data Engineer role that primarily involves coding and architecture. Among these choices, this resonated with me the most from a technical standpoint. While I was familiar with R Programming and comfortable with VB.net, I was uncertain whether these skills would suffice. Fortunately, the current job opening aligned with my skill set, enabling me to become a data engineer. Since transitioning, this role has proven to be one of the most fulfilling data-related experiences.
To conclude, the precise definitions of these titles are of secondary importance. The focus should lie on personal aspirations and whether a job aligns with those objectives. Thank you, Josephine, for hosting.