John Spooner

Playbook

Owning the Technical Sale

Solutions Engineering should not be a reactive technical support function inside Sales. I believe the SE and AE share ownership of the deal, with the SE accountable for engineering the right solution, managing technical risk and making sure the technology actually sells.

  • Technical Sales
  • Enablement & Leadership
  • Product & Market

In this playbook

  1. What does it actually mean for an SE to share ownership of a deal?
  2. Where should technical accountability begin and end?
  3. How do I balance winning the deal with protecting the technical teams?

An SE's job isn't to wait for an AE to assign technical tasks.

The AE and SE share ownership of the deal, bringing different areas of expertise to it. The SE's responsibility is to engineer the right solution and make sure the technology sells.

The weakest version of Solutions Engineering is reactive.

An AE requests a demo, so the SE delivers one. A customer asks a difficult question, so the SE answers it. Someone encounters a blocker, so the SE logs a ticket.

What value is the SE adding if they're simply executing somebody else's instructions?

A strong AE/SE pairing is a partnership.

The AE should understand the customer's business problem, commercial process and decision-making landscape. The SE should understand that context just as deeply while owning the technical discovery, solution design and path through evaluation.

Neither works in isolation.

If an AE asks me to demo, I expect enough discovery to understand what problem I'm supposed to solve. If that context doesn't exist, we do more discovery before the demo.

If a customer wants a trial but isn't ready to run one successfully, I won't activate it.

If the proposed solution is technically weak, I'll challenge it.

And if the product is fundamentally the wrong fit, I'll say so.

Owning the technical sale means being accountable for the outcome, not merely completing the technical tasks within it.

Do

Take responsibility for the technical outcome of the opportunity and challenge the plan when the evidence says it needs to change.

Avoid

Treat Solutions Engineering as a queue of technical tasks assigned by the AE or customer.

  1. Know the whole deal

    An SE shouldn't only know the opportunities where somebody has invited them to a meeting.

    They should understand the wider pipeline and recognise where their involvement will materially improve the likelihood of winning.

    If an AE is giving a straightforward product demonstration, perhaps the right answer is to enable them to deliver it themselves.

    If they're about to discuss complex security architecture with a prospect, I should already know that I need to be there.

    Once involved, I drive the opportunity alongside the AE until the technical work is genuinely complete.

  2. Own the solution

    The AE and I should agree on the customer problem, desired outcome and overall proposition.

    But the solution itself is my responsibility.

    I validate the assumptions, deepen the technical discovery, design the flow, determine how the product should be configured and make sure the AE understands what we are proposing well enough to sell it confidently.

    The AE owns pricing and contracting. I deliberately stay outside those conversations with the customer so I can remain a trusted technical advisor.

    Internally, however, I am commercially conscious. I need to understand the value and likelihood of the opportunity because technical resources are finite.

  3. Own the stakeholders

    Technical sales rarely involves one technical buyer.

    Architects, developers, security teams, compliance, business owners and end users can all influence whether a solution survives scrutiny.

    I want to know who they are, what they care about and what could cause them to block the deal.

    An objection remains mine until I understand the concern behind it and know whether it has actually been resolved.

    If I don't know an answer, I don't bluff. I'll test it live if appropriate or say that I need to verify it, then go away, get the right answer and usually walk the stakeholder through what I found directly.

    Technical credibility takes a long time to build and seconds to destroy.

    Do

    Keep ownership of a technical objection until you understand the concern and know it has genuinely been resolved.

    Avoid

    Bluff an answer or treat a technically correct response as sufficient when the stakeholder's actual concern is still open.

  4. Protect the technical teams

    Owning technical sales also means knowing what not to escalate.

    If every sales blocker becomes an Engineering ticket, Sales quickly consumes resources it doesn't own.

    My first responsibility is to understand the issue myself. I may work privately with developers to learn something particularly niche, but I should be capable of representing the company in the customer conversation.

    If a genuine product change is needed, I need to establish the business case and advocate for it internally.

    Sometimes the answer is a workaround. Sometimes it's a roadmap request. Sometimes it's simply that the requirement falls outside our core competency and indicates poor product fit.

    The SE should know the difference.

  5. Care about the customer after signature

    An SE is often the person in Sales best positioned to recognise a technically bad deal before it becomes somebody else's implementation problem.

    That creates responsibility.

    I won't support an implementation I believe is fundamentally wrong simply because somebody wants the contract signed.

    If another vendor is clearly a better fit, I have recommended them.

    Selling a poor solution only moves the problem downstream: implementation struggles, trust disappears and churn follows.

    I'd rather lose the wrong deal honestly than win it by creating a problem for the customer and the rest of the company.

    Do

    Optimise for a solution that can succeed after signature, even when that means challenging the deal or recommending another option.

    Avoid

    Create tomorrow's implementation failure or churn simply to improve today's chance of closing.

This philosophy changes how I behave throughout a deal.

I have refused to deliver demos when the discovery wasn't strong enough to make them relevant and required another discovery conversation first.

I would not activate an enterprise trial until the customer had completed the onboarding process, agreed success criteria and established the resources required to run it properly.

I regularly designed the narrative and technical implementation behind customer demonstrations rather than simply presenting a pre-existing environment. If new information emerged during a call, I would adapt the demonstration or introduce another capability where it helped solve the problem we were uncovering.

When recurring technical gaps affected opportunities, I built tools to remove them, pushed for product changes or advocated for fixes using the commercial impact as evidence.

And when I believed we were genuinely the wrong solution, I said so — including recommending competitors where appropriate.

That isn't separate from selling.

It is what responsible technical selling looks like.

  • The SE and AE share the deal. Different competencies do not mean different levels of ownership; the SE is accountable for engineering the right solution and driving the technical path.

  • Own the technical outcome, not just the technical tasks. Understand the customer, resolve objections, protect technical resources and spend effort where it can materially influence the result.

  • Don't create tomorrow's churn to win today's deal. Responsible technical selling means being willing to challenge a bad solution — or lose the wrong opportunity — before the problem moves downstream.