> It gives us 50x better engagement than email and 8x better response times to customers.
Does it mean that it forces the customers to send 50 messages instead of a single mail message?
> However, developers hate email.
Always feels awkward when there are general statements about the group you belong to, which are certainly false at least for you, and possibly for most others you know in that group.
If anything, I would expect developers to dislike a web chat, as tech-savvy people generally seem to prefer more lightweight and customizable options.
> That context helps Railway Engineers deliver a truly first class support experience.
Much of the post reads like a rather annoying advertisement.
I was curious why it was a problem to support thousands of customers in the first place, and looks like the issues were in combining conversations over different communication channels, and that a single overloaded person used to create those Slack chats.
I love email. It's the exclusive way we communicate at our company, too. We almost use it like Slack, writing short messages, usually getting a response pretty immediately. For group discussions, we use plain old mailing lists (Topicbox from Fastmail currently).
It's not perfect, for sure, but:
1. You can use a client of your choice.
2. You can filter in any way you like.
3. You're not stuck with any particular provider, and migration is not a big deal.
4. You can organise things in a way that works for you (inbox zero etc.), I find that a lot easier than the typical notifications.
5. It comes with all kinds of "integrations", e.g. GitLab comments can just be responded to via email, which I use a ton when on the go. A CI failure, customer question etc you can just forward to discuss it. When set up reasonably, it's the one communication channel you need.
It takes some discipline and self organisation, but I haven't heard about developers hating email. I think there's a ton of reasons not to hate it. Is it non-trivial to use well? Sure. Do others use it in questionable ways? Sure. The same is true for Slack and all that as well. But I can't think of anything that I found easier to manage at the end of the day.
Yeah, I personally gave up and embraced HTML email, so I can't really use some of the nerdier clients I like. Right now I'm pretty OK with Thunderbird - knowing that I _could_ switch any time I like is somehow good enough for me, it appears.
At work we use Thunderbird for regular communication but I sometimes have to dig into large exports (100+ gigabytes, up to 10 per mailbox) and mutt is very fast and responsive, so I've found an incantation for the config that strips the styling and layout.
What I don't have yet is the same for my bulk import to SQL database, but I'll probably figure something out in the next project where we need to analyse large amounts of email.
The one thing I like better about Slack over email is the lack of constant spam from random apps.
Working in a company means that only 1% of my email is actually from humans. I must constantly add new filters, because even small companies today use dozens of SaaS products that are constantly fighting for my attention, and only a small fraction of those messages is actually useful for me.
Slack so far is just humans. Plus integrations mostly added by developers for developers.
Of course this can change at any time, and I'll have random robot spam in Slack. Which means I will have no option other than start ignoring Slack as well and start asking people to come to my desk. Which might cause me to finally go into carpentry as I have been promising to do for the last 15 years.
The nice thing about those Slack integrations is that you can usually have a conversation with your team to adjust them for usefulness, such as better signal to noise ratio.
"usually" is the key word there. A previous employer had a "learning" team that used their slack bot to send unblockable DMs to everyone in the company every time they released optional employee trainings. "Work like an NBA player!" The manager was verbally abusive to anyone who brought it up as an issue too.
They didn't program the bot very well though, because it had a separate employee->acct list from the org that you could modify to change who was messaged.
We add some apps ourselves to our own profiles (I have the Google Calendar one for example) but this is at least opt-in.
The problem with email is that you subscribe to a service (or “get subscribed to”) and suddenly there’s 200 messages per week on your inbox that you gotta filter out and figure what the heck you’re gonna do with…
The worst part is that you often NEED some of those notifications, a small portion of them at least, but an email notification is the shittiest form of notification ever when SaaS apps are involved, and SaaS apps rarely allow for good configuration granularity.
This. It's gotten to the point where I don't check email at all because of the constant spam of mails that are not actionable and/or urgent. There are so many different types of automated mails that setting up filters is a never-ending battle. For me, email now serves as an archive/log of everything that has been going on in the company. I search my email to find details about things I am notified about via other channels.
Due to many people doing this, all important notifications that are actually actionable are now sent via Slack as well. So far these notifications are only for things where I actually need to urgently respond or do something, so none of the spam has yet reached Slack.
Also, no one ever seems to personally send an email to another employee because Slack is always the better option, and people actually respond on Slack, unlike via email.
And if they do make them to slack, usually all those things that you would have to manually make filters for are usually in their own channels that you can just mute.
If there’s one thing I hate more than email, it’s not being able to mark an item as unread, and put it in a folder to address it later. Slack is synonym of stress.
The Slack stress compounds with being pinged all the time, on various topics. It transforms a developer role into a manager role.
Remind me -> in 20 mins / 1 hours / 4 hours / tomorrow / next week. Or you can click the 'save for later' bookmark icon with no time alert.
The pings are within your control. If your org has an unruly Slack workspace, get on top of your notification settings or just leave it closed most of the time and check in periodically.
I’ve never thought GTD is a good system for programmers. The last thing I want to do is interrupt some important piece of work because an incoming request will only take a couple of minutes.
That's entirely contrary to my understanding and implementation of GTD - which is to have daily "scans" of my inboxes to see what tasks have come in since the last scan, bucket them into the appropriate categories/lists/record-keeping systems, and then _close those inboxes_ until the next scan. If anything, GTD keeps me _more_ interruption-free, by strictly ringfencing the times that I am open to processing new task-requests.
I assume you're referring to the 2 minute rule here. One of the main points of GTD is that you can just make a note of the interruption, so you don't have to deal with it right then, because you know it's waiting for you in a trusted system. (Which incidentally might just be a sticky note on your desk!)
Also, the 2 minute rule itself is flexible, just like the rest of the system. Sometimes it's a 30 second rule, and sometimes it's a 5 minute rule.
Both Slack and (most) email clients allow you to mark items as unread and set reminders. Being pinged all the time sounds more like an organisational issue, where comms channels are left to grow wild and unstructured. It's definitely not down to Slack.
Forgive me! Whenever I write internally or externally, it's usually a super long rambling piece and then we cut it down. The hardest part about writing for me making sure that everyone can have something to take away from it.
I'll zoom out- Railway got its first users from a Twitter post from the founder asking people to try the product. The founder then sat in a Discord voice channel during the winter break just answering mundane questions from people. Railway (like many DevTools at the time in 2021) was significantly more free than what it was today.
When I joined, we made the determination that Support Engineering, for the sake of our customers (staying sharp) and mental stimulation (we're not just help desk) - build our own automations to help users. (Blog post here: https://blog.railway.com/p/support-engineering-is-engineerin...)
(Railway also, intentionally, keeps our team small. Not out of elitism but out of alignment. The hardest part of working remote is making sure that people are on the same page. The tradeoff is that we are busier and need to be mindful about what work we take on. I, however, take it all on!)
Around 18 months ago or so- I started getting pulled into more revenue conversations as we moved upmarket. Railway moved into it's first proper plans. A lot of the prevailing advice we were getting was to start gating the product and start booking demos. So we did that for a bit much to the annoyance to developers. Then we started emailing them to see if they wanted to chat- I can't speak for you, but a lot of people in our book didn't reply. (Blog post: https://blog.railway.com/p/scale-not-sales)
In Railway's eyes- we think that Support/Sales is just the same thing just at different points of the developer's journey. A lot of engagements begin with a question.
The channel that did work was Slack Connect. After answering a question or two with companies on there- their usage would grow a lot. So we scaled that out!
Again, sorry if it read like an ad- not my intent.
> So we did that for a bit much to the annoyance to developers. Then we started emailing them to see if they wanted to chat- I can't speak for you, but a lot of people in our book didn't reply.
This looks like an amusing misunderstanding in both directions: I did not check the linked previous blog post until now, and interpreted it as developers disliking to use email to contact you, but apparently what you mean is that you contact them, for no important reason. I would not just ignore such an email, but probably would treat it as spam, and this sounds like the kind of thing some people dislike email for.
Yup. Excessive engagement maximizing is a bad thing for a communication method. If you succeed at maximizing engagement, all you have accomplished is a human Skinner-box. Good if you are in the business of selling attention, but not if you want productive employees.
My perspective is every form of communication bears certain unspoken rules / implications.
* Email - This is a serious thought out discussion
* Slack / Similar in a shared channel - This is office-formal, you should be professional but can joke around. Similar to how you would talk to an equal or your manager in person
* Slack / similar in DM - This is a rapid "Quick question" forum where you just need some links or quick thoughts. Nothing here is very serious
* Phone call - This is informal, rapid discussion for time sensitive issues. I'm calling you so that I don't have to page you.
Did you even read the article? This is about offering companies a private 1:1 slack channel between your team and the support/sales team. Many companies offer this nowadays if you're on a large enough plan to be assigned an account manager and I prefer it >100x to email because I know a human is going to be in the loop.
I did read the article, but my experience is that many companies offer support in a public chat context (Slack, Discord) as their first line. 1:1 is certainly better, but you're still limited in your ownership of the conversation (you literally have to copy and paste it out of Slack if you want records, because they may otherwise vanish outside of your control). I also like being able to find all communication information in one place. I can search across multiple channels and contexts with email all at once, but not with Slack.
I get that it's a preference thing, so I'm not saying my position is correct for you. If you don't care about any of these things, I can see Slack being better.
"Please don't comment on whether someone read an article. "Did you even read the article? It mentions that" can be shortened to "The article mentions that"."
Yeah, I'm with you. I'll take email over Slack any day. Especially for something I may need to refer back to in the future.
I had experience from the customer side of this situation, when Segment set up a Slack channel for an integration I was doing a few years ago. Lots of back and forth with their team (that would probably have been better as email), with some good, important stuff about how to work around particular issues.
Then one day, I get a message from a Success Engineer of some description saying that now we're up and running, they're going to "Archive" the channel. No worries. That must mean it'll go read-only, but at least I'll still have access to that good info in there. Better go copy/paste the whole thread somewhere safe though, just in case.
No. "Archive" is Slack for "Destroy Permanently". By the time I got the email, the Slack channel was 404ing. No more record of a conversation having ever taken place.
>Always feels awkward when there are general statements about the group you belong to, which are certainly false at least for you, and possibly for most others you know in that group.
You wrote this and then;
>would expect developers to dislike a web chat, as tech-savvy people generally seem to prefer more lightweight
I can't think of a more bloated way to communicate than putting a browser in the middle. For some quick numbers, compare web browser input latency to terminal [0] where one might run an IRC client. Even emacs [1,2] is fast and light in comparison.
Does it mean that it forces the customers to send 50 messages instead of a single mail message?
> However, developers hate email.
Always feels awkward when there are general statements about the group you belong to, which are certainly false at least for you, and possibly for most others you know in that group.
If anything, I would expect developers to dislike a web chat, as tech-savvy people generally seem to prefer more lightweight and customizable options.
> That context helps Railway Engineers deliver a truly first class support experience.
Much of the post reads like a rather annoying advertisement.
I was curious why it was a problem to support thousands of customers in the first place, and looks like the issues were in combining conversations over different communication channels, and that a single overloaded person used to create those Slack chats.