This person is posting this to gather attention for his work on HN, so he probably doesn’t have billions of dollars of dirty slave-labor fast fashion empire money to advertise with like H&M…
I lead the solutions engineering team for a company called Hightouch.
My background:
- Started off my career as an SSE (Demo builder) at Salesforce and eventually moved to software engineering at Salesforce working on their analytics product.
- Spend the rest of my career in front-end engineering (in startups, large enterprises, and everything in between)
- Started my own company (which we shuttered after 1.5 years)
- Made the move to sales to learn more about sales
My move to Sales Engineering was highly motivated to learn to sell since gaining sales experience is much easier in an established company (unlike programming, it's hard to become good at sales just by self-learning). Originally, it was a skill I wanted to learn to start my own company again, but ultimately I fell in love with profession.
My career as a sales engineer:
- Started off as a sales engineer at Algolia
- Move to Segment where I eventually became a leader for the West & APAC region
- Now I lead the Sales Engineering/CS team at Hightouch
One thing I've learned over my career is that Sales Engineering is very different depending on what company you work at. A sales engineer at Salesforce for example, is very different than what we have at Hightouch. Understanding the role that an SE team plays in the company overall can make a huge difference in the role.
If you are considering Sales Engineering, here's my grain of salt advice:
1. Joining the right company matters. Your comp is variable so whether or not you make a lot of money depends on the success of the company. Here's an article I wrote on my methodology when it comes to picking a good SaaS company: https://1stgeneration.substack.com/p/how-to-pick-a-winner-in...
2. Join a Sales engineering team that values discovery and sales skills. I've seen the most respected sales engineering teams come from teams who don't have the most technical people, but have people who can bridge business and tech together extremely well.
All in all, I love sales engineering. If you want to talk more - feel free to shoot me an email at ju[at]hightouch.io
>If you are considering Sales Engineering, here's my grain of salt advice: 1. Joining the right company matters.
I want to echo this 100x. IME experience there are two major things to consider.
At the end of the day your job as a Sales Engineer is to convince people to buy something. If you are a reasonably honest person you need to feel like the products you are selling are good. It's soul-crushing to sell a product you think is crap. Unless you are a dishonest person, then it doesn't matter. Work at a company where you believe in the product.
Some companies sell their products to the by mostly talking to the Executives and your job as an SE is to talk and sell vision. Some companies need their SEs to be much more technical and really work with customers on technical matters. Figure out kind of SE you want to be and go into the right role.
Sales is incredibly hard to learn without actually doing it. It's a soft skill so it requires a lot of reps and practice.
I wanted to get great at sales after my startup failed and I decided the best way to learn would be by joining a company as a solutions engineer (being a developer, I felt like it was role that was perfect for me since it combined sales with technical skills).
It ultimately ended up being the best decision of my life, and I couldn't imagine doing anything outside of sales/go-to-market now. I'm happy to talk more about my experience over zoom if you'd like! Feel free to shoot me an email at ju@hightouch.io
In terms of book recommendations, I do recommend the book "To Sell Is Human" by Daniel Pink to people deciding whether or not to get into sales. A lot of people associate sales with the "annoying car salesman", but this book gives really great insight into how sales has transformed into "consultative" in order to survive.
[Context: I worked with this team previously] Data here is coming from mobile apps, and is similar in volume to typical mobile app user analytics. I can certainly imagine that Segment would be a poor (or maybe just costly) fit for device telemetry in most IoT use-cases.
It hasn’t been an issue so far, but we have our own ingestion pipeline on our roadmap that will address this and other issues. (Renat from Kraftful team).
It might be just me - but I don't understand why any company would want to make their roadmap public. I feel like only the company's competitors ever look at it
I'd say if your competitors are relying on looking at your roadmap to compete with you, then they're in trouble. Single features are often easy to copy but it's a losing battle if your competitor is way out in front of you and you're trying to copy them feature-by-feature.
Similar argument with open sourcing your product. Couldn't your competitors look at your code? Sure they could, but if that's how they're trying to compete, they're going to lose. Plus, their engineers will probably look at your code and think they can do better anyway ;-)
We are a lot more concerned with making customers feel like part of the company’s growth than worrying about competitors.
Our customers love seeing the roadmap. And we are lucky to have an engineering team that really does deliver what’s promised. So we like to show that (hence the public release notes that connect to items on the roadmap).
This gives customers confidence that we really will deliver what we say we will, and they can plan their adoption of the product around it.
The community also really loves seeing their own suggestions make it into the roadmap. The way I see it, we’re all building this together.
At the end of the day, it’s not the best product that will always win. It comes down to community.
Why not? If i'm a potential customer and i see some features are missing, having the roadmap to visualise how they plan to evolve is great. Without that, why would i waste time contacting them, bothering with an NDA and what not just to know if they plan on adding X or Y?
Good question! Both Datafold and Atlan support data monitoring as a secondary feature, but have different main focuses:
Datafold is primarily known for their Data Diff regression testing that simulates the result of a PR on your data within a CI/CD workflow. There’s definitely a need for proactively preventing data issues from occurring in the first place, but issues introduced via code are only one subset of potential data quality issues.
Metaplane is focused on catching the symptoms first via continuous monitoring. Regression tests don’t replace the need for observability, and vice-versa.
Atlan is primarily known for their data workspace features that make collaboration easier, like a data dictionary, SQL editor, and governance.
Data collaboration is a huge unsolved problem and data monitoring does play a role there. But Metaplane is focused squarely on the problem of detecting data issues and giving you relevant metadata to prioritize and debug.
It’s crazy how much has changed in the data space in the past few years. You can basically set up a ‘modern data stack’ by swiping a credit card and buying fivetran (EL), snowflake (warehouse), DBT (transform), and hightouch (reverse-etl) for extremely cheap and without the need of an engineer. Just need to know SQL.
I think more companies are going adopt this modern data stack earlier in their data maturity lifecycle.
I would check out http://hightouch.com/. You can easily sync data from a warehouse to SFDC. You can also sync PG -> Airtable as well!