At Mainteny, a prospect once asked how our system would handle a scheduling edge case in their maintenance workflow. The question was too specific for a feature-list demo. It touched the data model, technician availability, recurring jobs, and what happened when a customer changed a request after dispatch. I could answer because I had built that part of the product. I explained the current behavior, the trade-off behind it, and a limitation they would hit if they used the workflow in a certain way. He signed the contract that week.
A sales call as an engineering loop
Good sales calls help the buyer make a decision. They do not make the buyer feel handled.
Why technical founders underrate this skill
I disliked sales for years because I associated it with pressure, vague promises, and performance. The version that actually works feels closer to engineering: a buyer describes a workflow, you ask for the current state, you find the constraint, you test whether your product fits, you explain the trade-offs, you write down what you heard and what happens next. Engineers can be good at this because the work rewards precision.
The strongest calls are demand calls, not pain-point interviews. I am listening for four things: the project the buyer already owns, why it matters now, which options they have tried, and why those options are not enough. If those four things are missing, a great demo usually turns into polite interest.
When I was at Bain building Aura, I watched how the most successful internal sales happened. The work was deeply understanding someone’s problem, showing exactly how the solution worked, and being honest about trade-offs. Partners who adopted Aura most enthusiastically were the ones who felt genuinely helped.
Deep product knowledge beats sales technique
| Career sales rep | Technical founder | |
|---|---|---|
| Edge-case question | 'Let me get back to you on that.' | Walks through the actual code path, the trade-off behind it, and the workaround for their specific case. |
| Architecture question | Has to check with the product team | Is the product team. Has opinions about the design and can defend them. |
| Limitation discussion | Avoided or spun | Named upfront, with a workaround the buyer had not asked about |
| Buyer's reaction | Delay, uncertainty, no decision | Trust, fast follow-up, signed contract |
This is the practical advantage. You are the product team. You can have real conversations about architecture, integrations, and implementation. In B2B software, those conversations often matter more than anything else.
The consultative mindset
The mental shift was simple. Stop treating sales calls as opportunities to pitch. Treat them as opportunities to understand. Your job is to help the buyer figure out whether what you have is a fit for what they need. If it is, the next step becomes obvious. If it is not, that is also useful information.
When you give people permission to say no, they listen with less defensiveness. When you are honest about limitations, they believe you when you talk about strengths. When the product is a poor fit, you learn that early.
Discovery: the engineer’s natural strength
Weak sales calls break during discovery. The seller rushes to the pitch before understanding the work. Engineers are almost pathologically inclined toward thorough discovery. We want to understand the problem before suggesting solutions. We are uncomfortable making recommendations without sufficient context. We ask follow-up questions because we genuinely want to understand the edge cases. That thoroughness is an advantage.
Ask with genuine curiosity. The best sales conversations feel like technical design discussions. You are both trying to figure out the right solution to a real problem. Sometimes that solution is your product. Sometimes it is something else.
Handling objections with technical honesty
Traditional sales training teaches you to overcome objections with clever rebuttals. Engineers often struggle with that because it feels manipulative. We can see through our own tricks. The good news is you do not need tricks. Honesty is more effective.
When a prospect raises an objection, they are telling you something important about their needs or concerns. Take it seriously. If the objection is valid, acknowledge it directly. Then do three things: explain why that limitation exists, describe what you are doing about it, and help them evaluate whether it is a dealbreaker for their specific situation.
Prospects do not trust salespeople who have an answer for everything. They trust salespeople who are honest about trade-offs.
At Luminik, prospects sometimes ask about features we do not have yet. Instead of pretending we are working on it, I tell them exactly where it is on the roadmap and why other things are prioritized higher. Sometimes they are fine waiting. Sometimes it is a dealbreaker. Either outcome is better than setting false expectations.
Follow-up answers build trust
A clear gap in the call can build credibility when the follow-up is precise. Pretending to know creates future trust debt. Send the answer within 24 hours, ideally with more detail than they expected. The follow-through turns the gap into a trust-building moment.
Practical tactics
| Tactic | Why it works | |
|---|---|---|
| Structure your calls | Opening, discovery, demo, next steps | Keeps you on track without making the conversation feel scripted |
| Demo less, talk more | Targeted 10-minute demo of relevant pieces only | Beats a comprehensive 45-minute feature tour every time |
| Take detailed notes | Write their exact words down | Lets you reference their language later, not generic feature descriptions |
| Send a summary in 24h | What you discussed, what you understood, agreed next steps | Demonstrates professionalism, gives them something to share with stakeholders |
| Negative close | 'Is this worth continuing, or not the right fit?' | Removes pressure and paradoxically increases yes rate |
| Useful follow-up | Specific next thought, not 'just checking in' | Engineers fear being pushy and under-follow-up. The opposite of pushy is useful, not silent. |
| Get comfortable with silence | Wait after the question | Silence prompts prospects to share more than they planned to |
| Record calls (with permission) | Review the recording later | You will hear bad questions, places where you talked too much, objections you handled poorly |
When to keep selling vs when to hire
Conventional wisdom says hire a salesperson as soon as possible. I think that is wrong. Founder-led sales has enormous advantages early. You learn directly from customers. You understand objections firsthand. You can make product decisions based on what you hear in calls. You build relationships with early customers that pay off for years.
More practically, you have not figured out the sales motion yet. Ideal customer profile, messaging that resonates, the right price point, repeating objections, typical sales cycle. You need to answer those questions before hiring someone to execute a process that does not exist yet.
| Keep selling yourself if | Consider hiring when | |
|---|---|---|
| Customer count | Closed fewer than 10 to 15 customers personally | You have a documented, repeatable sales process |
| Sales process | Cannot articulate it cleanly yet | It is repeatable enough to teach |
| ICP | Still evolving | Stable across multiple closes |
| Pricing | Still moving | Predictable across deals |
| Time consumption | Sales is not yet overwhelming | Sales is consuming more than 50% of your time |
| Product needs | Product needs your attention more | Pipeline is dropping deals because you are stretched |
Even then, the first sales hire probably should not be a quota-carrying rep. An SDR who handles outbound and qualification leaves you doing the actual selling. A customer success hire frees you to take more first calls. The goal is to extend your capacity, not replace yourself.
The practical advantage
Modern B2B buyers need help making a good decision. They want to talk to someone who understands their problem deeply and can have an honest conversation about solutions. They want technical credibility and clear tradeoffs. As a technical founder, you have all of that. You just need to stop thinking you need to be something else.
