business

It’s time for my annual update on the wild ride. A brief recap of what’s happened so far:

• April 2011 – started the company.
• April 2012 – year one finished, but I didn’t blog about it right away. I wanted to get it into the rear view mirror for perspective before blogging.
• April 2013 – year two finished, so I blogged about year one.
• April 2014 – year three finished, so I blogged about year two.
• April 2015 – year four finished, so I blogged about year three.
• April 2016 – year five finished, so I’m blogging about year four – April 2014 to April 2015.

In April 2014, we had two full time employees, a part time admin assistant, a successful consulting business, and a growing training business. It felt like things were going like gangbusters at work, but…

My personal blog went very anti-PASS.

I was so pissed off about how PASS handled one thing after another, and how they’d ignored private feedback. I decided to go public, and the results weren’t pretty:

• Fact-Checking the 24 Hours of PASS
• 3 Reasons the #SQLPASS BA-Con Will Fail
• Here’s Why My #SQLPASS Blog Posts are So Angry
• I Need Your Help Improving #SQLPASS
• The Bigger #PASSVOTES Problem: Your Password Was Shared

As a community journalist, I was proud of those posts.

I cared (and still care) a lot about repeated privacy violations, clearly misleading/wrong vendor spam masquerading as education, wasted money, and a disregard for a quality product.

But it’s not all that different from the ongoing Uber controversies – many consumers (myself included) are willing to overlook that kind of thing when they like the business’s product, and the PASS product is the best SQL Server conference product in the US right now. (I’d argue that the SQLbits UK product is better and cheaper, but that’s for another day.)

Looking back, I can really clearly see that I burned a lot of bridges that year. I caught a lot of flak for saying bad things in public – as if I hadn’t been complaining privately to PASS Board members for years. I don’t think my complaints made anything better, and I was a fool for standing on the street corner, yelling for faster changes. PASS is changing (and improving) at the rate that big, bureaucratic institutions change, and it is what it is. Today, in the rear-view mirror, it’s easy to see that the technique didn’t help, and instead hurt the community. Today, I understand that I don’t know how to affect the changes I want to see in PASS, but I also recognize that it’s my own shortcoming, not that of the organization.

Thankfully, the company kept right on trucking just fine despite my distractions. PASS had never been a revenue source for the company, but I wager that we lost a few potential employees due to my rants. I bet there’s good people out there who would have been interested in working for us before, but weren’t after the rants. That’s a bummer, and that’s entirely my fault. And probably unrelated (but you never know)…

Employee #1 left for greener pastures.

