Solutions Engineering: The Misunderstood Role That’s Both Problem and Solution

Coke or Pepsi?

In recent interview for a senior solutions engineer role, I was asked a question by the NA head of sales the equivalent of “Are you a technical strengths solutions engineer or a sales professional solutions engineer?” as if one could only like Coke or Pepsi. While it’s an interesting and necessary question, I also think it’s the wrong question, or at least a flawed question in the way of unknown unknowns. I ended up explaining that there’s a third type that they were elegantly missing, but even then my answer missed a lot of the nuance in either the question or how we collectively understand solutions engineers.

Granted, I think there’s a lot of value in asking interview questions that don’t have clear answers, but a lot of this kind of questioning is the ‘validate what we see’ form of ‘does this person actually fit into our operations to hit what we need them to do?’ as part of tech sales ecosystem.

SEs then get queried along the following main lines:

  1. **are you a ‘technical’ solutions engineer, or are you a ‘sales’ solutions engineer
    1. ‘are you going to just sell the product and know your audience, or are you actually going to understand how it works’
  2. are you a pre-sale solutions engineer or a post-sales solutions engineer?
    1. hunter v farmer - is this person just going to be talktrack presales or are they actually going to care about clients post conversion and product on an ongoing basis?
  3. why don’t you want to be (blank) alternative role?
    1. if customer success manager, validation of technicality vs appetite for managing people over technical solutions
    2. if technical account manager,

EDITORIAL QUESTIONS:

  1. The three query lines you list (technical vs sales, pre-sale vs post-sale, why not alternative role) - should these stay as numbered list or convert to prose that unpacks each one more? Currently feels like it’s building toward something but stops.

  2. Context setup: You’ve established the interview scenario and the types of questions SEs face. Now - why does this misunderstanding matter? What are the consequences when orgs get this wrong? (organizational dysfunction, wasted talent, poor customer outcomes?)

  3. Transition: You mention “my answer missed a lot of nuance in how we collectively understand solutions engineers” - this is the bridge to the next sections. Should we make this transition more explicit before diving into Hunter/Farmer/Special Forces?

NEXT STEPS: - Third query line (why don’t you want alternative role) feels incomplete - expand on TAM example? - Bridge from “these are the questions SEs get asked” to “but here’s what’s actually happening in practice”

Presale talktracks - hunter SEs that can’t change their stripes

  • The “feature is on the roadmap” meme personified
  • Profile: Traditional white guy in tech who’s only lived in that stack
  • Massive disconnect from product, CS, and especially support
  • “But hey, they made their commission - what’s the problem?”
  • Result: Communicative and cognitive organizational disconnect

EDITORIAL NOTES - Development needed:

You’ve got great material here in your notes:

Concrete examples to develop: - The “good version”: Head of sales/CTO delineating presales vs caring about clients/product - The “bad version”: SE confidently saying features are on roadmap when they aren’t or don’t know - The “hunter gonna hunt” insight: time with product = time not on sales calls = lost commission

Five dangers of organizational disconnect to unpack: 1. Disconnect from product feedback 2. Selling disingenuously 3. Selling disingenuously while not coordinating with peers 4. SEs working as contractors/not part of org 5. Opportunity cost of lost potential

Development questions: - Should you develop one concrete example in narrative form (the SE who promises roadmap features)? - The five dangers list is strong - keep as bullets or expand each into analysis? - “Traditional white guy in tech” phrase - you want to keep it to skewer lazy SEs and poor org design. Should this be unpacked more explicitly in the text, or let the critique stand on its own? - Transition to Farmer section: is this an evolution from Hunter, or a different org choice? - Counter-example: You note “what about micromanagement?” - is this worth exploring as an opposite extreme? ## “Farmer” Deployment (Post-Sales Technical CS Manager)

  • More technical CS manager with less commission + daily scope creep threat
  • The “great soft skills + great technical skills + more responsibility” trap
  • Responsibilities that eat you alive: client escalations, product roadmap input, regular selling, white glove selling, CS artifact improvement, webinars, marketing, web presentations, existential dread
  • Better than hunters (no org disconnect) but speaks to terrible boundary setting
    • more than anything, it’s a quiet risk to management
    • mismanagement or lack of boundaries doesn’t have immediate costs
  • Dangerous in startups
    • will either get you a director role, a burnout, or ???

