You’ve been reading my blog, watching my videos, and maybe even taking some of my training classes. You’ve heard me say things like “my clients” from time to time, and you’re wondering… why do companies actually hire me? What problem are they trying to solve?

Well, when clients meet with me for the first time, I have a series of questions I put up on the screen for them to talk through:

The last one basically asks, “What’s the straw that broke the camel’s back? What made you pull the trigger to schedule a sales call with me today as opposed to waiting another couple of weeks?”

Here’s a rundown of several of my recent clients and the reasons they hired me, in no particular order:

1. “Our Azure bills are growing out of control.” The small company’s customer base had been growing 10-20% per year, but their Azure bills had more than doubled over the last year. They kept hitting 100% CPU, and they’d upsized from 4 cores, to 8 cores, and just before calling me, to 16 cores. Management told the tech team, “We’re going to 16 cores, but only for emergency purposes – you gotta get this database server back under control, and back down to 8 cores, max.”

2. “We’re playing Whack-a-Mole.” The company had migrated to Azure SQL DB Managed Instances, and ever since, every couple of weeks, they faced a performance emergency they’d never seen before. Management was tired of the surprises, and wanted to know if it was an MI problem or something else. (It was something else.)

3. “Our third party ERP app performs terrible.” The entire company’s staff was grinding to a halt because salespeople couldn’t place orders, manufacturing processes were timing out, the shipping dock was slowing down, etc. The ERP vendor was blaming the SQL Server hardware and storage, but the company wasn’t so sure.

4. “We want to become proactive.” The small company & team had been growing for years. They’d started as a 3-person shop, and were now approaching 30 people. Whenever they’d had performance problems in the past, the original founder would kinda wing it, but now they wanted to become more practiced and polished. They wanted to assess the server and the team’s existing skills, then build a learning plan.

5. “We know your tools, but we’re hitting a weird wall.” The large company with a team of 3 full time DBAs had been using the First Responder Kit scripts for years, been through all of my Mastering classes, and were able to handle most of their performance issues. However, they were stumped by an unusual recurring storm of poison waits that would strike at random days/times.

6. “The DBA’s gone, and we need a plan.” It never was really clear whether the DBA left on their own or was laid off by cost-cutting management, but either way, things had started going very wrong with the database server. Management needed a prioritized list of what to fix versus what could get by, and then assignments to various existing team members to divvy up the work.

7. “We need a data warehouse strategy.” The so-called data warehouse server had two dozen databases on it, and was getting hammered by half a dozen different teams who’d built a few dozen applications, including real time OLTP on it. The DBAs knew things were bad, but the teams needed an independent outside opinion, in writing, that management could use to build a new strategy over the coming years to get the house in order.

8. “We disagree about whether our caching is working.” Management brought me in because the developers swore the app was using Redis for caching, but the DBAs swore the app was hitting the database constantly. (It turned out they were both right.)

9. “We’re getting ready to refresh everything.” Every 4-5 years, this company would build new SQL Servers. They wanted advice on a range of topics like whether it was time to use readable replicas, if they should try Fabric Mirroring, and whether they should invest developer time to move to a newer version of Entity Framework.

10. “We want fast training targeted at our skill level.” The company had about 20 developers and 1 full time DBA. They knew they’d been shipping good-enough code for a decade, and they wanted to start leveling up. The DBA didn’t have the time or training material to bring the developers up to speed quickly. The company wanted a quick assessment of the code base, then a couple of days of training for the developers to make things better each time they touched existing code.

I love my job because every week is different. I get called into all kinds of companies to solve all kinds of problems, quickly. If you’d like my help, here’s my 2-day SQL Critical Care® process, and you can schedule a sales call from there. I look forward to working with you!