Your First Support Hire Should Be a Generalist, Not a Specialist

The first time I helped a startup hire for support, the founder handed me a job description copied off a SaaS template. It listed Zendesk macros, average handle time, CSAT targets, and "experience working tickets in a high-volume queue." All the language of a support function that already exists.

The problem was that nothing existed yet. No documentation. No triage process. No idea which issues were bugs and which were confused users. We weren't hiring someone to run a machine. We were hiring someone to build one.

That distinction is everything, and most founders get it wrong. They picture support as ticket-closing, so they hire a ticket-closer. Then six months later they're confused about why their support person can answer the same question forty times but has never once written it down, never flagged the recurring bug to engineering, and can't function the moment a question falls outside the script.

Your first support hire is not a support agent. They are the person who turns chaos into a system. Hire for that.

What the first support hire actually owns

At a five-to-thirty person company, "support" is a deceptively broad job. The person who answers customer questions sits at the only point in the company where you can see, in real time, what's actually broken, confusing, or missing in your product. That is a strategic position. Treating it as a queue to be cleared wastes it completely.

Your first hire should own three things, in this order:

Documentation. Every answered question is a documentation gap until proven otherwise. The job isn't to answer the question — it's to answer it once, write it down, and never have a human answer it again. A good first support hire reduces their own future workload on purpose.

Triage. Most "support tickets" are not support tickets. They are bug reports, feature requests, billing problems, or confused users who needed onboarding. Someone has to sort the signal, reproduce the real bugs, and hand engineering a clean, reproducible report instead of "customer says it's broken." This is the single most valuable thing a support person does in an early-stage company, and it's the thing career L1 agents are usually worst at.

Customer communication. Tone, clarity, honesty when something's genuinely broken. Early on, every support interaction is also a retention conversation. The person doing it is shaping how your customers feel about you when something has gone wrong — which is exactly when impressions stick.

Notice what's not at the top of that list: closing tickets. Tickets get closed as a side effect of doing the three things above well. If you measure your first hire on close rate or handle time, you will optimise them straight into the wrong behaviour.

Why a generalist beats a career specialist here

A career L1 specialist is genuinely good at something: working an established queue, fast, within defined processes, hitting metrics someone else set. That's a real skill and you'll want it eventually — at the stage where you have volume, tiers, and SLAs to defend.

You are not at that stage. At your stage the process doesn't exist, so "good at following process" buys you nothing. What you need is someone who can:

• Sit with a vague, half-described problem and figure out what's actually going on.
• Write a clear sentence — repeatedly, under time pressure, for an audience that's annoyed.
• Talk to an engineer in language the engineer respects, without needing a manager to translate.
• Decide, on their own, whether something is a doc gap, a bug, or a one-off.

Those are generalist traits. The specialist's strength — speed within a known system — is the one thing that doesn't transfer to a company that has no system yet.

I've watched both hires play out. The specialist clears the inbox and the founder feels relief for a month. Then they realise the same ten questions keep coming back, nothing's been written down, engineering is getting garbage bug reports, and the moment a weird edge case arrives the whole thing stalls because it wasn't in the script. The generalist clears the inbox slower at first — and then volume starts dropping, because they're killing root causes instead of symptoms.

Slower at first, compounding afterwards. That's the trade you want this early.

A job description you can actually use

Here's roughly what I'd post. Adjust the product specifics, but keep the shape.

Title: Support & Customer Operations (Founding) — not "Support Agent," not "L1 Support."

What you'll do:

• Be the first human customers talk to when they're stuck, and make those interactions feel good even when the news is bad.
• Turn every recurring question into documentation so it never has to be answered live again.
• Triage incoming issues: reproduce real bugs, write clean reports for engineering, and route the rest correctly.
• Build our support processes from close to nothing — you'll be defining how this works, not inheriting it.
• Tell us what's actually wrong with the product. You'll see patterns nobody else can.

You'll do well here if you:

