Working With A SQL Server Consultant Checklist: Who Should Attend Meetings, And When?

This Week Only

I’m going to be running some posts about working with clients, which might be sort of specific to the way I tend to work with people.

I realize it’s not my usual technical content, but every once in a while the brain needs a break from writing about that stuff all the time.

Anyway, the first post up is about who should attend meetings.

Stakeholders

Usually there’s a mix of people who are potentially invested in SQL Server.

Technical staff, like DBAs, developers, and sysadmins
Executives and managers
Customer support to advocate for client issues
Third party developers who build the product

Sometimes there are other people involved, but that covers the most common mix.

I like working with people who work with the server and product directly, because they have the best domain knowledge about why things are the way they are, and where the bodies are buried.

Working In The Dark

I tell everyone I work with that I don’t like working in the dark. That means a couple things:

I don’t want my process to be a black box, I want to build self-sufficiency where I can
I don’t want to wander blindly through a server, I want to focus on the pieces where the pain is

That’s why I kick off every engagement by working via web meeting with anyone who’s interested. We look at everything all together.

If it touches the SQL Server, it’s in scope:

Hardware
Settings
Queries
Indexes
Monitoring data

Other stuff sometimes comes into the mix, like looking at application code and servers, but there’s not a ton I can do to fix those directly. It’s mostly just advice.

I save any scripts we use so folks can run them later, on any other SQL Server. That’s part of building self-sufficiency, but not working in the dark isn’t just for your benefit, it’s for me too.

Anyone can find a slow query, but I like to focus in directly on the queries that are causing the business pain I’m getting paid to solve.

Even with Query Store or a monitoring tool, you’re only guessing at exactly which queries users are complaining about.

Showtime

The thing is, not everyone needs to attend every minute of every meeting.

Executives and managers very rarely have the time and technical knowledge to make attending start to finish. They might care very much about the product, and making sure the engagement is successful, but I usually save their time for delivery of findings.

After the initial analysis, I write detailed findings about the issues that get uncovered during the initial meeting, and I start them off with an executive summary.

You know, for executives.

That gives the really busy, non-technical folks a chance to hear high level pain points, and to ask questions about them without having to sit through all the technical voodoo behind them

After that, I get into all the gory details with the folks who have the best chance of understanding them.

In tomorrow’s post, I’ll talk about how I get access to client SQL Servers in different circumstances.

Thanks for reading!

Going Further

If this is the kind of SQL Server stuff you love learning about, you’ll love my training. I’m offering a 75% discount to my blog readers if you click from here. I’m also available for consulting if you just don’t have time for that and need to solve performance problems quickly.