First Sales Hire: Profile & Interview Process for a Technical Product, Ops-Manager Buyer, Narrow ICP

---

The Core Tension to Resolve First

With one hire and a narrow ICP, the failure mode is not hiring a bad salesperson — it is hiring the wrong type of salesperson. There are three archetypes you will encounter in the market, and only one fits your situation:

Archetype	What They're Good At	Why They Fail Here
Hunter / high-volume SDR	Outbound volume, fast pipeline	Ops managers don't respond to spray-and-pray; narrow ICP means volume doesn't save you
Enterprise relationship seller	Multi-year stakeholder management	Your deal cycle and budget probably can't justify 12-month relationship nurturing before a close
Technical domain seller ✓	Understanding the product deeply, speaking the buyer's language, running consultative discovery	Matches the buyer, the ICP, and the complexity of the product

You are hiring the third archetype. Everything below is calibrated to that.

---

Profile: What Actually Predicts Success

Non-negotiables

• Sold a technical product to an operational or industrial buyer. Not necessarily your exact domain — but they must have been the person who understood the product well enough to demo it, answer objections, and get a procurement-resistant ops manager to a yes. "Technical" here means they have done product-led discovery, not just read a one-pager.
• Comfortable with a small named-account list. A narrow ICP means this person will work a list of maybe 50–200 accounts, not thousands of leads. They need to be a farmer-hunter hybrid: able to build a list, prioritise it, and work each account methodically. Someone who has only operated with a large marketing-qualified lead pipeline will flounder.
• Can run the full cycle alone. With one hire and no SDR or sales engineer behind them, this person needs to prospect, qualify, demo, handle technical questions, and close. Candidates who have only held a "closing" role with a full support team around them are a risk.
• Has sold where the buyer is not the economic buyer. Operations managers typically influence or recommend but do not always sign. Your hire must understand how to map a buying group and get to the person who can approve spend, without losing the ops manager's trust in the process.

Strong positive signals (worth paying for)

• Prior role at a company with a similarly narrow ICP and no inbound engine — they built pipeline from scratch.
• Evidence of deal velocity control: can they describe why a deal stalled and what they did about it?
• Existing relationships or network inside your target vertical (not just general "network").

Red flags to screen out early

• Career built entirely on inbound or marketing-sourced leads.
• No experience explaining a technical concept to a non-technical economic buyer.
• Role descriptions that show quota attainment but no ability to articulate how — pattern suggests luck or a favorable market, not repeatable process.
• Expectation of a large SDR or pre-sales team behind them.

Compensation structure signal

Ops-manager-focused technical sales rarely closes on first contact. Candidates who demand 80%+ variable pay are signaling they expect fast, high-volume deal flow. For your context, a 60/40 or 55/45 base/variable split is more realistic and will attract people who match the motion.

---

Interview Process: Four Stages That Predict the Right Outcomes

Each stage targets a specific predictive dimension. Eliminate stages that don't serve this specific hire — do not run a generic process.

Stage 1 — Structured Screen (30 min, phone or video)

Purpose: Eliminate archetype mismatch before either party invests.

Ask exactly these four questions, in this order:

1. "Walk me through the most technical product you have sold. What made it technical, and how did you get up to speed on it?" — You are listening for their comfort with depth, not just their confidence. A strong answer names specific technical concepts they had to learn and how.
2. "Describe your typical account list size. How many accounts were you working at any given time?" — You want someone who has operated with a small, named-account model.
3. "Tell me about a deal where the ops-level contact wanted to buy but couldn't get budget approved. What did you do?" — Tests multi-stakeholder navigation in an operational context.
4. "What would your first 90 days look like here, before you have a single qualified lead?" — Tests self-sufficiency and pipeline-building instinct.

Screen out if: answers are vague about the technical dimension, they describe a high-inbound environment as their only experience, or they cannot describe a deal that required navigating above the ops manager.

---

Stage 2 — Domain Discovery Exercise (async, 48 hours)

Purpose: Test whether they can do the core job — research a prospect and run a credible discovery conversation.

Give them:

• A one-page description of your product (what it does, not the pitch deck).
• A fictional but realistic target company profile: industry, size, described operations context.
• The role: "You have a 20-minute discovery call with the operations manager at this company. Prepare your discovery questions and be ready to run that call with us."

You are evaluating:

• Do their questions diagnose the operational problem, or are they product-feature questions dressed up as discovery?
• Can they frame the problem in language an ops manager would recognize?
• Do they show awareness that the ops manager is not always the budget holder?

This exercise is low-cost to send, screens out candidates who won't do the work, and generates the best signal of the whole process.

---

Stage 3 — Live Roleplay + Debrief (60 min, with you or a founder)

Purpose: See them in motion on your actual buyer type.

Run the discovery call they prepared. Then debrief it:

• "What did you learn about the prospect's situation?"
• "What would you do next, and why?"
• "What's the risk that this deal doesn't close, and what would you do about it?"

The roleplay shows execution. The debrief shows whether they can self-assess and think strategically about the sales process — essential for someone who will be operating alone without a manager coaching every deal.

Also ask one adversarial question: "Assume you are six months in and pipeline is thin. What do you do?" You want to hear a specific answer about outbound motion, not a vague "I'd work harder" response.

---

Stage 4 — Reference Calls (structured, two calls)

Purpose: Verify the pattern you saw. References almost always confirm or contradict the roleplay signal.

Ask former managers:

1. "What type of sales environment did [name] thrive in — high inbound, named accounts, or both?"
2. "How technical was the product they sold, and what was their learning curve?"
3. "What did their pipeline look like when they had to build it themselves?"
4. "Would you rehire them? If not, why?"

Do not accept "they were great" as a complete answer. Push on specifics. The single most predictive reference signal for your context: a manager who says they could build pipeline independently and held their own in technical conversations with skeptical buyers.

---

What to Skip (and Why)

Common Practice	Skip It Because
Personality/DISC assessments	Predict style, not performance in your specific motion
Panel interviews with 5+ people	Adds noise, not signal; intimidates strong ops-domain candidates who aren't used to startup theater
"Tell me your biggest weakness"	Produces rehearsed answers; the roleplay already surfaces real gaps
Homework decks (50-slide market analysis)	Too much work for a seller role; use the discovery exercise instead

---

Summary Decision Criteria

Before extending an offer, verify all four:

• Sold a technical product to an operational buyer — confirmed by the candidate's own words and a reference call
• Has built pipeline on a small named-account list without relying on inbound
• Discovery exercise showed genuine problem-diagnosis framing, not product-pushing
• Can operate the full cycle alone — evidence from prior roles, not just self-report

If any box is unchecked, do not substitute enthusiasm or raw intelligence for the missing signal. A first sales hire who requires 6 months to unlearn the wrong motion before they start building the right one is a materially expensive outcome with one budget slot.

Role Consolidation & Restructure Plan

40-Person Agency — Overlapping Departments

---

Situation Summary

Three specific problems are named and drive this plan:

1. Two people performing identical account management work — duplicated effort, unclear ownership.
2. Three teams each running their own reporting — three separate data pipelines, three sets of tools or spreadsheets, no single source of truth.
3. No process ownership — decisions stall, work falls into gaps, and accountability is diffuse.

This is not a headcount reduction exercise by default. The goal is to remove the duplication while keeping every capability the agency needs — and to give people clarity, not anxiety. Whether any roles ultimately become redundant depends on what the diagnostic phase (Phase 1) surfaces. That distinction matters for how you communicate it.

---

Phase 1 — Diagnostic (Weeks 1–2)

Do this before any decisions about people.

1.1 Role Mapping Audit

For every person in the three affected departments, produce a one-page role reality sheet:

Column	What to capture
Stated job title	From contract / HR system
Actual recurring tasks	Self-reported + manager verified (30-min interview each)
Time allocation	% across task categories — estimate is fine
Outputs owned	What deliverable or decision is theirs alone
Handoffs given	What they pass to whom
Handoffs received	What they receive and from whom
Tools used	Especially reporting tools — every distinct one

Why the interview matters: job descriptions at fast-growth agencies drift. Two people with different titles often do the same work; two people with the same title often do different work. The audit reveals what is actually happening.

1.2 Reporting Audit

For each of the three team reporting processes:

• What data sources feed it?
• What is the output (dashboard, slide deck, email, spreadsheet)?
• Who reads it and what decision does it drive?
• How long does it take to produce per cycle?
• What tool or platform runs it?

This surfaces whether the three reports are genuinely different (different audiences, different decisions) or duplicates with cosmetic differences.

1.3 Process Ownership Gap Map

List every cross-department process — briefing, delivery, reporting, client escalation, invoicing handoff — and record who currently "owns" it. Where the answer is "nobody" or "it depends", mark it red. This is your accountability gap register.

Phase 1 output: a single document — the Overlap and Gap Register — listing every duplication found, every ownership gap, and the estimated hours per week consumed by each. You need this before any restructure conversation is credible.

---

Phase 2 — Design (Weeks 3–4)

Design the target structure against the audit findings, not against an org chart preference.

2.1 Account Management Consolidation

The two people doing identical account management work represent one of three states:

State	What the audit shows	Correct action
True duplicate	Same clients, same tasks, same outputs	Consolidate to one role; redeploy the second person to a gap
Volume split	Each manages a defined client set but the role design is identical	Keep both people, redesign with clear client ownership per person, document the split
Informal specialisation	One handles retention, one handles growth — but neither role says so	Formalise the specialisation; give each a distinct title and scope

Do not assume state before the audit. The audit decides.

2.2 Reporting Consolidation

Target state: one reporting function, one data pipeline, one owner.

Design steps:

1. From the reporting audit, identify the union of all data needs across the three teams.
2. Designate one reporting owner — this is a role, not just a name. Write a one-page scope of what they own.
3. Select one tool or platform. If the three teams currently use different tools, the selection criteria are: covers the full data union, lowest migration cost, highest adoption likelihood.
4. Retire the other two reporting processes on a named date.
5. The two people who previously ran reporting in the non-primary teams do not disappear — their time is now freed. Map that freed capacity against the gap register from Phase 1.2.

2.3 Process Ownership Assignment

For every red item in the gap register:

• Assign one named owner (a role, not a committee).
• Write one sentence defining what "owning" means: the decision they make, the output they produce, the escalation they handle.
• Do not assign ownership to someone already at capacity — freed capacity from the consolidations feeds this.

Phase 2 output: a draft org structure with named roles (not necessarily named people yet), a reporting ownership diagram, and a revised process ownership register with every gap filled.

---

Phase 3 — People Decisions (Weeks 4–5)

Map people to the new structure. This is where morale risk lives — manage it deliberately.

3.1 Capability-First Matching

For each role in the new structure, list the three or four capabilities it genuinely requires. Then score each affected person against those capabilities — not against seniority, not against likeability. A simple three-point scale (strong / adequate / gap) is enough.

This produces a matching matrix:

New Role	Capability Requirements	Person A	Person B	Person C
Consolidated Account Manager	Client retention, brief management, escalation handling	Strong / Strong / Strong	Strong / Adequate / Gap	—
Reporting Owner	Data tool proficiency, stakeholder communication, deadline discipline	—	Adequate / Strong / Strong	Strong / Strong / Strong
[Gap role from register]	…	…	…	…

Best-fit matching against this matrix reduces the risk of putting the wrong person in a role they will struggle with — which is a morale problem, not just a performance one.

3.2 Redeployment Before Redundancy

The goal stated in the brief is reassignment without losing capability. Work the gap register first: every freed hour from consolidation should be mapped to a named unowned process before any redundancy conversation begins. If freed capacity covers all gaps, no roles need to be eliminated — the structure is leaner, not smaller.

If, after mapping freed capacity against all gaps, a role genuinely has no home:

• That determination is made on paper before any individual is told.
• The affected person should hear it from their direct manager in a private conversation, not in a team meeting or after others already know.
• The sequence matters legally and ethically: in most jurisdictions, a formal consultation period is required before a redundancy is confirmed. Check this with your employment legal adviser before communicating anything.

3.3 Transition Agreements

For anyone moving to a new or redesigned role:

• A written role brief — one page, not a full JD — covering what they own, what they do not own, who they escalate to, and what success looks like at 90 days.
• A named transition buddy from the team they are joining (if cross-department).
• A 30-day check-in scheduled at the point of the role change, not later.

---

Phase 4 — Communication and Rollout (Week 5–6)

Sequence and honesty matter more than messaging polish.

Communication Sequence

Step	Audience	Message	Timing
1	Senior leadership	Full plan, rationale, people decisions	Before anyone else hears anything
2	Direct managers of affected staff	Their team's specific changes, how to handle questions	24–48 hours before staff
3	Directly affected individuals	Their specific new role or transition	Private, 1-to-1, same day across affected group
4	Whole agency	What is changing at the structural level and why	Same day as or immediately after step 3

Do not let step 4 happen before step 3. The worst morale outcome is an employee learning their role changed from a company-wide announcement.

What to Say (and What Not To)

Say plainly:

• The agency grew faster than its structure, which created duplication and gaps.
• This plan fixes that. Here is what is changing.
• Here is what is not changing.
• Here is who to talk to with questions.