• Write clearly and quickly, and actually enjoy it.
• Are comfortable when the answer isn't written down anywhere yet.
• Are technical enough to read an API error, follow a reproduction, and hold your own with engineers (you don't need to code).
• Are genuinely curious about why things break, not just how to make the customer go away.

This is not the role if you want a defined queue, a script, and clear metrics from day one. We don't have those yet. You'll help build them.

That last line does more filtering than the rest of the post combined. It scares off the people who'd be miserable here and attracts the ones who'll thrive.

Interview signals worth chasing

I care about four things, and I test each one directly rather than asking about it.

Writing ability. Give them a real, slightly messy customer message and ask them to reply, then to write the help-doc version of that answer. This is the single most predictive exercise I run. You'll see clarity, tone, structure, and whether they instinctively reach for documentation — all in fifteen minutes. Don't skip it. Talking about writing tells you nothing; watching them write tells you everything.

Curiosity. Ask them about a bug or problem they once chased down. The good ones light up. They remember the details, the dead ends, the moment it clicked. They cared about the why. The ones who just want the ticket closed give you a flat, generic answer and move on.

Comfort with ambiguity. Hand them a deliberately under-specified scenario: "A customer says the export is broken. You can't reproduce it. What do you do?" The specialist often freezes or reaches for an escalation path that doesn't exist. The generalist starts asking questions — what browser, what data, when did it start, can I get a screen recording — and builds a plan out loud. That improvisation is the job.

Technical-enough. Not "can you code." Can they read a stack trace and tell roughly where the problem is? Can they follow reproduction steps without hand-holding? Can they tell a real bug from user error? Show them a redacted error log and ask what they'd ask the customer next. You're looking for confidence around technical material, not expertise in it.

Red flags

A few things make me nervous, regardless of how polished someone seems:

• Metric talk with no curiosity behind it. If every answer is about CSAT and handle time and nothing about the customers or the product, they've been trained to clear queues, not solve problems.
• Allergic to ambiguity. "What's the process for that?" asked about everything. Fine at a big company. Fatal as your first hire.
• Can't write. If the take-home reply is vague, sloppy, or weirdly formal, that won't improve under pressure. Writing is the core skill, not a nice-to-have.
• Treats engineers as a wall to throw tickets over. If they describe engineering as "them," adversarially, they'll generate friction you'll spend your own time refereeing.
• No interest in why things break. Pure symptom-clearers keep you on the treadmill forever.

Onboarding: the first 30 days

How you onboard this person decides whether they become a system-builder or just another inbox-clearer. Be deliberate.

Week 1 — Absorb. They sit in the inbox and answer nothing alone. They watch how things are handled now, shadow real conversations, and start a running list of every question that comes up. No documentation exists yet, so this list is the seed of it. They should also meet engineering this week, in person or on a call — not over a ticket. The relationship matters more than any tool.

Week 2 — Start answering, start writing. They take real conversations, with someone reviewing their replies. Every time they answer something for the first time, they draft a help-doc entry. By the end of the week you want the first five or ten docs to exist, however rough. The habit is the point.

Week 3 — Own triage. Now they start sorting. Bug versus feature request versus user confusion versus billing. They file their first clean engineering bug report and you both review it together: was it reproducible, did it have the right detail, could an engineer act on it without a follow-up. This is the skill that pays off most, so invest the review time here.

Week 4 — Run it, then tell you what's broken. They handle the inbox largely solo, escalating real edge cases. And they bring you their first pattern report: the top recurring issues, which are doc gaps, which are real product problems, what they'd fix first. If they can do that at thirty days, you hired the right person.

By the end of the month you should have documentation that didn't exist, bug reports engineering doesn't dread, and a person who can already tell you something true about your product that you didn't know. That's the return on hiring a generalist. A specialist gives you a cleared inbox and nothing underneath it.

The bottom line

Your first support hire is a foundational hire, not an operational one. They're building the support function, not staffing it. So hire for the things that build: clear writing, real curiosity, comfort in the fog, and enough technical confidence to be taken seriously by your engineers.

The specialist comes later — once you have volume, tiers, and a system worth defending. Hire that person too early and you get a fast queue-clearer sitting on top of a mess that never gets organised.

Get the order right. Generalist first. The person who can write the docs, talk to the engineers, and tell you what's actually wrong is worth ten people who can only close the ticket in front of them.