If I wasn't, would I have proposed the following topic for several speaking chances, including SQLRally?

Being a specialist means you're really, really good at one thing. Being a generalist means you're good at a a lot of different things. The generalist has an advantage over the specialist because he or she can see and solve problems the specialists can't. In this session I'll cover why it's important to diversify your skill set, not only for career protection, but to be better as a database professional. Taken from my own experience as an infrastructure architect, security professional, developer, and SQL Server DBA, we'll look at what skill sets to build on to expand your abilities around SQL Server to include the operating system, development, networks, and security. Remember, this saying isn't complete, "Jack of all trades, master of none." The full saying is, "Jack of all trades, master of none, though often times better than master of one."

I believe in Adam's extension of the saying "Jack of All Trades, Master of None" which is the last line of that abstract:

"Jack of all trades, master of none, though often times better than master of one."

In my career I've been a developer. I've been a system administrator. I've dealt with storage. I've been an infrastructure and security architect. I am currently a DBA. I've been an incident response team lead. About the only area of IT I've not spent a great deal of time in is on the mainframe. That's an area I wish I had an opportunity to fix, because they are I/O behemoths. What I find is having a breadth of skillsets means that in troubshooting situations, I've got extra tools to bring to the game.

For instance, when troubleshooting a lot of server or AD issues, the first words out of my mouth are usually, "Let's get a packet trace." By looking at the packet trace I can often see things that aren't easily visible any other way. For instance, when servers at a remote location stopped authenticating against AD, I was able to see that the firewall device there was dropping key packets. All the fingers were pointed at AD until I showed the packet trace. It's not just about keeping out of the blame game. It's also about getting to what the real problem is so that end users can be up and running as quickly as possible. If we had stayed looking at AD, it would have been a lot longer before we would have gotten around to guessing it might be the network device. However, one packet trace, 10 minutes of work, and we had the real culprit. That's why I spread out my knowledge and skills.

Another example: by understand how HTTP works I can troubleshoot a web application and prove it's not my database server. I did that not too long ago. An application wasn't connecting properly to the DB server. It was making a reference to something else that wasn't up. But the whole website was down. The blame came at SQL. It wasn't. It was that the component that wasn't up was in the master page for the web site. And the error page was built off the master page. So guess what? With that other component down, you never got a page because the error page generated the error page which generated the error page which... endless loop. Using Fiddler, I could see the repeated 302 response headers coming back. And that's when I asked about the error page versus the master page.

So I don't ever plan on specializing. It requires  more work to stay up on more technologies. And it means I'll never be, say, an Allan Hirt with respect to HA or an Andy Leonard with respect to SSIS. But it does mean I can look at a situation and have a good guess if it's an AD issue, if there's something going on at BGP/EIGRP level, or if it really is SQL Server. And I'm happy to be right where I am at.