engineering brain in a sales jungle
Three weeks into a hyper-growth startup role in sales after ten years in engineering. The cultural differences are stark, the organizational ones even starker. I’m still not sure if what I’m seeing is just sales-culture standard or if it’s the nature of a hyper-growth org where things move so fast that structure hasn’t caught up. A few things I’ve noticed:
1. hierarchy of value
In an engineering-led company, sales sits lower on the totem pole.
Engineers are revered — and for good reason. Their skills are hard to acquire, the barriers to entry are steep, and the work they do ships the product itself. Sales, on the other hand, is built on hustle, personal networks, soft skills. Respectable, yes — but harder to quantify, easier to dismiss. And that difference in perception shows up in the culture.
2. the chaos of open loops
Half of sales feels like keeping track of open loops.
- Customer asks a technical question → you don’t know the answer
- You Slack a channel (if you can even find the right one)
- If no one responds, you ping again or track down the right engineer
- Then you circle back to the customer
Multiply that by dozens of threads across Slack, email, and meetings, and you end up chasing ghosts. It’s disorienting.
In engineering, the product lifecycle is tracked in Linear or JIRA: each ticket is an entity, requirements are documented, pull requests link back, and the whole thing is traceable. Sales feels more like a messy inbox of threads and favors. Sure, Salesforce exists, but it’s clunky, and at least so far it hasn’t given me the same clarity of workflow that an engineering tracker does.
3. proving your value
In sales, it’s not just about doing the work — it’s about showing the work. If you can’t trace back what you’ve done, it’s easy to get overlooked, miss a promotion, or worse — leave yourself vulnerable when someone complains. Politics thrive in the gaps. Documentation becomes survival.
4. my experiment: a personal ledger
So here’s my plan: build my own personal accounting system.
- An npm script spins up a new Markdown file for the day with a template
- Throughout the day, I dictate notes via Wispr Flow:
- “8:30am — followed up with X on Y issue”
- Links to Slack threads, emails, meeting notes
- Screenshots of the calendar if needed
- At the end of the day, run a script that pipes the notes into an LLM (Claude, GPT-5, etc.) to summarize:
- Key wins
- Open follow-ups
- Weekly: roll-up reports for visibility and reflection
The homepage of the tool will show: What’s in my queue? What did I do today?
It doesn’t have to be pretty — it just has to be mine. A traceable picture of what I’ve done, ready to share when needed, and searchable when I forget. In messy environments, traceability is power.
5. structure vs speed
This experiment is partly about balance. Structured systems bring discipline, but they’re heavy. Fast, messy, nimble systems are flexible, but they cost clarity.
I want both: the ability to move quickly in the chaos while still leaving a breadcrumb trail I can rely on.
If I can nail that, maybe I can turn this jungle into something I can actually thrive in.