Andy Mallon is a Product Manager at SentryOne, SQL Server DBA and Microsoft Data Platform MVP who has managed databases in healthcare, finance, e-commerce and non profit sectors. He is the SentryOne 2016 Community Influencer of the Year, the founder of Boston SQL, co-organizer of SQLSaturday Boston, and a speaker at SQL Server user groups and SQLSaturdays . He is also the founder of Boston SQL, co-organizer of SQL Saturday Boston and a frequent speaker at SQL Server User gropus and SQL Saturdays.

Andy started working with SQL Server as a support tech for a startup software company. Unlike most “accidental DBAs,” Andy knew early on that he loved SQL Server and wanted to become a SQL Server DBA. He shares his passion for SQL Server by blogging at Andy M Mallon – AM² ( am2.co ) and SQLPerformance.com .

Andy, his husband, and their dogs live in the same community where he grew up, just outside Boston, Massachusetts. He can also be found on twitter at @amtwo.

Mala Mahadevan: Describe your journey into the data profession.

Andy Mallon: I started my very first job at a software company. I worked mostly in tech support. It was a small company, so there was a lot of wearing multiple hats, but it was primarily training and tech support. We did a lot of database-heavy tech support things, so I learned SQL Server in that first role. I realized that I liked working with databases, and I really wanted to be a DBA when I grew up.

I had a number of tech support roles, increasingly focused on databases, SQL Server, and Oracle, until I finally had the opportunity to have a position as a database engineer, which was effectively a junior DBA job. Then, I got a “real” DBA job, where I was hired to be a full-time official DBA.

Mala: Describe a few things you wish you knew when you started your career and that you know now, and you’d recommend to somebody who’s looking to be a DBA.

Andy: I wish that I knew about imposter syndrome, especially since I recognized fairly early that I wanted to be a DBA. I spent a long time thinking that I didn’t know enough to be a DBA, and I wasn’t quite sure where I would get that knowledge, or how I would do that. Most of the DBAs I worked with early in my career were really fantastic—complete star DBAs that really knew their stuff. I looked at them and thought they knew so much more than me, I wouldn’t be able to get a DBA job.

Now, I know that a lot of people end up getting DBA jobs when they’re still figuring stuff out. I knew enough to be a junior DBA long before I ever got the actual job. I could have made that jump sooner, but I was too afraid that I wasn’t good enough, and that got in the way of me progressing my career faster. I still have those moments where I feel like I’m not good enough, or I don’t know something as well as other people do, or I’m somehow faking it in my career.

But now, I do understand imposter syndrome more. I’m able to recognize what it is most of the time and have that internal dialog over whether I’m getting in my own way. Do I actually need to learn something more? Do I need to do more? Am I actually just better than I recognize that I am?

Mala: What’s your experience with agile methodologies in regards to database administration?

Andy: I’ve never worked in a position where we formally used agile methodologies for being a DBA. I’ve taken some classes for it, and I do find that a lot of the concepts helpful as far as sprint planning and time planning. As a DBA, you can’t plan out two weeks’ worth of work and stick to that. There are just too many surprises that come up along the way.

But when I studied agile, I fell in love with the idea of taking a chunk of time, working off of a prioritized list of the things that are the most important that need to get done, and picking the stuff that you can do in the set amount of time that you have, even if it’s planning one day’s worth of work that way. You look at what you have to do for the week and plan a day where you can pick out what you can actually accomplish in the day and be realistic about it. That really helps to get stuff done, and to be able to accurately tell people when you’re going to be able to deliver something.

So the area that I feel like I’m using the agile methodology most is with a one-day “sprint”, where I plan my day and work through my day as if it were a one-day sprint.

Mala: Describe your experience with cloud adoptions .

Andy: I think an interesting thing with the cloud is that there are a lot of companies that are really excited by the idea of the cloud, but it’s hard to take existing software and realize the benefit in the cloud. If you’re building something new from scratch, it’s easier to build it to work well in the cloud, but if you have existing software, a lot of times cost or other system integrations end up getting in the way of being able to really use the cloud.

Most companies are excited to move to the cloud, but then, in reality, it’s a fairly slow move and you have a hybrid data center where a lot of the existing systems, and larger HR and finance systems end up being on-prem because companies can’t afford to spend that much money to put it in the cloud.

