More engineers should consider working in sales

More engineers should consider working in sales

Contents

Professionally, there are really two questions I get asked constantly:

  • How did you become a software engineer with no formal training?
  • Why did you decide to move from engineering into GTM (technical cs and sales)?

The first is straightforward. Countless engineers have taught themselves and transitioned into engineering successfully. It's a well-traveled path. The second? Less so.

Why, people ask, would someone who enjoys software engineering ever want to move to a customer facing (non-engineering) role? Normally, followed by "are you ok?" and various expressions of horror, bewilderment, and disbelief.

Let me deal with that one.

Software engineering is fun

Software engineering is mentally stimulating. Finding a problem, solving it with code, and then seeing people use it, is truly thrilling. Building something from nothing? So satisfying. Chasing down an elusive bug and solving it? Can't beat it. Finding a performance issue and unlocking resources from thin air? Am I an actual wizard?

And don't get me started on giant whiteboards, architectural decisions and bike shedding things that don't really matter. Who wouldn't want to be a software engineer?

Apparently, me. But you can scratch that itch while working in sales.

Selling software, specifically selling to engineers, means you get to do this all day, every day. If your company lets you. Selling to technical users often means you get to be a part of their process.

Working in a customer-facing role with engineering teams means that you get to see a variety of engineering teams, processes, architectures, and business models every day. A day in the life of technical software sales is truly different every day. I'm not working on the same code base, product or even company. In a given day, I could very easily end up:

  • Debugging a customer issue from pairing on their code base and how our product interacts with it

  • Brainstorming high level architecture for keeping state in sync across their front and back ends

  • Writing custom SQL queries to unlock brand new use cases for their business

  • Helping a customer understand which errors are actually impacting their users via session recordings, logs and analytics events

  • Raising a PR on our own code base to unblock a customer

And this is across business, languages and engineering teams.

It's still software engineering at its core, but every interaction is truly unique. And there are things I can learn from an ecommerce customer that may later apply to a B2C learning platform.

Buying software is not fun

"Be the change you wish to see in the world, or something." - Gandhi / Michael Scott (disputed)

Better yet, as an engineer working in sales, you help make something engineers hate doing joyful.

Inevitably, being a software engineer means you have to buy some type of tooling or other software, with money. A lot of dev tools are PLG, so you can signup, use it for free for a while, eventually enter a credit card and pay for what you use. Others, well, you often find yourself needing to "Contact Sales". This is the worst.

Usually this means filling out some details in a form, waiting for someone to reach out to you and ask you similar questions, before getting on a call with someone who can sell you the product, but can't always help with your actual needs, requirements, and limitations.

If you've been through this process, you've likely encountered "let me check with my team and get back to you" more than once. Both the buying process, and getting technical answers are painful.

Having an engineering context means I can help not only with what exists today (what the user can actually buy), but also what is possible. Feature requests, but right from the user. Not filtered through someone who talked to the user.

By understanding my own product well, I can often bucket feature requests for users on the spot. Most of the time, feature requests fall into one of the following buckets:

  • A small bug or feature with a small blast radius that is doable now, typically without needing to be planned and roadmapped

  • A slightly larger bug or feature that is aligned with my product and value, but needs to be planned and roadmapped

  • Something that I know we're not likely to build (whether it doesn't align with your business or is not architecturally sound)

  • Something that the customer is actually doing incorrectly without even knowing, and I can re-direct them to the correct solution on the spot.

Being able to process these in real time is massively helpful to get a user unblocked very quickly. And it's what an engineering buyer actually wants.

Being technically competent changes how engineers end users perceive me, but also my company and the product we build. And it takes it to another level when they realize the "sales person" helping them can raise a PR internally as well. You can often see the guard come down and the joy spark in real time.

Selling software is a new challenge

"Learn to build. Learn to sell. If you can do both, you will be unstoppable." – Naval Ravikant

Building software is a challenge. A problem to be solved. At the end of the day, so is sales, just in a different way. At PostHog, many of our team are former founders and I think most would say they will be founders again. As someone who fits that mold, learning sales is a thrilling, different challenge. Well outside of my comfort zone in some ways.

Learning to sell (or work directly with customers in general) is not only a new skill, but also an extension of engineering skills. It's problem solving all the way down. Whether you're building software, or helping other software products/team succeed.

Eventually, building software becomes talking to users and understanding their needs. Being on the front lines talking to them is the best way to learn this. I believe being in a sales role has made me a better software engineer.

And this comes in a few flavors. At a previous company I started as an engineer, was talking to enough customers that I ended up helping them and found myself as a Customer Engineer, and then leading a team of Customer Success Engineers. Eventually I was shuffled to a Forward Deployed engineer and then a Sales Engineer. All engineers with different titles.

Oh also, if you sell more, they pay you more.

If you like the sound of any of this, you should consider applying to one of our Technical Customer Success roles. We’re hiring in Europe and North America.

PostHog is your product's context layer. With a full suite of developer tools – AI observability, product analytics, session replay, feature flags, experiments, error tracking, logs, and more – PostHog ingests and stores all the data agents need to diagnose problems, uncover opportunities, and ship fixes. A data warehouse and CDP tie it all together, unifying that context into one source agents can read across. You can steer it all from Slack, the web app, the desktop (PostHog Desktop), or your own editor via the MCP.

Community questions