PRINCIPLES OF A SOLUTIONS ENGINEER.
- Topic
- Principles
- Reading time
- 2 min
Seven principles I keep coming back to, learned between customer calls, go‑lives and late-night debugging sessions.
- 01
Own the outcome, not the ticket
In a customer project, the org chart rarely matches the problem. The deal, the integration and the go-live are mine even when part of the work officially sits with someone else. When something blocks a customer, I don't wait for a handoff to decide whose job it is. Nobody hands you ownership in pre-sales. You take it, or the project drifts.
- 02
Learn whatever the problem requires
Ad tech at Criteo, healthcare at Doctolib, payments at Alma, data infrastructure at RudderStack. Every move meant starting again as a beginner in a new domain, with new regulations, new jargon and new failure modes. Skills got me into the room. The willingness to learn fast is what kept me useful in it.
- 03
Stay curious past the brief
I test the things nobody asked me to test: the undocumented API behaviour, the SDK edge case, the AI tool that came out last week. Most of these detours lead nowhere. The few that work become the demo that wins a deal, or the workaround that unblocks a customer on a Friday evening.
- 04
Stay hands-on
Seniority should not mean distance from the system. I still build the demo, read the logs and write the transformation myself. With AI, an experienced engineer who keeps building moves faster than ever, and a working prototype will always say more than a description of one.
- 05
The customer's win is the only credit
On a deal, the best idea can come from anyone: the account executive, support, or the customer's own engineer. Defending my design over theirs only costs time. What matters is not whose architecture it was, but whether the pipeline runs in production.
- 06
Care about the details nobody checks
An event name, the retry logic on a webhook, the follow-up email sent the same day as the call. Customers rarely notice when the details are right. They always notice when they are wrong. Caring about them is hard to measure, and it is where trust is actually built.
- 07
Ship the proof, then refine
A proof of concept running on real customer data teaches more than a week of architecture slides. I would rather get something working in the customer's environment, learn from what breaks, and iterate. Shipping early is not cutting corners. It is the fastest way to find out what the customer really needs.