Then they’ve got other software that they’re able to put in the cloud and slowly start to move it—even though maybe the CTO is all excited about going full-in on the cloud and putting everything in the cloud. They think they’re going to save a bunch of money , but in reality, the cloud can be expensive. It’s a shift in what you do—a shift in how you spend money and a shift in the type of work that you do, but it’s not some sort of magic.

Mala: Terrible for your cost savings.

Andy: Yeah. If you’re moving to AWS or Azure, Amazon and Microsoft make money off of that, and the reason they make money is because it’s not free.

If it were really saving that much money, Microsoft and Amazon wouldn’t be making so much money.

Mala: So, you recommend the cautious approach and understand that it’s not going to save you a ton of money up front?

Andy: Yes. Absolutely.

Mala: What are some of your favorite SQL Server features?

Andy: I really love replication. I know that that’s an unpopular opinion to really love replication, but for reporting and for getting data from one spot to another, it’s so straightforward. It does have its problems. When it breaks and goes wrong, debugging it and digging through it can be hard. The tooling that Microsoft gives you isn’t always the easiest to sort through.

But I really love replication for creating reporting environments, for moving data between servers. So it is a favorite.

My other favorite feature is Availability Groups—to set up high availability or disaster recovery environments. The multiple node availability group has the option to scale out reads to other nodes, and it’s fairly easily protect your entire database to keep it highly available, or to ship a copy off to some DR [disaster recovery] site.

Again, it’s a feature that needs a little babysitting and some expertise to use, but it’s a really awesome feature for a DBA to use.

Mala: Are there third-party tools and techniques that you like to use as a DBA?

Andy: Any time I have a new server, I always install sp_whoisactive, and Ola Hallengren’s maintenance tools, and the open source First Responder Kit from Brent Ozar Unlimited. Those three tools I install on every server that I administer. I also am completely in love with Plan Explorer and the SentryOne monitoring tools, Plan for performance and query tuning. It offers so much more detail than the regular execution plans in Management Studio. Some days I spend more time in Plan Explorer than I spend in Management Studio.

Mala: Are there any trends in this line of work that you’re looking forward to? Any particular technology that you’re watching grow?

Andy: It’s interesting because technology is always changing, and keeping up with the latest changes is very important to your career because new features and new technology don’t usually get adopted right away, but eventually people start using it.

When I was starting my first tech support job, virtualization was a new thing that nobody was using, and now practically everything is running virtual. And now I think the cloud is in that kind of space, where a lot of people aren’t using it and don’t really see where they’ll get their benefit. But there’s a lot going on in the cloud. Certainly, Microsoft’s investing a lot in their cloud technologies to try to make them compelling and make it easier for people to start using it.

I think everyone knows that the cloud is the next big technology that they need to keep up with, but I also think that from an individual development perspective, what people really need to think about learning and being better at are automation and architecture. When you’re in the cloud, you’re building things by piecing different services together and figuring out how to connect part A to part B.

People really need to be good at that architecture piece of taking a service like Azure SQL Database, and thinking about how to take all of these services and piece them together to make your big product that you’re going to sell and that your company is going to make money off of. There’s a lot of automation that goes on with that. A DBA is no longer worrying about where to put data files on drives. It’s more about creating a new server and just spinning up another Azure SQL database that is exactly like the one that you did yesterday.

And doing that in the cloud is really easy, but you have to be good at PowerShell and scripting in order to make that happen.

Mala: What sort of struggles have you faced with management on the business side of things, and what’s your recommended approach to handling that?

Andy: I think everyone has probably had a job where the business, their management, or other people were resistant to change. I’ve certainly had my fair share of cases where I wanted to make a change, or I had something that I was advocating for, and I needed to convince other people that it’s the right idea. The DBA sometimes gets to just make the decision and tell everyone to follow along, but in most cases, you’re not the only person making that decision. You really need to be able to communicate with the other people directly on your team—particularly the people who are going to be making the decisions—that something is the right choice. You need to convince other people that it’s the right choice so that everyone is on the same page.