EDITORIAL QUESTIONS:

You’ve added key insights about “quiet risk to management” and lack of immediate costs - this is a strong angle.

  1. The “quiet risk” concept is compelling - should this be developed more? What does it look like when the delayed costs finally hit (turnover? quality degradation? health impact)?

  2. Farmer burnout: You list eight responsibilities and note the startup danger (director role, burnout, or ???). Do you have a concrete example or story to illustrate this arc? What’s the “???” - is that intentional ambiguity or something to develop?

  3. You note “are there healthy versions of this?” - good question. Is there a way to do the Farmer role well, or is it inherently unsustainable?

  4. Transition: How do we move from Hunter → Farmer → Special Forces? Different org choices, or an evolution in thinking?

NEXT STEPS: - Develop the “quiet risk” angle - why management doesn’t see the problem until it’s too late - Eight responsibilities list is strong but needs cost/impact analysis - Consider: healthy Farmer example vs unsustainable Farmer example?

Antibiotics? Special Forces? What We Actually Want SEs to Be

  • Deliberately and specifically used
  • Not overly applied grossly
  • Specific time, place, setting, duration, outcomes in mind (think course of antibiotics, not forever application)
  • Like this framing instead of camera, or special forces.
  • BUT this kind of framing is now how SEs are considered, or used
  • adjust these below to antiobiotic narrative
    • SEs as specialized tactical units deployed for specific missions
    • Like photography lenses: different SEs for different technical “shots”
    • You don’t waste special forces on routine patrol, and you don’t use a macro lens for landscapes
    • Strategic deployment based on mission requirements, not one-size-fits-all
    • Why organizations should want this version: efficiency, expertise, and outcomes
    • The business case for getting SE right

EDITORIAL QUESTIONS:

You’re shifting metaphors from camera/special forces to antibiotics - stronger framing. Notes to develop:

  1. Antibiotic metaphor needs unpacking: What does “course of antibiotics” look like for SE deployment? Specific time, place, setting, duration, outcomes - can you give a concrete example of an SE “prescription”?

  2. You note “this ISN’T how SEs are considered or used” - this is the key tension. Should we develop this more? What would need to change for orgs to shift from permanent assignment to deliberate deployment?

  3. Implementation: You mention “quiver of SEs with different skillsets deployed deliberately.” What does this look like organizationally?

    • Hiring multiple specialized SEs instead of generalists?
    • Pool of SEs deployed like consultants to specific deals?
    • How do you prevent this from becoming “bench time” problem consulting firms have?

  4. The old metaphors (camera, special forces) are still in the bullet list - should these be adjusted to antibiotic narrative as you noted, or keep multiple metaphors to reinforce the concept?

  5. Business case: You mention it but don’t develop it. Should this connect to the next section (costs), or expand here?

NEXT STEPS: - Develop one concrete antibiotic deployment example - Address the gap: “this isn’t how SEs are used” - why not? what’s stopping orgs? - Adjust metaphors to be consistent or keep variety?

Body Paragraph 4: Can You Afford NOT to Get This Right?

  • Cost of bad/limited SEs lacking technical skills
  • Risk of limiting their role artificially
  • The case for having multiple SEs vs trying to stretch one person

EDITORIAL QUESTIONS:

This section is still very thin - just placeholders. Your note suggests using the 1Password/Tailscale comparison here as the concrete example.

  1. Should this section come BEFORE or AFTER the “darling/dogwater” comparison? The comparison provides the concrete evidence for the costs argument.

  2. Cost specifics needed:

    • Revenue lost from poor technical sales conversations?
    • Customer churn from misaligned solutions?
    • Hiring costs from SE turnover?
    • Can any of these be quantified using the 1Password/Tailscale example?

  3. Your note: “doing more of what you’ve already done, or micromanaging, won’t fix your SEs or cultural/technological problems” - this feels like a key insight. Should this be developed as a separate point, or woven into the costs discussion?

  4. Multiple SEs vs stretching one person: Is this about specialization, capacity, both, or the “antibiotic deployment” concept from the previous section?

