DBA Career Levels

Starting from the first day the career levels could be something like this.

Trainee

Assist on tasks and issues. Can be given trivial tasks with some training. Mentor assigned to introduce to profession.

Junior (Level I)

The Junior DBA resolves issues while developing professional skills. Handle assigned tasks. Check test results. Will mostly work individual, but will have a close colleage as mentor (Sensei).

Usually with up to two years of experience. But the period length is not defining - it is the capabilities.

Specialist (Level II)

Works on troubleshooting, review and test. Does now have solid fundamental skills.

Between two to five years of experience. Unusally depending on the organisation, capabilities and the mentor (Sensei).

Senior (Level III)

Now works as individual contributor with deep understandings. Ownership of technical components like SQL Server components. Key resource in problem analysis. Give process recommendations. Comprehensive knowledge of practices and organization structures, both formal and informal (goat paths).

Develop and present proposals, also to customers. Negotiate project and product technical terms and requirements with vendors and customers. Participate in pre-sales. Professional mentor (Sensei). Key business knowledge. Recognized for technical skills on international level with influence on wide organizational level.

Typically more than five years of experience. Often more than ten years.

Principal

Designing and presenting technical stratigies. Setting department goals and creating implementation plans. Setting and manging engineering budgets.  Develop and implement proces improvements.

Provide expert advise. People management in research and design. Professional and career mentor (Sensei) but not as primary priority. Deep business knowledge.

Now it is no longer a matter of years but more of capabilities and ambitions. Usually has at least a bachelor degree.

Chief

Deep technical understanding. Manage development through the entire program with interpretation of central demands. Take major and difficult technical decisions. No people management and no yearly budget. Only funding on activities from senior management. Direct contact on a regular basis with senior management.

Very rare title on a DBA. Take a look on a Toyota Chief Engineer to se details and examples. Usually a Chief is assigned a new product or a new edition of a product.

Master

Guiding and training professional teams and individuals. This is the primary focus. Deep knowledge and experience in both tech and processes. Can also be called Sensei in a Lean context.

Executive

Part of senior management. Set budgets. Define products and projects.

Driven by career ambitions.

Very rare title. Most people has left database administration many years before this level is relevant to pursue a more focused business career.

Inspiration

• SHIFTMAG: Engineering career levels explained.
• indeed: Principal Engineer vs. Senior Engineer.

History

2025-05-02: Chief role added.

2024-12-23: Master level added.

2024-11-16: Post created.

DBA Questions

These questions are relevant your first day on the job as Database Administrator. Also the questions are usefull to look at on a regular basis like a couple of times every year.

Q1: Where are the backups?

This is all types of backup files; full, differential and log backup files. And on all databases.

Also the backup files on the Service Master Key (SMK) and the Database Master Keys (DMK) on the system database [msdb] and the user databases with encrypted columns. This might require some investigations on encrypted columns.

This is most likely the most important question the first day.

Q2: How are the backups created?

Get concrete quickly and ask about tools and schedules. Get to know all the tools all the way to the last storage area. If you want to be a little more confrontative you could ask for the definitions of the processes to handle SQL Server recovery. I would wait a couple of weeke at least and prepare the formulation.

If the backups are created by SQL Server Maintenance Plans you should consider that as an anti-pattern and be cautious.

Q3: How are the backups used?

At first you should focus on database restore. Ask for a recovery plan and restore guides. The restore guides are the most important.

Be aware of the tools used for restore. Are they general available or are you to install them by your self? In what context are the tools to be used? Is a special user or other access required? Is a priviledged access device required?

Then you can open up and ask for a report from the last recovery test. Also you can ask about your new collegues personal experiences with recovery. Both in general and in the actual organisation.

Please remember that it is not you but the SQL Server service accounts that require access to the backup files.

Q4: How do I get administrative access to the SQL Server installations?

Do I have to apply for AD groups? Or apply for an administrative account? Or a combination? Is the access permanent or only by request? This is also you first peek into the security structure build around the SQL Server installations. The approach to SQL Server security is usually unique to organizations and people. A lot of people say that there is a strick role-based (RBAC) security model, but usually the reality is way different and with several variations.

Q5: What are the three most important systems using SQL Server?

Limit the question to three system. This you can look into the first day. Do the rest later.

Ask about a inventory on these systems. What databases, servers, contact persons etcetera.

Q6: What is your phone number?

Ask this question to your new collegues, Incident Management, line manager and the IT manager. Enter the numbers in your personal contact list. Decide by yourself who will have your private phone number. Personally I always have two phones, one job and one private. Also I am rather picky with who have my private number. Especially if I am not paid to take calls outside office hours.

DBA Backlog

As a Database Administrator both in projects and daily routines like administration or operations all kinds of things show up. Normally they are associations that doesn't really fit in the plans or the context, but still relevant or even important in the long run.
Usually these things and ideas end up on post-it notes, whiteboards or another volatile medium. If you are lucky to be in a large project with experienced developers and project managers some items might be saved.

Another way is to create your own backlog of ideas, points of interest, nice to haves and other things that might make your works better. In ITIL these things will be considered part of Continual Service Improvement (CSI) as input to the Plan part of the Deming Circle.

I have collected a set of attributes I have used to establish a backlog in a project or a team. Not all attributes are relevant in each situation. Sometimes it is also necessary to twist an attribute to make the backlog usable.

And to my proposal for a general backlog:

Attribute Name	Attribute Description
Title	Short and descriptive title of the backlog item.
Theme	Predefined themes to sort the backlog on a "dimension" like technology. This is very useful when the backlog grows. { SQL Server | SSDB | SSIS | ... }
Description	Prose description of the backlog item with as many details and thoughts as possible. The description can easy change and grow over time, even before the backlog item is activated and processed.
Priority	The priority of the backlog item. Predefined values that makes sense, even to senior management. { Critical | High | Medium | Low }
Abstraction	This item can be added to the backlog if you are working with defined abstraction layers from idea to solution. This is sometimes seen in agile development methods like SAFe. { Epic | Story | Task }
Status	Status of the backlog item. The values are inspired by Kanban to support an effective execution of the backlog. "Keep the Ready queue short". { Backlog | Ready | Doing | Done }
Estimate	A quick estimate of the time needed to process and finish the backlog item. The item is finish when the issue is solve and documented – completely. As in agile development. { Day | Week | Month | Quarter | Year }
Deadline	Date of deadline, if one is required. If a deadline exists it is usually given by business or management.
Changed	Timestamp of last change to the backlog item. Consider to enable automatic versioning on the backlog.
Created	Timestamp of when the backlog item was created. Usually when the item was entered into the backlog.
Changed by	The person who last changed the backlog item.
Created by	The person who created the backlog item. Usually the person who entered the item into the backlog.
Tangible	This is more a business attribute that tells about where business can relate to the backlog item.
Owner	Business owner of the backlog item.
Responsible	The person who is responsible on the backlog item. Usually the person who is to get the job done.

I personally have good experiences on building a backlog as a SharePoint list rather quick and effective. This also gives all the SharePoint features on filtering, printing and other trivialities.
Another possibility I have tried a few times is using the backlog features i Microsoft Team Foundation Server (TFS). It works really nice also for Database Administrators.

History

2017-04-02 Blog post created.
2017-05-08 Abstraction element added to backlog schema.