Live data from Hacker News

How we scaled Slack to support 1000s of developers

blog.railway.com

11–20 of 124 posts

Re: How we scaled Slack to support 1000s of developers

#11
post #8

Earlier quoted context omitted.

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 h…

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.

Re: How we scaled Slack to support 1000s of developers

#13
post #9

It's a cool idea that the end users can chat easily with the teams who build the product. (If I got that right, I think that's part of what is offered here.) Where I work, we have several layers in between engineering and the end users and ... while there's a lot to be said for increasing focus and reducing distractions, I think it's also nice to have the unfiltered contact sometimes.

This was the case at ${lastCo} and it bothered me to no end as PM. My job is literally talking to customers! Why do I need to chat to a relationship manager so that I can talk to my own customer?!?

That exact point was my very axe to grind and why I am thankful to work on all sorts of comms. automations at Railway when they let me.

Re: How we scaled Slack to support 1000s of developers

#14
post #6

Earlier quoted context omitted.

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 h…

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).

Re: How we scaled Slack to support 1000s of developers

#15

I like email. Just too many damn spam emails.

I agree, the growth marketer trend of nailing users with a marketing mailer every week drives me insane.

That gets an instant unsubscribe from me.

Sometimes it even works...

Re: How we scaled Slack to support 1000s of developers

#16

I like email. Just too many damn spam emails.

I agree, the growth marketer trend of nailing users with a marketing mailer every week drives me insane.

Yep honestly I got so tired of wading through marketing emails that I built a (free) email digest service for updates / changelogs from SaaS tools.

https://getchangelog.com

Re: How we scaled Slack to support 1000s of developers

#18
post #9

It's a cool idea that the end users can chat easily with the teams who build the product. (If I got that right, I think that's part of what is offered here.) Where I work, we have several layers in between engineering and the end users and ... while there's a lot to be said for increasing focus and reducing distractions, I think it's also nice to have the unfiltered contact sometimes.

This was the case at ${lastCo} and it bothered me to no end as PM. My job is literally talking to customers! Why do I need to chat to a relationship manager so that I can talk to my own customer?!? That exact point was my very axe to grind and why I am thankful to work on all sorts of comms. automations at Railway when they let me.

Because you don’t have people skills!

https://youtube.com/watch?v=hNuu9CpdjIo

Re: How we scaled Slack to support 1000s of developers

#19

Earlier quoted context omitted.

I agree, the growth marketer trend of nailing users with a marketing mailer every week drives me insane.

That gets an instant unsubscribe from me. Sometimes it even works...

If I never subscribed I always report spam. It only takes very small percentages of recipients to do this for mailer services to start getting agitated about bounce rates.

Re: How we scaled Slack to support 1000s of developers

#20

Earlier quoted context omitted.

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 h…

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.

Post reply on HN