The Sales Engineer Pairing: How We Stopped Losing Deals on the Technical Call

We used to lose deals in the same place every quarter: the second call. The first call — vision, budget range, vibes — went great. The technical call went sideways, because the person who took it was either too senior to care or too junior to commit. We fixed it by putting two people on every technical discovery: a closer and a working engineer. Close rates moved, but the more interesting effect was on the projects we won.

Why the second call kills agency deals

Most agencies run sales like this: a founder or account director handles the first conversation, qualifies budget, and then either (a) handles the technical follow-up themselves and bluffs, or (b) hands off to a senior engineer who treats the call like an interruption to their sprint.

Both fail, differently.

The bluffing route produces a proposal that looks confident and is quietly wrong about half the scope. You win the deal, then spend the kickoff backpedalling on what "integration with their ERP" actually means. Scope creep is baked in from day one because the original commitment was vapor.

The senior-engineer route is worse for conversion. Engineers who are pulled out of build work to talk to a stranger tend to do one of three things: over-architect on the call ("you'll want a message queue here"), under-commit ("it depends"), or visibly check out. Prospects read all three as risk.

What prospects are actually testing on call two

From debriefing about forty lost and won deals, the pattern was consistent. On the technical call, non-technical buyers are testing two things:

1. Can these people translate my messy business problem into something concrete?
2. Will the person who shows up to build it be as sharp as the person selling it?

That second one is the killer. If the salesperson is impressive and the engineer who shows up later is mediocre, the client feels bait-and-switched even if the work is fine. Putting an engineer on the sales call front-loads that judgement.

The pairing model, concretely

The structure we landed on:

• Lead (founder, account director, or senior PM): runs the agenda, manages time, handles commercial questions, takes notes.
• Engineer (someone who currently writes production code, not a CTO who hasn't touched a PR in two years): handles anything starting with "how would you...", "can it...", or "have you ever...".

The engineer is not there to scope the project on the call. They are there to demonstrate competence and to flag the three or four things that will materially change the estimate. That's it.

We ran this for about eighteen months across roughly sixty discovery calls. The pattern was clear enough that we made it a rule: no technical discovery call goes out the door with one person on it.

Who you put on the call matters more than the title

The engineer on the call needs three traits, in order:

1. Currently shipping. Someone whose last merged PR was this week, not last quarter.
2. Comfortable saying "I don't know, but here's how I'd find out in a day." This is the single most trust-building sentence in pre-sales. Confidence without certainty.
3. Can resist the urge to design the system on the call. This is the hardest part for good engineers.

Notice that "good communicator" is not on the list. We had better outcomes putting a slightly awkward senior engineer on calls than a smooth principal who hadn't shipped in a year. Prospects can tell.

How we prep — 20 minutes, not 2 hours

The failure mode of pairing is bloat. If both people prep for an hour, you've doubled sales cost per deal and the engineer hates you. We use a fixed 20-minute prep doc, shared before every call:

# Discovery Call Prep — [Client Name]

## What we know
- Industry, size, what they sell
- Stated problem (their words, quoted)
- Budget signal (range or "won't say")
- Timeline signal

## Three technical unknowns to resolve
1. ...
2. ...
3. ...

## Two commercial unknowns to resolve
1. ...
2. ...

## Red flags from call one
- ...

## Who owns what on the call
- Lead: agenda, commercials, next steps
- Engineer: technical unknowns 1–3, integrations, data

The "three technical unknowns" constraint is the important part. If you can't name them before the call, you're not ready and the call should be rescheduled. If you have more than three, you're trying to do scoping in a sales conversation, which doesn't work.

The on-call division of labour

During the call itself, we use a simple handoff rule. The lead opens, restates the problem from call one, and then says some version of: "I've brought [Engineer] because they'll be close to the build. They'll have some specific questions, and they can answer anything technical you want to throw at us."

That one sentence does a lot of work. It signals that the engineer is not a prop, and it gives the prospect permission to ask hard questions.

The lead then runs the clock. When the engineer starts going deep on an architecture tangent, the lead pulls them back: "That's a great topic for the proposal — can we park it and come back to budget?" Engineers don't always self-regulate on calls. That's fine. The lead's job is to be the regulator.

What changed when we ran this

A few things shifted, and not all of them were what we expected.

The obvious one: scope blowouts on won projects dropped. When the person who will build it has been in the room since call two, kickoff doesn't surface a pile of "wait, you wanted what?" moments. The proposal reflects what's actually buildable.

The less obvious one: we started losing some deals faster, and we started being grateful for it. An engineer in the room asks questions like "what does your current data look like — can you show me a sample row?" Prospects who can't answer that, or who get defensive, are prospects whose project will be a nightmare. Two-person calls surface that in 30 minutes. One-person calls let it hide until month two of the build.

We also stopped winning a particular kind of deal we used to win — the ones where the client was buying a vibe rather than a solution. Those projects were always our worst margins. Good riddance.

The cost, honestly

This isn't free. You're putting a billable engineer into pre-sales for roughly 90 minutes per opportunity (20 prep, 60 call, 10 debrief). At a 30% close rate on technical discoveries, that's about five engineer-hours per won deal.

For deals under roughly £15k, it doesn't pay off — the math just doesn't work. We don't pair on small projects. For anything north of that, especially anything with integrations or unclear data, it's the highest-leverage hour of engineering time in the whole sales cycle.

When pairing is the wrong move

A few situations where we skip it:

• Repeat clients with a known pattern. If we've built three things for them already, the engineer who runs their account handles discovery solo.
• Pure staff augmentation deals. The client knows what they want; they want a CV, not a conversation.
• Deals where the prospect explicitly wants to talk "strategy first." Bring the engineer to call three instead. Putting an engineer in front of someone who wants to discuss org structure wastes everyone.

Where we'd start

If you're an agency founder reading this and you currently run technical calls solo, try this on your next three opportunities: bring one currently-shipping engineer to the second call, give them the 20-minute prep doc, and have your lead run the clock. Debrief honestly after each one — did the prospect's questions get better answers? Did you learn things you wouldn't have learned alone?

Three calls is enough to feel the difference. If you want to talk through how we structure pre-sales for larger engagements, our services overview is a reasonable starting point, or browse the blog for related pieces on scoping and pricing. The pairing model isn't a sales hack — it's an honesty mechanism. It makes it harder to sell something you can't build, which is exactly what a good agency sales process should do.