That kind of communication doesn’t always come easily for IT pros. We’re not always the best communicators. There are certain things in particular—like careful word choice—that people need to think about when they’re talking, especially to managers or the business, to make sure that you don’t accidentally offend someone.

Sometimes the people who are resistant to change are the people wrote or built the thing that you want to change. If they’re a manager and they’ve been there for a while, you might be changing their “baby.” You want to make sure that you don’t accidentally put down that thing that you’re changing, because although it might not be the right solution now, that doesn’t mean that it was a bad choice when they did it. What’s “bad code” today might have been the best code to write at the time.

For example, you need to understand that the most important thing when it was written was that it be done that day.

In that case, it doesn’t matter how ugly the code is, it had to be done “today.” Perhaps it worked great for five years, if that code doesn’t perform well now, you need to rewrite it. But people need to steer clear of how they describe that “bad code” because it might have worked great for five or ten years, and that makes it pretty good. It’s far too easy for people to accidentally offend someone, and then you can’t convince that person that what you’re doing is the right choice because you’ve accidentally offended them by trashing their “baby.”

Mala: What sort of issues are caused when you interact with other technologists, like SAN admins and network folks, and how do you handle that?

Andy: In a way, it’s usually a combination of the communication that I mentioned before and also everyone is looking out for what’s best for them. I’m looking out for my databases and what’s best for my databases, and the developers are looking out for their priorities. Oftentimes, maybe what’s easiest for me to do on the database involves more work from a developer—and what’s easiest for the developer involves more work for me.

Everyone has to be willing to give and take some to figure out what’s really best for the company, or what’s best for the organization, and sometimes it involves the very uncomfortable conversation of reminding the other people that everyone needs to do what’s best for the organization. In the case of the DBA, one of the things that I frequently find myself arguing with developers over is staffing—there is one of me and there are forty of them. They can spread out a little bit extra work across forty people to make my life easier, and sometimes that’s the right choice. Purely because there are more developers than there are me, it can be done faster. And in other cases, the right choice is something that is really hard for me, but it’s the right choice and I need to figure out how to spend, perhaps eighty hours building something new because it’s the right thing, even though I don’t want to do it, and I don’t know where the time and effort are going to come from.

I’ve had more than one conversation where I realized that I’m arguing for what’s best for my databases, and the storage admin is arguing what’s best for storage. And we’re both right because we’re both arguing what’s best for ourselves. You really have to get everyone to come together so that everyone is on the same page with not just what is best for the database, or what is best for storage, but what is best.

Or sometimes it is just coming up with what is best for now.

Mala: What’s the role that documentation plays in your job?

Andy: I’m a very firm believer that I shouldn’t be the only person that can do anything. Because if I’m the only person that knows something and I have some knowledge locked away in my head, it means that when I go on vacation, if that thing breaks, then they need to call me and ruin my vacation, and I don’t like to do that. And it means that if it breaks in the middle of the night, I have to wake up.

So, making sure that things are documented somehow is important. It doesn’t have to be the greatest documentation. It just has to be good enough that people can figure it out. For me, that usually means having some comments right in my code that explain what’s going on, and then points to something with more information. If I can keep my code self-documenting, it’s easy. You keep it up-to-date, because if I change the code, I can change the documentation. If I change a SQL Server Agent job, the description is right there, and I can change my documentation on that job without having to go to a wiki or some other spot.

But when I do have to have some other spot where it’s documented, I just make sure that there’s a URL, or some pointer, to that other spot from the code so that it’s easy for me to find it so I can keep it updated. It’s easy for someone else to find it if I’m asleep or on vacation and someone else has to look at it, they can find my documentation easily. If something breaks in the middle of the night, the documentation has to be there so that I don’t get woken up, but then it also has to be able to be found. If someone can’t find it, it’s not very useful documentation.

Mala: What are your favorite books, blogs, and other means of learning?

Andy: For books, one of my favorite books is SQL in a Nutshell by Kevin Kline [O’Reilly Media, 2008]. He gave me an autographed copy after I started blogging, and speaking, and being more involved in the community. That particular copy that Kevin gave me, the gift and the inscription together, mean a lot to me from a career perspective. More importantly, it’s a book that I already love—and now I have a treasured copy as well—means a lot to me. It was one of the books I used as I was learning SQL Server because it was really straightforward and I could figure out what I needed to. I was learning on the job and when I needed to figure out how to do something, that book helped. It is definitely my favorite book.