Do not say:

• "Nobody is losing their job" — if that is not yet certain, it is false reassurance and will destroy trust when it turns out otherwise.
• "This is just a reorganisation" — it is a reorganisation, but minimising language signals that leadership is not being straight.
• Anything that implies the affected people caused the problem — the structure grew around them, not because of them.

---

Phase 5 — Stabilisation (Weeks 7–12)

• Week 7: New structure live. Reporting consolidation running on new owner and tool.
• Week 8: 30-day check-ins begin for all redeployed staff.
• Week 10: First team retrospective — what is working, what is still unclear, what process gaps remain.
• Week 12: Overlap and Gap Register reviewed. Every item should now be green (owned, not duplicated). Any remaining red items are escalated to leadership with a named resolution owner and date.

---

Risk Register

Risk	Likelihood	Impact	Mitigation
Audit reveals more overlap than expected — a genuine redundancy is unavoidable	Medium	High	Follow legal consultation process; make people decisions before communicating; redeployment first
Reporting consolidation loses data a team relied on	Medium	Medium	Run old and new reporting in parallel for one full cycle before retiring old processes
New reporting owner becomes a single point of failure	Medium	High	Document the reporting process fully; cross-train one backup within 60 days
Staff resistance to role changes erodes morale	Medium	High	1-to-1 communication sequence; 30-day check-ins; genuine input into role briefs
Process ownership assignments ignored in practice	Medium	Medium	Publish the ownership register; make it the first slide at every cross-department meeting
Diagnostic phase takes longer than 2 weeks	Low	Low	Time-box interviews to 30 minutes; cap the audit document to one page per person

---

What You Need From Outside This Plan

Two items require external input this plan cannot supply:

1. Employment legal advice — before any conversation about redundancy is held with an individual, confirm the consultation process required in your jurisdiction. The sequence of decisions → legal check → individual conversation is non-negotiable.
2. Tool selection — the reporting consolidation requires a platform decision. That decision depends on what your three teams are currently using, your data sources, and your budget. The plan flags where it lands; the evaluation is yours to run.

---

Execution Summary

Phase	Key Output	Owner	Timing
1 — Diagnostic	Overlap and Gap Register	Operations or senior management lead	Weeks 1–2
2 — Design	Target structure + reporting ownership + process register	Leadership team	Weeks 3–4
3 — People decisions	Capability matching matrix + redeployment or redundancy decisions	Leadership + HR	Weeks 4–5
4 — Communication	Role briefs delivered; agency-wide announcement	All managers	Weeks 5–6
5 — Stabilisation	Gap register all-green; check-ins complete	Assigned role owners	Weeks 7–12

Engineer Departure + Demo Survival Plan

Situation Assessment

The real risk is not the missing documentation. It is an undocumented system breaking during or before the demo with no one able to fix it. Everything below is sequenced around that failure mode.

You have two overlapping clocks:

• Clock 1 — Knowledge transfer window: 10 working days before the engineer walks out.
• Clock 2 — Demo deadline: ~20 working days total.

These are not the same problem. Treat them separately.

---