NEXT STEPS: - Consider reorganizing: move this section after the 1Password/Tailscale comparison? - Or: use the comparison as the evidence within this section - Develop the “can’t dig your way out of a hole” concept - This section needs substantial development before it can stand on its own

Red Flags Section: How to Spot SE Misunderstanding

  • Asking SEs to do programming work or deployments
  • Disconnect between SE and CS/Support/Product teams
  • CS +$10k comp as SE “strategy”
  • [Other red flags you mentioned]

EDITORIAL QUESTIONS:

  1. “Asking SEs to do programming work”: Where’s the line between acceptable and red flag?
    • Custom integration scripts = acceptable?
    • Building product features = red flag?
    • What’s the distinction you’re drawing?
  2. “CS +$10k comp as SE strategy”: Why is this a red flag?
    • Undervaluing SE complexity?
    • Creating incentive misalignment?
    • Signaling sales-mill mentality?
    • All of the above?
  3. Other red flags to add: Job posting language? Organizational structure? Reporting lines? Commission structures? What else signals SE misunderstanding?

NEXT STEPS: - Complete the list - what are the other red flags? - Decide if this should be bullets or developed into prose - Consider: should this come before or after concrete examples (Tailscale/1Password)?

What Technical Skills Does an SE Actually Need?

  • Sales methodologies (MEDDIC, Challenger, etc.)
  • Technical stack fluency
  • Interpersonal/body language/communication styles
  • Stakeholder mapping and messaging (especially Fortune 50 dynamics)
  • [Other skills?]

EDITORIAL QUESTIONS:

  1. Skills list completion: What other skills belong here?

    • Current: Sales methodologies, Technical stack fluency, Interpersonal skills, Stakeholder mapping
    • Missing: Presentation skills? Technical writing? Architecture understanding? Where does this list end?

  2. Why each matters: Should this section explain WHY each skill matters, or just list them? Voice guidelines suggest avoiding prescriptive “you should have X” tone. How do you make this analytical rather than prescriptive?

  3. Balance question: You’ve answered this one - “literacy via a framework, thus this post to break down things in a healthy fashion.” Should this be explicit in the text? Or is the whole post the answer to this question?

NEXT STEPS: - Complete the skills list - Decide: analytical explanation of skills vs just listing them - Consider: is this section even necessary, or does the Deployment Matrix cover this more effectively? - Your answer suggests this whole post IS the framework for understanding the balance - should that be made more explicit?

Examples: Good vs Bad Job Postings & The Compensation Reality Check

  • Decoding what companies actually want vs what they post
  • Red flag language in postings that signals SE misunderstanding
  • Green flag indicators of SE-mature organizations

EDITORIAL QUESTIONS:

  1. Actual examples: Do you have specific job postings (anonymized if needed) that signal:
    • Red flag language (what phrases scream misunderstanding?)
    • Green flag indicators (what signals SE-mature organization?)
  2. Decoding framework: Should this section teach readers how to decode postings, or just show examples and let them infer the pattern? (Voice guidelines suggest showing, not teaching)

NEXT STEPS: - This section still has zero concrete examples despite the title promising them - Need actual job posting excerpts (redacted/anonymized) - Or: cut this section and let the Tailscale/1Password comparison do the work? - The “Acute microcosms” section below might be where this develops?

Acute microcosms

  • org problems acute in how org approaches solutions engineering
    • list all parts of org that SEs can touch
  • how an org understands and goes to market for SE talent shows its thinking, flawed or not

EDITORIAL QUESTIONS:

This is a new section - interesting concept that SE approach reveals org problems.

  1. “List all parts of org that SEs can touch” - is this meant to be:

    • A literal list (Sales, Product, CS, Support, Marketing, etc.)?
    • An argument that SEs touch everything, therefore org dysfunction shows up acutely here?
    • Something else?

  2. “How an org goes to market for SE talent shows its thinking” - this connects to the job postings section above. Should these sections be merged? Or is this the conceptual framing and job postings are the examples?

  3. The title “Acute microcosms” is evocative - should this be unpacked? Is the idea that SE problems are a concentrated/acute version of broader org problems?

NEXT STEPS: - Develop the “parts of org SEs touch” concept - Connect this to job postings section, or merge them - Unpack the microcosm metaphor - SE dysfunction as symptom of org dysfunction

The difference between darling and dog water

The Compensation Reality Check:

  • Tailscale: SE roles paying ~$200K USD ($268K CAD), “competitive total compensation package” with equity and commission
  • 1Password: SE roles paying $89K-$121K CAD (~$66K-$90K USD), minimum $93K USD for US-based roles

What This Signals:

  • Tailscale: Treats SEs as strategic technical advisors worth premium compensation
  • 1Password: “Sales mill” mentality - SEs as cost centers rather than revenue multipliers
  • The hunter SE trap: Low base salary “compensated” by commission creates perverse incentives
  • Glassdoor reality: 1Password employees rate compensation 3.3/5 stars vs Tailscale’s 5/5 stars

Long-term Consequences:

  • Talent retention: Quality SEs migrate to companies that value strategic contribution
  • Solution quality: Underpaid SEs focus on volume over technical depth
  • Customer satisfaction: Rushed technical conversations due to comp pressure
  • Organizational learning: High turnover prevents SE insights from reaching product teams

EDITORIAL NOTE: ✅ STRONG SECTION - This case study is fully developed with: - Concrete numbers (Tailscale $200K vs 1Password $89K-$121K) - Clear consequences spelled out - Glassdoor data adds credibility

QUESTIONS:

  1. Section title “The difference between darling and dog water” - colorful, but does “dog water” need explanation for readers unfamiliar with the term? Or is the context enough?

  2. This section is well-developed compared to surrounding sections. Should it:

    • Stay as is (the anchor/proof point for the whole post)?
    • Become a callout/sidebar?
    • Move earlier to ground the abstract concepts?

  3. You reference this comparison in notes for earlier sections. Does this mean the structure should be: concept → example → analysis? Or: example first, then analysis?

When to Walk Away: The Special Forces Principle

Mission Assessment Framework for SEs:

  • Special forces operators assess mission viability before deployment
  • If intel is bad, resources inadequate, or objectives unclear → abort mission
  • Same principle applies to SE role evaluation

Red Flag Mission Indicators:

  • Skills misalignment: Principal Technical SE asked to do basic demos
  • Incentive misalignment: Strategic thinker paid like commission hunter
  • Values misalignment: Technical advisor role in “sales mill” culture
  • Organizational dysfunction: Disconnect between SE and product/CS/support

The Strategic “No”:

  • Disengaging from postings that signal SE misunderstanding
  • Recognizing wrong pressure types (volume vs. quality, commission vs. strategic impact)
  • Walking away from employers who treat SEs as interchangeable
  • Drawing boundaries around mission scope and success metrics

Why This Matters:

  • Accepting misaligned roles perpetuates SE dysfunction
  • Quality SEs choosing strategic deployments raises industry standards
  • Organizations learn SE value through talent scarcity, not accommodation

EDITORIAL NOTE: ✅ STRONG SECTION - Well-structured with clear frameworks: - Mission assessment framework is concrete - Red flag indicators are specific - “Strategic No” concept is compelling

QUESTIONS:

  1. Could this section be strengthened with one concrete example of walking away from a specific role/company? A brief story illustrating the “Strategic No” in action?

The SE Deployment Matrix: Know Your Type, Know Your Worth

Core Dimensions for SE Classification (Star Chart Framework):

Technical Depth Spectrum:

  • Junior Technical (can demo, explain features, basic troubleshooting)
  • Mid Technical (understands architecture, can customize, speaks dev language)
  • Senior Technical (can code solutions, debug complex issues, architect integrations)
  • Principal Technical (can evaluate technical trade-offs, influence product direction)

Stack Experience Axis:

  • Generalist (broad tech knowledge, quick to adapt)
  • Specialist (deep expertise in specific stack/domain)
  • Polyglot (multiple deep specializations)

Communication & Leadership Dimension:

  • Individual Contributor (personal technical excellence)
  • Team Influencer (mentors junior SEs, leads complex deals)
  • Cross-Functional Leader (manages SE team, influences product/sales strategy)
  • Executive Technical Advisor (shapes company technical direction)

Product Management Integration:

  • User/Demo Focused (shows what product does)
  • Workflow Integrator (understands how product fits customer processes)
  • Strategic Product Partner (influences roadmap based on customer needs)
  • Product Visionary (helps define future product direction)

Market/Demographic Experience:

  • SMB Specialist (quick demos, self-serve onboarding focus)
  • Mid-Market Generalist (process integration, multi-stakeholder navigation)
  • Enterprise Specialist (compliance, security, complex procurement)
  • Vertical Expert (industry-specific solutions and regulations)

Company Stage/Context Experience:

  • Startup Scrappy (wear all hats, build-while-you-fly mentality)
  • Scale-Up Structured (process-oriented, repeatable playbooks)
  • Enterprise Mature (established procedures, risk-averse environments)
  • Market Leader Strategic (competitive positioning, thought leadership)

Global/Cultural Operational Experience:

  • Local Market Only (single timezone, single culture)
  • Cross-Timezone Coordinator (async communication, handoff management)
  • Multicultural Bridge (works across cultural communication styles)
  • Global Enterprise Navigator (regulatory differences, local partnership dynamics)

Soft skills aren’t one thing

  • identifying job to do isn’t hearing a client isn’t finding the technical issue isn’t hearing a feeling
  • panorama of body language facial expressions tone matching etc

EDITORIAL QUESTIONS:

This is a new section - important concept that “soft skills” is too broad.

  1. Should this be its own section, or integrated into the Communication & Leadership dimension above?

  2. “Identifying job to do isn’t hearing a client isn’t finding the technical issue isn’t hearing a feeling” - this run-on sentence structure is effective but needs development. Can you unpack each of these distinct skills?

  3. “Panorama of body language facial expressions tone matching etc” - should this be a full list/taxonomy, or keep it evocative?

  4. This feels like it could be an eighth dimension of the matrix, or a callout that “soft skills” in any dimension is actually a cluster of distinct skills. Which direction?

NEXT STEPS: - Decide: new matrix dimension, or integrated into existing dimensions? - Develop the “panorama” concept - what are the distinct skills being conflated? - Consider: this might address question 19 about the “great soft + technical skills trap”

Real-World Deployment Examples:

SUCCESS: Principal Technical SE + Enterprise + Global experience assigned to Fortune 50 digital transformation initiative FAILURE: Junior Technical SE + SMB experience thrown into complex multi-national integration project

SUCCESS: Startup Scrappy + Generalist SE helping early-stage company pivot technical messaging FAILURE: Enterprise Mature + Specialist SE trying to operate in “figure it out as we go” startup environment

EDITORIAL NOTE: ✅ STRONG SECTION - Comprehensive 7-dimension framework: - Well-defined dimensions with clear progression - Technical Depth, Stack Experience, Communication & Leadership, Product Management Integration, Market/Demographic, Company Stage, Global/Cultural dimensions - SUCCESS/FAILURE examples are helpful - New “Soft skills aren’t one thing” section adds nuance

QUESTIONS:

  1. The “Soft skills aren’t one thing” section - how does this integrate with the existing dimensions?

  2. Could use more real-world deployment examples beyond the four given - do you have specific stories?

  3. Matrix might be overwhelming - should there be a “how to use this matrix” section? Or does the antibiotic/deployment framing earlier provide that guidance?

  4. Should the matrix come earlier in the post to provide the framework, then the archetypes (Hunter/Farmer/Special Forces) are mapped onto it? Or does current structure (archetypes → matrix) work better?