As Doug Lane (employee #2) was getting up to speed, we lost Jes Schultz-Borland, our very first employee. Going forward, as I write more about the company’s successes and failures, I won’t talk about individual employees leaving (PLEASE GOD DO NOT LEAVE, ANGIE, DOUG, ERIK, ERIKA, JESSICA, RICHIE, AND TARA) because it’s just not appropriate. I do think it’s appropriate to talk in generalities about employee retention, though.

Here’s some of what’s hard about hiring employee #1:

• Accounting – holy paperwork, Batman – taxes, payroll, retirement planning, insurance, states
• Management – planning a successful path for their career, training, and evaluation
• Communication – letting them know where we’re going, and how they can help

It’s tempting for me to say that as long as you’re hiring one person, you might as well hire 2-3 to spread your risk around, but that first employee is going to have a really chaotic ride. The #1 trait you should look for in employee #1 is a sunny, upbeat outlook despite strange obstacles. We never would have known to look for that, but Jes’s disposition made all the difference as we conquered one startup obstacle after another.

Jes was with us for three very tumultuous startup years. She had to put up with a complete lack of HR functionality as we learned how to set up insurance, payroll, taxes, procedures, expenses, you name it. Kendra worked her tail off to set the company up, putting in infrastructure as fast as we could. It’s hard to overstate how hard Jes and Kendra both had it for the first couple of years. It took two very special people to pull that off, and they did it with impeccable awesomeness. I don’t think any two people could have done the startup process any better than those two did.

As a result, I totally understood when she switched gears and went to work for Concurrency, a larger, more traditional consulting company. There’s a limit as to how much transparency I can have here on the blog, especially when other peoples’ careers are involved, so I would totally understand if you read the rest of this as, “He’s just being polite to be good to Jes.” No, seriously – believe me when I say I really do wish Jes the best success in the world. She’s awesome. We want our employees to learn, grow, and succeed, full stop, and I was actually excited to see what Jes did next. She’s going to be in the SQL Server community for the rest of her life, and she’s going to be successful. I’m proud that we’re on her resume.

When you only have two employees, losing one of them is hard.

I’m not talking emotionally – which of course is hard too – but it’s hard on your client calendar. We’re lucky enough to focus on short-term engagements, so we didn’t have to worry about replacing Jes on a large project, but we had enough client demand that we really needed to add more people, stat.

Our business model made it challenging because we were focused on a single, repeatable process – but we didn’t have any training material built up to teach people how to do that process. We were teaching it like some kind of ancient tribe passing down our traditions verbally.

Since we were under the gun, time-wise, we made the decision to hire someone very senior with a lot of performance tuning experience. We put out a call for resumes, and we grabbed Erik Darling in an entirely work-appropriate way. (Both Doug and Erik had to deal with our very haphazard way of training new people because our product methods were iterating as fast as our hiring.)

When we originally started the company, we aimed to hire one person per year, but year four was pretty wild because…

We also finally hired a salesperson.

I really should have recognized earlier how much of my time sales was taking. I wasn’t doing outreach or cold calls – I was simply answering the contact emails, scheduling introduction calls, signing contracts, and scheduling consultants. It doesn’t sound like hard work, but it was sucking up more and more of my own time. I should have been using that time to write training material, do consulting, and blog, but I enjoyed the sales process too much.

Jeremiah and Kendra saw this problem long, long before I did, and they suggested we should hire a salesperson. The single biggest mistake I made during the startup process was not listening to that suggestion. The simple fact that they even made the suggestion should have been my clue to let go. They were amazing cofounders, and they had faith in me when I said I could keep running with the sales duties.

In summer 2015, I had a Eureka moment when I realized that I was the bottleneck holding back the business from growing faster. We started looking for a salesperson, and it was the toughest position we’d ever hired for. We know a ton of data professionals, but we don’t really have a solid network of salespeople. I happened to ask a friend of mine what he’d look for in a salesperson, and one thing led to another, and I met Jessica Connors for dinner. By the end of the dinner, I was thinking, “PLEASE GOD, LET HER BE INTERESTED IN THIS JOB,” and whaddya know, she joined the company.

Seriously, when I look back, this is the one thing we should have done long ago (only assuming that Jessica was the salesperson we’d have hired.) Hire people who are really good at the stuff you’re only passable at.

This was important because something else in year four was really kicking my ass.

Our training class inventory kept growing.

In summer 2014, Jeremiah, Kendra, and I took a deep breath and increased our commitment again: we’d up our 2015 training lineup from a couple of shorter 2-3 day classes all the way to three week-long classes. Even tougher, we ran pairs of them back-to-back in the same cities in order to cut our expenses.

It’s funny – I clearly remember when I left SQLskills, I told Paul and Kim that I had absolutely no interest in running week-long classes – and that was true then. Teaching is pretty hard work, and a week-long class means being on the road away from home longer and longer stretches. But the siren song of profit was too good to resist, and we really liked training, so we took the leap. Plus, our customers had been telling us, “As long as I’m away from the office for a 2-3 day class, I might as well be gone the entire week.” So we structured week-long classes around three imaginary people: Sandra the Senior DBA, Paula the Performance Tuner, and Danny the Developer. (I’m reading these profiles and giggling – they were fun to write.)

Selling these kinds of classes is a huge financial gamble for a small startup. You have to pay huge deposits to the hotels where you host the training (we’re talking tens of thousands of dollars), and hope like hell that people actually show up. You have to guess what people want to learn, how much they’ll pay, and what cities they want to visit. We got lucky that year, and things worked out okay, but the stress was definitely there.

We booked the hotels, then announced the lineup in July 2014, and ran our Black Friday sale in November. We breathed a huge sigh of relief when all the classes finally looked like they’d be profitable.

Along the way, I was working way, way the hell too hard (along with Jeremiah and Kendra). I had to work my ass off in order to get the new training material ready, and then after each class, I had to keep working to iterate over the material and make it even better. It paid off, don’t get me wrong – we made money doing training, and we built up a valuable inventory of training materials, but I don’t think we paid enough attention to work/life balance that year.

We tried a lot of fun experiments.

No, really, a lot, and I’ll only mention a few:

• A spiffy explanation video on the home page of BrentOzar.com
• A week-long partnership training experiment with Dell (it didn’t pan out in year four, but it later ended up being Dell DBA Days)
• Online training classes – like a hybrid of recorded + live video training classes so people could do homework, and then ask questions live, plus an Extended Events training class
• Setting up conference profit & loss statements – so we could see how much we were spending on each conference
• More ambitious video/training sales pages on BrentOzar.com – put some decent money into PHP development here
• User group video night – where user groups could get one-day access to our video library to show recorded presentations
• Moved the company to Nevada in preparation for me moving to California (since we didn’t have a reason to be incorporated in Illinois anymore)
• Started planning our 2015 FreeCon, a professional development event at the PASS Summit
• Changed the weekly presentation-based webcast into a totally Q&A Office Hours approach

Looking back, I’m really proud of how hard we worked to figure out the maximum possible that we could give back to the community without going broke as a company. I’m super-competitive in an odd way: I wanted to help every SQL Server professional more than anybody else in the industry, for free. Tools, scripts, blog posts, videos, live webcasts, in-person events, you name it – I want to make a real, meaningful, permanent difference in peoples’ jobs and lives.

One thing we didn’t experiment on was the product: we had really focused on the SQL Critical Care® process, and at this point, it was the only product we offered. (We still do additional services for companies who find disturbing things inside their servers during the SQL Critical Care®, though.)

Was year four successful?

Oh yeah. Looking back at my original personal goals for the company:

• 0-1 year – consult 16-32 hours per week – which might sound like I was being lazy, but the reality of a small business is that you have a lot of unpaid work to get the business moving down the runway.
• 1-3 years – consult 16-24 hours per week – a dropped ceiling from 32 to 24 due to the admin overhead of a growing business, and wanting to do less paid work and more R&D/presenting/training-writing.
• 4-6 years – hire people to offload the non-technical work – maybe a business manager, salesperson, and/or accountant so we can stay focused on the technical stuff we love.

Technically, we were on track, but I didn’t realize how much work sales would be, and I should have had that hire-non-technical-people goal up in year three. Not bad though. And now we’ve checked off the stuff through year 6. What’s next?

It’s time to recalculate goals for years 6-10.

Jeremiah, Kendra, and I originally wrote up goals further out, but since the company’s purchased their shares, I get to make my own vision.

2016 is basically a stabilization year – it’s my first year managing the company on my own, teaching the training classes by myself, and making sure we’re financially stable enough to pay off Jeremiah & Kendra over time. As time goes on, though:

Years 6-7 (April 2016-2018):

• Grow to around 10 consultants – which I think we can do without too much infrastructure investment or the company losing its fun vibe.
• Take the community’s available tools to the next level again – I think we’ve made a huge difference with our sp_Blitz® tools, but we can do better. I want to give the community something even easier to use, yet more scalable and more actionable.

Years 8-9 (April 2018-2020):

• Be a vital, valuable part of every SQL Server database administrator’s daily routine.

Yeah, it’s grandiose, but you don’t get big stuff by dreaming small, and we’re building a team that can do it. This is gonna be so much fun sharing the next steps with you.