Rather than writing a guide, shouldn’t we automate this????
https://blog.railway.com/p/support-engineering-is-engineering
https://blog.railway.com/p/scaling-railway-automating-support
Follow in the footsteps of https://thundergolfer.com/blog/against-slack-dms for interactive graphics
Akshat review
And great blog post! Some random thoughts:
When I took my first startup job, I wanted a place that would train me as a good programmer. When I took the second one, as employee #7, I wanted a place that would train me on everything.
At startups “everything” is engineering, support, sales, marketing, growth, operations, and recruiting[^1].
This post, probably the first in a series, is about support. In particular, it’s about the core of support engineering in a “larval stage” startup, one with fewer than 30 engineers.
At Modal we have a strong customer focused culture. At Modal, all engineers talk to users directly.
For Modal engineers, customer support work builds empathy with our users, informs what products to build, and shows which features need fixing. Our customers on the other end, themselves other engineers, love talking to the people who built the product. In cloud infrastructure, the most expert support naturally comes from the service owner.
We try to reply instantly. We sometimes reply at 1:36AM in the morning. We may get on planes and fly to you that day. We check back in.
The post is my distillation of the core mantras of early support engineering success, mantras which have served us well for more than three years.