From AE to SE: What I’m Keeping, What I’m Unlearning

I spent fifteen years in sales across EMEA and North America. I went through all the motions. The high highs and the low lows. The stress eating at end of quarter. The intense exercise to keep up with everything. The sleepless nights. The repetitive phone checking and DocuSign refreshing at 2am.

And then I became a Solutions Engineer.

People ask me what the transition is like. The honest answer is that it is equal parts exhilarating and humbling. There are skills I brought with me that made me effective faster than I expected. And there are habits I built over fifteen years that I have had to consciously unlearn. Not because they were wrong. Because they were optimized for a different job.

Here is what I have figured out so far.

What I kept: the commercial instinct

Most SEs come from a technical background. They understand the product deeply, but the commercial side of a sales conversation can be a blind spot. Reading the room, understanding buying signals, managing stakeholders, knowing when to push and when to pull back. These are skills that do not always come naturally when your background is technical.

For me, that instinct is native. I know what it feels like to be an AE trying to close a deal before Friday. I know why urgency matters, why a hesitant champion needs nurturing, and why the procurement conversation is never just about price. That perspective makes me a better partner to the AEs I work with and a more credible presence in front of customers who can tell when someone does not understand the commercial stakes.

If you are making this transition from a sales background, do not underestimate what you already bring. Your commercial instinct is not a consolation prize. It is a genuine superpower in this role.

What I kept: discovery

Great discovery is great discovery, regardless of whether you are an AE or an SE. The ability to ask questions that uncover real pain, not just surface-level feature requests, translates directly.

What changed is the depth and the direction of the questions. As an AE, I was asking about budget, timeline, decision criteria, and the buying process. As an SE, I am asking about tech stack, data flows, integration ownership, authentication setup, and what success looks like technically. The muscles are the same. The exercise is different. And learning to ask better technical questions has made me a fundamentally sharper thinker in the room.

What I am unlearning: the instinct to close at all costs

Fifteen years in sales wired me to move things forward. Every conversation was oriented around a next step that brought us closer to a signature.

As an SE, I have had to reframe what closing actually means. My job is not to close at all costs. It is to understand. And more importantly, it is to flag when something is not a good fit before anyone signs.

I genuinely care about what happens after the deal. The onboarding experience. The customer’s first 90 days. Whether they will be a reference in a year. Whether they will expand or churn. That long-term lens changes how you show up in a sales cycle. I would rather slow a deal down than accelerate a problem.

What I am unlearning: the ability to fake it

As an AE, I could sometimes navigate a difficult question with confidence and charm. Buy time. Redirect. Reframe.

As an SE, I cannot. When a customer asks a detailed technical question, they will know immediately if I am bluffing.

But it goes deeper than just admitting what I do not know.

The real skill I am building is knowing how to respond to a request that seems outlandish or technically complex without immediately defaulting to yes or no. Instead of answering the surface question, I have learned to ask a better one first. Why do you need this? What problem are you actually trying to solve? What does success look like for you here?

Nine times out of ten, the answer to that question reveals a workaround, an alternative approach, or a completely different solution that the customer had not considered. They did not actually need the thing they asked for. They needed the outcome it was supposed to deliver.

That is the difference between being a technical answer machine and being a Solutions Engineer.

The single most important thing I have learned is to say four words I was trained to avoid: I do not know. And then follow with: but let me understand what you are trying to achieve, and I will come back to you with a clear answer about what is possible.

Every time I have done this, trust has gone up. Not down.

The onboarding never stops.

Every complex customer is a new course you did not know you were enrolled in. Every edge case is a wall that becomes a door if you are willing to build the thing that opens it. I have had to learn API documentation overnight, draw architecture diagrams on the fly, and become fluent in conversations I had never had before.

Intellectual humility and a genuine love of learning prepare you better for this role than additional technical training.

If you have those two things, the rest follows.