In general, I learn most things through blog posts and through much shorter things. So when new technology comes out, or old technology that I’m using for the first time, I generally go straight to blogs for learning. SQLPerformance.com and SQLskills.com are two of the blogs that I read on a religious basis where when new content comes out. I at least read the title and introduction of every post to see if it interests me because I really love the deep dive content.

The SQLskills blogs come from the whole team of consultants there. They’ve just got such deep knowledge of the things that they do. They often talk about the internals of what’s happening, and that kind of blog post where it describes what’s happening on the inside. It helps me really understand how it works, not just what it does.

Mala: Are there any conferences or any in-person learning events that you’re particularly fond of?

Andy: My favorite in-person learning events are SQLSaturday and user groups. The local events really give you the opportunity to interact with the class. If you’re at a large conference, and you’re one of one hundred people in the room, it’s a lot harder to interact with the person who’s teaching and to get some time one-on-one time with them before or after, or to ask questions during the session. The structure of those larger conferences makes all of that a little bit harder.

When it’s a small user group or a SQLSaturday, you can interrupt the session for questions and the time format is usually more open at a user group. It’s not a strict one-hour box. There’s really a lot of opportunity there to not just have data thrown at you, but to talk to the person and get your questions answered so that you really understand it. You’re not just trying to follow along with what’s coming at you.

Mala: What are your recommended ways of stress management and developing a healthy work/life balance?

Andy: I love to cook. If I have a stressful day at work, I like to come home and cook dinner. My husband hasn’t had to cook dinner in a decade because I love to cook so much.

Mala: He’s lucky.

Andy: I’m a lucky man too. He loves that if I have a stressful day, I come home and I cook. And then when I’m done cooking, I’ve relaxed and I’m no longer grumpy from my stressful day at work. Also, on Friday nights, we do a date night. Every Friday night, as long as we’re both in town and not traveling for work, we go out to dinner. We can have that time where we’re just talking to each other. It’s dedicated personal time where I’m not looking at my phone. Even if I’m on call, we still go out to dinner. I might have my laptop in the car, but it’s just making sure that we have some time together.

I also love to go to Maine. Being in Massachusetts, it’s a few hours ride to get up to the woods or to the ocean up in Maine. It is someplace that I can go fairly easily in just a couple hours’ drive to get away. It is a happy place that I can go to and relax as a great way to take a vacation.

Some companies let you cash-in vacation time and get money instead of taking a vacation. No. Go on vacation. Take a holiday. Relax and get away from work. It’s really healthy. When you come back, you’re recharged, and it’s easier to have those stressful days because you took time off.

Mala: What’s your style of interviewing a data professional? What do you look for, and what are some examples of questions you ask?

Andy: When I interview people, I try to avoid the rapid-fire quiz format. I think it makes everyone very anxious. I’m trying to judge the person on whether their answers are right or not, and they’re nervous that they’re going to get the right answer. Maybe they have a right answer and I don’t understand that it’s right. I think it makes for a really awkward interview.

What I prefer to do is start off with some open-ended questions about things they’ve been working on or some general questions about experience working with XYZ technology. If we’re using Availability Groups at their job, I might ask that applicant what their experience is with Availability Groups and try to just ask more conversational questions. If I can get them to talk about a project that they worked on, as they mention specific technologies or specific things that they did, I can ask targeted questions to find out how much they know about that or find out how they work.

I think of a lot of things at work as a problem that we’re solving. So as they talk about their experience, I can ask, “Oh, you set up an Availability Group to accomplish that. Did it work the first time? What problems did you have?” And then I focus on digging into those specific things that they worked on, and problems that they had, and how they solved that problem. I can dig into that and really get a good idea of what they know, what they’ve done, and what they’re capable of by asking them about those specific things that they have actually done.