Clock 1: The Next 10 Working Days (While He's Still There)

This window is non-renewable. Every hour spent on anything other than extraction is a permanent loss.

Day 1 — Today

1. Have one conversation with the departing engineer before anything else. The goal is not to guilt him — it is to negotiate. Most engineers who give notice are not hostile; they will do reasonable things if asked directly. Ask him for:

• A written architecture overview (even bullet points — 2 hours of his time).
• A guided walkthrough of the three riskiest or most opaque modules, recorded on Loom or equivalent.
• Agreement to be available for paid consulting after his last day at a rate you set now (e.g. £150–250/hr, 10-hour cap). Lock this in writing today.

2. Identify the demo path. You need to know exactly which features, screens, and data flows will be shown to investors. Write this list down. Everything that touches that path is Priority 1. Everything else is deferrable.

3. Set up a shared doc (Notion, Confluence, Google Doc — anything). Every piece of information extracted this week goes there immediately. Do not let it live in Slack messages or emails.

Days 2–5 — Structured Extraction

Run daily 90-minute sessions with the engineer. You lead; he talks; someone else types or the session is recorded. Cover these in order:

Session	Focus	Output
1	System architecture — what are the major components, how do they connect	One-page diagram or annotated diagram of existing system
2	The demo path end-to-end — every API call, every service, every dependency	Step-by-step trace of a demo run
3	Known fragile points — "what would break first if something went wrong"	A short list of named risks with symptoms
4	Infrastructure and deployment — how to deploy, roll back, restart services	Runbook: named commands, URLs, credentials location
5	Data — what the demo needs in the database, how to reset or seed it	Demo reset procedure

Do not attempt to document the full 40k lines. You do not have time, and you do not need it. You need the demo path documented to a level where you can diagnose and recover from a failure.

Days 6–10 — Validation and Backup Engineer

Validate the runbook yourself. Follow each documented step without asking him. Where you get stuck, that is a gap — fill it while he is still reachable.

Bring in a contractor now, not after he leaves. A senior contractor who overlaps with the departing engineer by even 3–4 days gets 10× more useful context than one who arrives after. Budget for this. Options:

• Toptal, arc.dev, or Lemon.io for vetted senior contractors (typical rate: $100–180/hr).
• Your investor network — ask your existing investors today if they have a technical contact or portfolio CTO who can advise or refer someone.
• A local freelancer who can be on-site is worth a premium right now because questions get answered faster.

What to tell the contractor in the brief: "We need someone to understand an existing Node/[your stack] codebase well enough to keep it running and demo-ready for 3 weeks. The previous engineer will be available for 1 week of overlap. Documentation is being produced now."

---

Clock 2: The 4-Week Demo Window

Freeze non-demo scope immediately

No new features until after the demo. Tell your team today. The only code changes permitted are:

• Fixes that prevent the demo path from breaking.
• Demo data setup and reset.
• Cosmetic changes explicitly required by the demo script.

Every other ticket is parked. This is not a negotiation — a half-finished feature discovered by an investor is worse than a missing one.

Demo environment isolation

If your platform runs on a shared environment, create a dedicated demo environment this week. Reasons:

• You can seed it with clean, compelling data.
• A developer mistake in a staging environment cannot break the demo.
• You can test the exact demo sequence repeatedly without side effects.

Rehearsal schedule

Week	Activity
Week 2	First full demo run-through in the new environment. Identify what breaks.
Week 3	Two rehearsals with the contractor present. Document every failure and fix.
Week 4 (days 1–2)	Final dry run. No changes after this point. Freeze.
Demo day	Contractor or you on standby with the runbook open.

Demo day failure protocol

Do this before the demo, not on the day:

1. Prepare a pre-recorded backup of the demo (screen recording at peak state). If the live system fails, you pivot to "let me show you the recorded walkthrough" without panic.
2. Assign one person as the technical monitor (watching logs or a simple uptime check) while you present.
3. Keep the demo reset procedure tested and under 5 minutes.

---

Honest Assessment of Your Situation

What is achievable: A demo-ready system with a documented critical path, a runbook that lets you or a contractor recover from likely failures, and a contractor engaged before the engineer leaves.

What is not achievable in 4 weeks: Full documentation of 40k lines, a meaningful test suite, or a system that is safe to develop new features on at speed. Do not attempt these before the demo — they compete for the same hours.

Biggest single risk: You fail to extract the demo-path runbook before the engineer leaves, something breaks in week 3, and neither you nor the contractor can diagnose it quickly enough. Mitigate this by treating the runbook as the only deliverable that matters this week.

Second risk: You hire a contractor too late (after the engineer leaves). Every day you delay this costs you irreplaceable overlap time.

---

After the Demo: What to Do Next

This is not the time to plan this in detail, but note it now so it does not get lost:

• Conduct a full codebase audit with the contractor in week 5.
• Begin writing tests for the demo path first — the highest-value, lowest-coverage area.
• Hire a permanent senior engineer with documentation and testing in the job spec. The architecture knowledge the departing engineer held must never be singular again.
• Consider whether the platform's architecture is sound enough to build on, or whether a partial rewrite of the most fragile modules is cheaper than maintaining the current state.

---

Immediate Actions — in Order

1. Today: Talk to the departing engineer. Negotiate post-departure consulting. Write the demo feature list.
2. Today: Post a contractor brief on Toptal or arc.dev. Email your investors asking for referrals.
3. Tomorrow: Begin the first extraction session. Set up the shared knowledge doc.
4. This week: Create a dedicated demo environment.
5. End of week 1: Validate the runbook yourself. Identify gaps before the engineer leaves.
6. Week 2: Contractor starts. Overlap with departing engineer even for 2–3 days.
7. Week 2: First full demo rehearsal.
8. Week 3: Record the backup demo video.
9. 2 days before demo: Final freeze. No changes.