Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Oh shoot, double surprise, and now from someone who isn't my co-worker who posted this.

Developer of the feature here, happy to chat through details of the implementation and general developer GTM watercooler advice for those who are building for developers.




How many folks do you have to support your slack channels? I'm counting 4-5 support engineers based on your about page?

What are your SLOs for messages?

How are you managing missed SLOs?


Excellent questions!

Railway has three support engineers who work on tooling + myself if you count me. (I have been more focused on customer migrations and classical sales as of late.)

One thing that I think we left out of the blog post which would have been helpful context is in our support tool, we have a queue of emails, Discord threads, forum posts, tickets, and Slack threads. Depending on the customer plan, we have an SLO assigned to the conversation. Enterprise people get a response in 1 hour, Pro in 24, and Hobby is best effort (usually 2-3 days at worst).

If we hit any of those timelines, the support on-call (a rotating person who is on the operations/GTM side of the house we call logistics) will get a page on PagerDuty. If the page is missed, it escalates up. We do a on-call rotation for support namely to make sure that we build the empathy for our customers for everyone at Railway while also testing if we built good tools that people know how to use. It's one thing to build something for yourself, a whole other thing to build for others.


I hope you stay better than Intel “community” forums where underpaid Intel employees take 3+ months to answer a post (original SLA was something like 2 days), return a poor quality response and then drop all further communication if the original author doesn’t respond in a couple of days (after waiting months).


That's my hope too- been at this company for 3+ years and there was a moment of time when it did truly feel like we would just spend time with only larger companies.

However, what's interesting is there is a direct correlation to the amount of conversations we can support and churn! We did put the walls up I'd say 18 months ago. Although it resulted in an okay business outcome as today, user churn numbers actually increased controlling for pricing changes.

Ever since we invested in our support tooling, we've been able to field more conversations and I think we (and the users) are better for it.

Talking to users- no matter how "small" they may be is a potential relationship for us to invest in. We will try to keep our heads to the ground always listening to users.

Talking to users and using our own product are the two hills we will die on. A company dies when they stop doing both, long before any financial reckoning I feel.


ah -- so they aren't "working in slack" that's just how/where the users interface.


Yep- key point, we work in Discord. We blogged about that too, https://blog.railway.com/p/how-we-work

The blog post is a bit old but the point mostly stands- we try to keep our customers close to us, but lately, we have extolled the virtues of focus work, so we rotate the customer comms baton through our on-call system.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: