Brent Ozar Unlimited

Every year, I stop to look back at what happened a couple of years ago. This post covers April 2015-April 2016.

My cofounders and I were all ready to try something new.

Jeremiah, Kendra, and I had the same vision for where the business was going next (on-premises software), what the next steps were, and the speed at which we’d make the journey. We didn’t want to kill consulting and training, mind you, just wanted to build up a third profitable leg for the business.

At the company retreat in Oregon, mid-2015

But in year five, both Jeremiah and I had the same thought individually: “The company should continue on as it is, but just without me.”

For me, it was the software work that was just over the horizon. I’ve worked for small and big software companies before, and I know the infrastructure is way, way bigger than it looks from the outside. I didn’t want anything to do with building a support team, managing groups of developers, QA processes, etc. I didn’t have any skills to bring to those tasks. I knew it’d be a Herculean amount of work over the next few years, just as the first 4 years were huge to get the consulting and training off the ground. I knew the company would succeed with Jeremiah and Kendra at the helm, and that I wouldn’t add anything to that success. (I wouldn’t hold it back, I just wouldn’t be able to contribute to those tasks.)

I took some time off by myself to think – I’m a big fan of doing structured solo retreats every year – and I sketched out a few ideas. I figured I’d walk away, then start a remote DBA services company or an e-discovery consulting company, because neither of those would compete with Brent Ozar Unlimited. (Neither of options had a particularly easy route forward, but I didn’t want to do anything competitive – I wanted Jeremiah and Kendra to succeed, period.) I talked it over with Erika, and we agreed that it was the right time.

I told them, “I’m walking away, but I fully believe in where you guys (Jeremiah & Kendra) are going to go with the company, and I’m totally okay with you using my name.” I was even willing to change my name to something else entirely just to make it easier to keep the existing company going. (I’d be Brent Valencia, if you’re wondering – I’d take my wife’s last name.)

But that company name made things awkward.

Jeremiah and Kendra didn’t want to keep the company without me involved because they would want to rebrand the company as something else. I don’t blame them – all throughout the company’s history, tons of readers/customers kept saying stuff like, “Great post, Brent” even when the blog post was written by somebody else. We had clients refer to our consultants as “Brent” no matter who was on the call. Jeremiah, Kendra, and I were always equal partners, and I know the constant “Brent” references had to be frustrating. If I was gone, they wanted the name to be gone too.

Rebranding – changing a company’s name – sounds easy, but it’s HORRIBLE work. We went through the rebranding process when Tim left – the change from Brent Ozar PLF, LLC to Brent Ozar Unlimited was a pain in the ass. I totally understand why they didn’t want the company if it came with that kind of baggage.

Company lineup, summer 2015

This is probably my biggest regret in founding the company – I wish when we started it, we’d have added another domain and started migrating our company stuff over to it. Something independent, like Data Bass Hatchery or whatever. It would have given us more flexibility around ownership. (When you start a blog, I still believe it should be under your own name, though.)

So in fall 2015, the company bought out Jeremiah and Kendra.

We brainstormed a bunch of options and came up with this:

• Jeremiah and Kendra would each get a cash payout, plus money over the next several years
• They would leave their intellectual property for training inside the company (which meant we could sell their classes, thereby helping pay them out)
• They could do anything they wanted, even take clients with ’em, but not hire the company’s employees for several months (because if the company lost J&K and all the employees, it’d be too hard to bring in revenue and pay down the loan)
• If the company defaulted on payments, Jeremiah and Kendra would get their ownership back

We came up with numbers that worked for everybody, worked through a bunch of legal paperwork, and then told the team.

I always say “the company bought out Jeremiah and Kendra” because I wanna make it really clear that I didn’t whip out my wallet and start slappin’ down hundos. I wouldn’t have been able to finance that big of a move. Instead, the company bought back their shares, which indirectly makes my shares worth more, but the company was the one taking on the debt and the risk. This move wouldn’t have been possible if it wasn’t for the incredible work that Jeremiah and Kendra put into the company, building up its earning potential over the years.

Since then, it’s been really cool to see Jeremiah go back to college and watch Kendra build up SQLworkbooks.com. I think the biggest lesson we learned over the years of working together was that each of us – and each of you, dear reader – can define what personal success looks like, and build a path to get there. I love watching them do their thing.

When the company ownership shifted, I had to pause to think about what success would look like to me, too. We were just hitting the $2mm/year revenue mark with a successful consulting and training business. I decided that over the next 2-3 years, if I owned the company, success meant growing the company to 10-15 consultants. (I didn’t choose to hire trainers.)

The first six months were really hard on me.

There’s probably never a great time to do stuff like this, but my first ~6 months of ownership (winter 2015-spring 2016) were rough. I knew it would all be fine if I could just get to May 2016, but until then, I was a little unhealthily stressed out because:

