Stop Hiring Yourself: From Swiss Army Knife Fails to Systems That Scale

Or: How I learned to stop worrying and love the documentation

Let me tell you about the most expensive hiring lesson I've ever learned. Twice.

When you're a bootstrapped founder doing literally everything—sales, support, marketing, coding, probably making coffee too—the natural instinct is to hire someone who can do... well, everything. Someone who's basically you, but cheaper.

Spoiler alert: This is a terrible idea. But I had to fail spectacularly before figuring that out.

Attempt #1: The Swiss Army Knife Employee

Picture this: I'm drowning. I'm handling customer support tickets, jumping on sales calls, doing demos, onboarding new customers, AND trying to write code. Jason's handling the backend operations, but all customer-facing stuff? That's me.

So when it came time to hire, my brilliant plan was to find one magical person who could handle ALL of that. Email tickets? Check. Live chat? Check. Phone calls? Check. Sales demos? Check. Customer onboarding? Check. Oh, and since they have a CS background, maybe they can help with technical stuff too? Double check!

I spent months training this person. MONTHS. At the time, I didn't realize what a red flag that was. If it takes months to train someone for a single role, you're probably not hiring for a single role.

They managed to handle it... sort of. They were sufficient but not great at anything. Jack of all trades, master of none. Eventually, we had to let them go because "sufficient" doesn't cut it when you're trying to build something great.

Attempt #2: The Almost-Learning Experience

You'd think I learned my lesson, right? Wrong.

For hire number two, I almost got it right. I removed the technical requirements but still expected them to handle both customer support AND sales. This was around our V2 launch, which was... let's just say "bug-rich."

The plan was logical: most tickets will be about bugs, so I'll handle those personally and let the new hire handle everything else. What we didn't anticipate was the sheer volume of issues. I quickly got overwhelmed, so I had to throw this poor person into the deep end.

After a month of training, they still weren't keeping up with either sales or support. Smart person, driven, but juggling two completely different skill sets? Not happening.

That's when the lightbulb finally went off.

The Breakthrough: One Person, One Job

I asked myself a simple question: "What's the ONE thing I need to solve right now?"

Customer support. That's it.

So I made a radical decision. I told our hire: "Forget everything else. You're focusing ONLY on tickets. Learning the software. Helping customers use it. That's your world."

Any sales questions? "Sorry, we're not doing demos right now."

We literally closed off all demos for the next six months. Scary? Hell yes. But here's the thing about being bootstrapped—we're profitable, we don't have VCs breathing down our necks, and we can make decisions like this. If we don't get new customers for six months, it's not ideal, but it's not the end of the world either.

Suddenly, magic happened. Our support person became... actually good at support. They were on top of tickets, customers were happy, and I could focus on fixing our ops pipeline.

Building Systems, Not Dependencies

But even focusing on one job wasn't enough. I realized I needed to build systems, not just hire bodies.

We implemented a tagging system for every ticket:

• Type: Bug report, assistance request, feature request
• Area: Which part of the software (sales orders, QuickBooks integration, etc.)
• Status: Triaged, escalated, waiting on customer, waiting on engineering, closed

We made crystal clear distinctions. A bug means something that used to work doesn't work, or something works incorrectly. A feature request means "I wish it worked differently"—not because it's wrong, but because that's how you prefer it.

Bug reports get escalated to engineering. Feature requests get documented for future consideration. Clear escalation paths mean the support person knows exactly when to involve me or the dev team.

But here's the real game-changer: documentation. Aggressive, comprehensive documentation.

RTFM: The Ultimate Scaling Strategy

Every process, every decision tree, every common scenario—documented. Customer-facing docs AND internal docs. Now when I hire someone new, their first job is simple: Read the fucking Documentation.

Light software onboarding? Check. Read internal docs to understand expectations? Check. Follow documented processes? Check.

Instead of spending months personally training every new hire, they can become productive by following systems. If they have questions, they can ask me or other team members, but the heavy lifting is done by documentation.

The Real Lesson: Specialists Win

Here's what I wish someone had told me from the beginning: Stop trying to hire yourself.

If someone was capable of doing everything I could do, they'd probably be running their own business, not working for mine. There are two kinds of people: those who run businesses and those who don't. Both are valuable, but you need to be clear about what each can actually deliver.

Specialists beat generalists every single time. Someone who's excellent at customer support will outperform someone who's mediocre at support, sales, and onboarding. We'll eventually split onboarding into its own role too, but for now, support + light onboarding works because they're related skills.

Support and sales, though? Completely different skill sets. Don't make the same mistake I did—twice.

The Bottom Line

Building a business isn't about finding people who can replace you. It's about building systems that make normal people extraordinary at specific things.

Document everything. Focus roles. Build processes that survive personnel changes. Because people come and go—their priorities change, their life situations change. But good systems? Those scale.

Now if you'll excuse me, I need to go update our documentation. Because someone just asked a question that should definitely be covered in our "How to Handle Weird Edge Cases" doc.

Currently hiring: One customer support specialist who's excited about reading documentation and becoming the best support person in the print shop software industry. Superman cape not required.