You Don’t Need to Know Everything

One of the things I’ve learned over the years as a database administrator is that being a good DBA does not mean knowing everything.

In fact, the longer you work in IT, the more obvious it becomes that you can’t know everything.

As a DBA, you’re often asked to investigate problems that aren’t really in your swim lane. Sometimes you’re brought into an application outage because someone noticed that the database is involved. Sometimes you’re asked to help with a deployment because the application needs a database change. Sometimes you’re handed a connection error and told, “The database isn’t working.”

And sometimes, the database isn’t the problem at all.

You may know the database engine inside and out, but that doesn’t necessarily mean you know the middleware sitting between the application and the database.

You can provide a connection string, but that doesn’t mean you know the specifics of the vendor’s database driver, connection pooling implementation, or application configuration.

You can back up a database, restore it to a new server, configure the instance, and make sure the database is healthy—but that doesn’t necessarily mean you know everything involved in migrating the application that uses it.

That’s okay.

One of the worst habits you can develop in IT is feeling like you have to immediately know the answer to every question you’re asked.

You don’t.

I’ve found that one of the most useful things you can say when you’re presented with a problem outside your area of expertise is:

“That’s outside of my area of expertise, but I’ll take a look.”

There’s an important distinction in that statement.

You’re not saying, “That’s not my problem.”

You’re also not pretending that you already know the answer.

You’re saying, “I don’t know this yet, but I’m willing to investigate it.”

That’s a very different attitude.

The DBA’s job isn’t to know everything

A database administrator has to have a broad enough understanding of the environment to troubleshoot problems that cross boundaries.

That’s part of the job.

If an application can’t connect to SQL Server, you should probably understand enough about networking, DNS, authentication, firewalls, TLS, connection strings, and application behavior to start narrowing down the problem.

But there’s a point where your expertise ends.

Maybe the application uses a proprietary middleware platform you’ve never touched.

Maybe the vendor uses a driver you’ve never seen before.

Maybe the application team has implemented connection pooling in a way you’ve never encountered.

Maybe there’s some obscure configuration file buried three directories deep that controls how the application communicates with the database.

You don’t need to become an expert in that technology just because it happens to be involved in a problem you’re troubleshooting.

You need to understand enough to determine where the problem is—and who is best equipped to solve it.

That’s an important skill in itself.

Learn enough to ask better questions

This doesn’t mean you should immediately hand the problem back to the application team.

Quite the opposite.

If something is outside your expertise, investigate it.

Read the documentation.

Look at the logs.

Search for error messages.

Ask someone who knows the technology.

Figure out what you can determine from your side of the boundary.

Maybe you’ll discover that the database is rejecting the connection.

Maybe you’ll discover that the connection never reaches SQL Server.

Maybe you’ll discover that the application is using a completely different database server than everyone thought it was.

Every one of those discoveries is useful.

And sometimes, while investigating something outside your normal responsibilities, you’ll learn enough about that technology that the next time it happens, you’re a little more prepared.

That’s how you build experience.

But there’s another important lesson here: learning something doesn’t mean you have to own it.

I’ve seen people in IT fall into the trap of becoming the person who knows a little bit about everything.

That’s valuable up to a point.

But if you’re not careful, you can end up being responsible for twenty different technologies while never having enough time to become truly good at any of them.

There’s a difference between being capable of troubleshooting something and being responsible for administering it.

Know that difference.

Don’t be afraid to say “I don’t know”

There’s nothing wrong with saying, “I don’t know.”

The problem is when you stop there.

“I don’t know” followed by “but I’ll find out what I can” is completely different.

You don’t lose credibility by admitting that you don’t know something.

You lose credibility by pretending you do.

And if you work in an environment where people expect you to have every answer immediately, it’s worth remembering that the person who confidently gives the wrong answer is much more dangerous than the person who says, “I’m not sure. Let me investigate that.”

You don’t need to know everything.

You need to know what you know, what you don’t know, and how to figure out the difference.

That’s a pretty good skill for a DBA to have.