I had to do all partner duties. Jeremiah and Kendra hadn’t exactly been sitting idle playing Solitaire – they were managing the staff, building tools, and designing the new software. I found myself working seven days a week trying to tread water. Thank God we had really smart, self-starter people who could manage themselves, because I didn’t do jack for management.

I had to rehearse and teach week-long classes by myself. We’d already signed hotel contracts for our 2016 training classes, and we’d just announced our week-long class lineups. However, I didn’t have co-presenters anymore, and I was up by myself starting January. While Jeremiah & Kendra left their training material in the company in order to increase its value, I wasn’t necessarily familiar with all of their modules. Teaching a week-long class solo is exhausting, let alone two of them, as I wrote last week.

I was on the road most of the time. I’d already booked my own 2016 travel calendar, and between taking over classes, plus my existing training/client commitments, and new clients that would only take in-person work, I was on the road for 14 out of 16 weeks. That sucked. I wish I could have canceled some of that, but the company needed the cash flow early on because…

We had to backfill consulting capacity, fast. We’d just hired Angie, but that wouldn’t be enough to replace both Jeremiah and Kendra. I hired Tara before the company changes were even done because I had to get consultants up to speed really quickly. Doug & Erik had to do double duty – consulting, plus getting their new coworkers trained.

We had to go underground

We were temporarily unprofitable. While Angie & Tara got trained on how we do the SQL Critical Care® process, we were way heavy on payroll – but way light on revenue. The first quarter of 2016 scared me more than any quarter we’d had – the consulting side of the business lost over $100k in those 3 months alone. We were never in a position where we wouldn’t make employee payroll, but I did a lot of training & consulting that I never got paid for, even to this day.

There were also some big expenses I couldn’t avoid:

• We needed a company retreat to get the new team together to build camaraderie
• My first solo class, a January 2016 class in Newark, bombed with only 5 tickets sold (losing a bunch of money, but we don’t cancel classes – lesson learned, nobody wants to go to Newark in January)
• Doug wasn’t billable because he started recording Jeremiah & Kendra’s advanced querying & indexing training material, because we needed to start bringing in more passive income
• I had the opportunity to hire Richie – but as a developer, he wasn’t directly bringing in revenue

“Wait – why hire Richie if you didn’t want to build software?”

Visiting Cliff Lede in Napa

If Jeremiah, Kendra, and I were all building Brent Ozar Unlimited, the right way to go forward was to add software to the company’s offerings.

If I left, and Jeremiah and Kendra ran the company, I thought software still made sense for them. I am absolutely positive that they would have succeeded wildly.

But if Jeremiah and Kendra left, and I was the only remaining partner, then I would have failed. It’s not that I don’t have the experience or the drive – it’s just that being a solo founder, running a consulting and training company, and trying to build an app – that’s stretching one person too thin. In the first year, there just simply wouldn’t be enough time for me to devote to designing a new app and building the staff infrastructure necessary to bring it to life.

However, I did see an opportunity to build something different than the SQL Server industry had seen before: free online services. (The first result which has since gone live: PasteThePlan.com.) I wasn’t really in a rush to build them, but when Richie became available, I wanted to snap him up fast because the personality fit would be so good for the team, plus he had the right architecture and project management skills that could hit the ground running with minimal oversight from me. (I really do suck as a manager – I just point at a dot on the horizon and yell, “Run that way! Let me know what you find.”)

Plus, I could have Richie build a tool to rapidly improve the SQL Critical Care® process, making it easier for us to onboard new staff that could produce a better product faster, and for less money. I gave him a general spec and two months to build it, and he totally delivered. His CriticalCareCollector app dramatically changed the way we do consulting.

By the end of year five, I thought could breathe again.

Breathing easier

I remember laughing in April when a commenter called me arrogant – at that point, I was about the farthest thing from arrogant. I had spent months really stressed out, paranoid that I would have to ask my team to make compromises, work more hours, take less time off, work crappy engagements, cut bonuses, or stop investing in our future. I was willing to do whatever it took to make sure that didn’t happen, including making a lot of personal financial compromises.

Thankfully, by the end of April 2016, it looked like we were firing on all cylinders. The consulting business was kicking ass: we had a trained, profitable team, using new consulting and sales tools do to their jobs better/faster/cheaper. The training business was on track as well: my 2016 classes were all written and working fine, we had a successful (profitable!) class in Newark, we had new video classes coming into the sales pipeline, and the rest of the year’s classes were in a profitable state.

Sadly, I was wrong about of half of that, but that’ll have to wait until next year’s retrospective.

If you wanna read the past updates:

• Year 1 recap – April 2011-2012
• Year 2 recap – April 2012-2013
• Year 3 recap – April 2013-2014
• Year 4 recap – April 2014-2015

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

Typical partner meeting in year four, Vegas

• 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.)

March 2014 – suddenly, my new favorite restaurant

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.

The holiday card lineup

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.)

The back of the class in Chicago

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.