The theoretical quiz type of questions are good, and they can tell you something, but I find it’s much more valuable, and you find out more if the person tells you about something they actually did. You can have that back and forth with a candidate. Sometimes I might share a story about when I did something and a problem that I had that relates to whatever we’re talking about. I can share my problem and then they can tell me how they would fixed it, and we can have a real conversation, like I would with a data professional friend, over the technical things that I run into and give each other ideas. “Did you try this? Oh, why did you do that? Why did you not try it? Did you just not think of it?”

It can be a much more enlightening if they answer, “No, it didn’t work, so I just kept trying and eventually it worked. I have no idea why.” That tells you something about how deep their knowledge is versus someone that says, “Oh, I looked at the logs and I found this error and had to go back, and I missed a step.” It teaches you a lot more from those answers about what they actually did.

Mala: What are your contributions to the community, and why do you recommend people be involved with the community?

Andy: I organize the BostonSQL user group in downtown Boston, and I speak at other user groups. I’ve helped organize SQLSaturday in Boston, and I speak at other SQLSaturdays, and I blog. I think all of those things are important, in addition to answering forum questions and other community contributions. They’re all really important because that’s how I learned.

From when I was starting out all the way through now as a more senior person, if I don’t know how to do something or I have an obscure error message, I search for it on the internet and hope that someone else has had that problem before. Blogging and other online forums contribute to those search results. Even just sharing problems on a forum by asking questions is as important as answering them, because it gives people something to find so that when the next person has that problem, it’s easier for them.

Any way that people can contribute either their problems or their solutions, it helps other people because now when other people have the same problem, they can find someone to talk to about it, they can find an answer, and they can learn.

Mala: So, you were recently awarded the MVP. How has that experience been?

Andy: It has been great. I was awarded last March, so it’s been exactly a year. I just got back from my first MVP Summit and it’s been really great. In the MVP program, you do get access to confidential NDA information from Microsoft, but that’s not the important part—just the recognition that it gives is fantastic. It gives you a little bit of credibility in talking to others, and whether you’re job hunting, or just having a conversation, it’s an incredible honor to have that credential next to my name that I’ve received the MVP Award for what I do with the community.

The MVP Award is awarded for your community contributions. I do the community contributions because I love to help people. I’m not getting paid for my blog posts, or my speaking at SQLSaturday and user groups. I do it because I love the community and getting the MVP Award to recognize that just makes me want to continue to contribute to help the community that I love. Also it helps me fight my imposter syndrome by helping me realize that I’m doing a great job.

There are a lot of people in the MVP program that I look up to, and they’re my peers now. I still sometimes have a hard time thinking all of the people that I’ve learned from being my peers now, being at MVP Summit in the same room with all of these really smart folks, has been a really amazing experience.

Mala: I couldn’t agree more. I think we’ve covered everything I wanted to ask. Would you have anything like a funny story to wind up the conversation? It does not have to be work-related.

Andy: Actually, I have a story from a prior employer that I think is quite funny that I just love to share with other data professionals.

They had a development team that was building a really cool new product that they were going to start offering on a new website. That team was allowed to build whatever they wanted, however they wanted—make their own technology choices without having to get the okay from the other stakeholders that might normally be involved. This meant when they were picking their database, they didn’t have to ask the database team, and they chose to build it in MongoDB to make it easy on themselves.

They spent tons of time building this new product, and then they launched it and other groups at the company had no idea how to query MongoDB. There were teams that needed to be able to pull data and couldn’t because they didn’t know how MongoDB worked. So they ended up taking the Mongo database, writing a process to pull data out of MongoDB and put it in SQL Server so everyone could use it internally.

Even after they made this decision about putting everything in MongoDB, they had to have a whole separate project to put an exact copy of everything from MongoDB into SQL Server so that the data could be useful for the company.

I just thought it was hilarious because if they had asked the database team, we would’ve told them that they’re going to be the only people in the company that know how MongoDB works and we’re not going to be able to support them very easily. Other teams aren’t going to be able to query the data. And it turned out that had they asked us, and had we provided that feedback, we would’ve saved a whole lot of trouble.

I think that that is a great example of how if you’re laser-focused on the problem you are trying to solve, what’s best for you might not be the best solution. When you get back and look at it from the whole company’s perspective, it was not the best solution, and in hindsight, I think everyone, including that development team, realized that. But at the time, that development team had their blinders on, and the cost was having to create the SQL Server database anyway.