OVERALL STRUCTURAL QUESTIONS:

  1. Narrative arc: The current structure is: Intro → Hunter → Farmer → Special Forces → Costs → Red Flags → Skills → Job Postings → Acute Microcosms → Tailscale/1Password → Walk Away → Matrix → Conclusion

    Issues:

    • Hunter → Farmer → Special Forces progression works well
    • Then jumps to disconnected middle sections (Costs, Red Flags, Skills, Job Postings)
    • Recovers with strong Tailscale/1Password, Walk Away, Matrix sections
    • New “Acute Microcosms” section might tie things together?

    Options:

    • Consolidate or cut thin middle sections (Costs, Red Flags, Skills)?
    • Move Tailscale/1Password earlier to ground abstract concepts?
    • Use “Acute Microcosms” as the bridge/framing for the middle sections?

  2. Format inconsistency: Mix of bullet points (Hunter, Farmer, Costs, Red Flags, Skills, Special Forces) and developed prose (Tailscale/1Password, Walk Away, intro). What’s the plan?

    • Convert all bullets to prose?
    • Keep sections as lists for scanability?
    • Strategic mix based on content type?

  3. Length and scope: Original draft was 178 lines, now significantly longer with new sections. Are you aiming for:

    • Comprehensive deep dive (expand all thin sections)?
    • Focused argument (cut peripheral sections to strengthen core)?
    • Current scope is right (just fill placeholders and refine)?

  4. Tonal decisions:

    • “Traditional white guy in tech” - you want to keep the edge to skewer lazy SEs/poor org design
    • “Dog water” slang - keep or explain?
    • Overall tone balance between provocative and analytical?

CRITICAL DECISIONS NEEDED: - What to do with thin middle sections (develop, consolidate, or cut)? - How does “Acute Microcosms” fit into overall structure? - Final length target and scope

So, what kind of a solutions engineer are you?

It’s fun to get to this point. My original answer was flawed in the way of going ‘a third type that X’

  • Your response: Type three - cross-functional integration that makes clients feel understood while providing critical linkage between sales and product
  • The problem: Even this response misses the nuance of how SEs actually get deployed and what they should be

EDITORIAL QUESTIONS:

  1. This conclusion section is started but thin. What’s the argument here?
    • Circling back to the opening Coke/Pepsi question?
    • After all this analysis, what kind of SE are you (or should orgs be hiring)?
    • Is the answer “it depends on the deployment” (antibiotic metaphor)?
  2. The bullet points repeat material from the intro - is this intentional (bookending), or should it develop further?

NEXT STEPS: - Develop the conclusion - what’s the takeaway after the whole framework? - How does this tie back to the opening interview question? - What action/understanding should readers have after reading this?

PARKING LOT

After establishing SE types, compare against:

  • Product Manager vs SE
  • CSM vs SE
  • Head of Product vs SE
  • Head of Sales vs SE
  • Head of CS vs SE
  • Forward deployed engineer vs SE

EDITORIAL QUESTIONS - CRITICAL DECISION POINT:

  1. Expand or cut? This “Parking lot” title signals unfinished work. Options:
    • Expand with actual comparisons (SE vs PM, SE vs CSM, FDE, etc.)?
    • Cut entirely as out of scope for this post?
    • Save for a follow-up post?
    • Leave as brief list for context?
  2. If expanding: What’s the comparison framework?
    • Responsibilities and scope?
    • Skills and technical depth?
    • Organizational positioning and reporting?
    • When to choose one role over another?
  3. You added “Forward deployed engineer vs SE” - this is an interesting comparison given FDEs are also specialist deployments. Worth developing?

RECOMMENDATION: - This feels like a separate post topic - Current post is already long and complex - Could be cut with a note “role comparisons in future post” - Or keep as a brief teaser list if it serves the narrative