Comment by pizzafeelsright | Hacker News Reader

Comment by pizzafeelsright | Hacker News Reader

pizzafeelsright

Ultimately this is a culture that requires leadership to establish and maintain.

I have tried without success as I was not seen as a leader in the area.

What I have done successfully is boil down my requests to allow async responses that do not require an exchange.

The template is generically: * Set context (what/when)

* Establish reasoning (what/why)

* Describe desired outcome (what/when)

* Request binary response (what/who) fulfill request or direct me to whom can.

Mx. Password Resetter, I got locked out of my account after 3 attempts, the self password resetter is currently down. I need to have my password reset by tomorrow morning. I am requesting either a reset of my account, let me know when the self reset will be online, or in the event you cannot please direct me to who can. My contact info is below in the event you want to verify my identity. Thank you

With enough context, an ability for them to tell me to gtfo or fix it, or pass the buck, the responses is generally < 20 minutes for most requests.

It’s funny because your sample communication reads exactly like an email.

Normally when it comes to remote work we like to talk about chat (slack, etc) and how to communicate in a way that lends itself well to asynchronous replies, but when you think about it, email is already perfect for this:

- Email generally doesn’t carry the expectation that the recipient will reply immediately

- Nobody emails with just “Hi” and waits for a response

- People already know how to craft email in a way that is self contained and doesn’t require a ton of back and forth

- Major open source projects, particularly the Linux kernel, are done entirely over email to great success.

Sometimes I wish typical remote companies would embrace email (with a searchable web archive) instead of chat. Mailing lists replace channels, you can always reply directly to take things off-thread, mail is an open protocol where you can use your own client… the advantages are enormous.

Chat apps like Teams, Slack should be used as essentially internal email with the option to drop into real-time synchronous chat. The main difference is that you have to be on the same instance so there are cases where email is still more appropriate, though.

Is this something the folks at Microsoft or Slack are actually saying "this is how our product is intended to be used" or is this just you saying "I wish these apps were different?" I ask because approximately 0% of the people I've met have ever used Teams/Slack/etc. as email, and approximately 100% of them use it as real-time synchronous chat first, and archive of past real-time chats second, and asynchronous chat a distant third.

I, and nearly everyone I've worked with, use Teams/Slack as async comms. Most of my colleagues are incredibly busy, so there's no expectation that we'll get an immediate, real-time, response. Generally, if real-time comms is needed, and the other party didn't respond via chat immediately, we ask "Can you jump on a quick call?"

What I've seen over the past 2-3 years is (company) email increasingly devolve most, though not all of the time, into announcements, automated workflow, and other FYI. If you're actually looking for a personalized response, even not immediate, the channel is chat in some form.

I don't like it really. Email was a respond in a day medium. Chat is now at least same day/hours. In general, people don't call out of the blue any longer though so chat is inevitably repurposed for pretty soon. I'm having to readjust workflows to that.

>the other party didn't respond via chat immediately, we ask "Can you jump on a quick call?"

That still asssumes they're always monitoring chat in near-real-time.

Not exactly, the “can we call” is usually to create a space to have that sync communication with someone but doesn’t always need to be immediate.

Rarely, I get a "Is this a good time to call you on your cell?" More frequently, "can we set up a video call soonest?" My point was, I don't know the last time I've had someone from work just call me out of the blue on my phone. And, honestly, there are only a handful of people outside of doctors/service people/etc. who do.

Back in the day, the phone rang--if not constantly--very frequently.

I definitely prefer the current way of working

Just throwing in some anecdata but this is how it has been used in the place I've worked at since the pandemic started.

Prior to remote work being basically the norm these tools were used more like traditional real-time chat in my personal experience (I'm sure it varies even still based on particular workplaces), but now its generally async with the possibility (but not expectation) of being synchronous if you happen to catch someone randomly available to be bothered at the specific time you send the message.

That’s how I work. Email is basically just there for things that need to be in “writing” like approvals or various requests. Teams is where I communicate, I get msgs like “approval is in your email” because I only check email when asked to. If it’s urgent or requires a real conversation then it’s a teams call otherwise it’s all done through chat.

(I’ve been wfh for about a decade now)

> Is this something the folks at Microsoft or Slack are actually saying "this is how our product is intended to be used"...

What those folks have to say on the topic is pretty irrelevant. What is relevant is how specific people (or groups of people) are using these text-based-communication tools.

> I ask because approximately 0% of the people I've met have ever used Teams/Slack/etc. as email

I've been working at a largeish company with employees all over the globe. It's very common for its employees to have to get information from someone who will be reporting to work 4->16 hours after the information requestor has clocked out for the day. Phrasing requests for information "as email" is one of the most (if not the most) correct ways to structure these requests.

When RTT for a reply is measured in hours rather than minutes, you tend to pack a bunch of useful information in to your request. (As an added bonus, future searchers often only have to read one or two messages to understand what was being sought and and why, and whether or not it was found.)

A properly worded slack message is indistinguishable from an email, and can pretty much be treated as such

I remember Slack themselves seeing it as an email replacement, and not intended for remote work. It struck me as weird because I was on remote teams using it differently, and it felt as if Slack was out of touch with their own product. This was all before Covid.

I have also seen people camp their email and use it as chat. Some of them don’t like Slack.

I'm not sure if it's an option to drop into real-time synchronous chat. Lots of places assume it's instant messaging, stress on the instant.

Maybe if there was an email client that looked a bit more like slack it could help those people transition into writing more meaningful messages.

sort of; the idea of having a phone and 'instant message' to always grab attention is ridiculous; text-chat all the same to me; if i have an emergency, blow me up with an audible alert ( a call of some sort, a mention with particular rules in place to not get over-mentioned ).

Email is crap-tier for internal communications IMO in that companies have 1 email for folks and it allows external entities to spam users (even if its internal spam). internal communication should be separated from external communication, this will help lower the phishing attack surface.

i'd argue people should treat "IM" like emails; get a response eventually; if you want immediate attention, schedule a calendar/meeting with somebody.

The biggest problem i see with chat-software is the attention-grabbing-notifications; silence all that stuff, and check on IM's every hour or so - set it up so that @mentions _might_ notify you in select channels.

I find it sad when doing a paired programing session, on a scheduled-meeting, that folks get _so_ distracted by the pings, popups, ect of notifications for queries that are not urgent. They need to practice 1) patience and 2) diligence in responding to things they've been directly mentioned or have knowledge about

All Communications are this way. I have no expectation on response time because those generally do not exist.

I have my deadline and SLA. How is make sure that these are well defined prior to taking on any task.

The ability to say to any level of management, I can do X and I can do y but I cannot do them both within your time constraints, is the superpower I wish I learned many years ago.

Yelling and screaming will not get it done.

Let's discuss your priority and get it done.

> "Nobody emails with just “Hi” and waits for a response"

I have to say, the zero-context "hi" in a Teams message has to be one of the worst violations of what we used to call netiquette.

> > "Nobody emails with just “Hi” and waits for a response" > I have to say, the zero-context "hi" in a Teams message has to be one of the worst violations of what we used to call netiquette.

I am guilty of this, but only on MS Teams. If you want to setup an audio call where Person A wants Persons B and C on a call together, you set up a new group chat. On MS Teams, the Start Call is disabled until the first message. So I will often put "hi" as a chat starter. MS Teams doesnt seem to see a chat as a bona fide chat until there is some spark of conversation, hence "hi"

What I do is call person B and then when the call is started add person C. Usually in a group chat if I hit the call everyone button it’s by mistake haha

Ok sure, but your use case doesn't necessarily imply that the "hi" message is sent without any surrounding context (ie, a previous message(s) preparing recipient for a call). My complaint was about a lone "hi", preceded by nothing, and followed by nothing (ie, putting the onus on recipient to respond to signal readiness to discuss... who knows what). It interrupts potential flowstate, creates an open loop, provides no hint as to priority, eliminates possibility of leveraging power of async comms to close a loop, and guarantees recipient comes into the future interaction unprepared. It only takes a few extra seconds to provide context ("hi, I could use help understanding X when you get a moment, ideally today"), so NOT doing that is, IMHO, either ignorant or rude.

"Major open source projects, particularly the Linux kernel, are done entirely over email to great success."

This is a good model of how to collaborate, but it's also a bit self selecting don't you think? Unfortunately the reality at most day jobs is that a lot of people you work with are simply trying to get by.

I've had almost the exact situation at my work. I eventually even put nohello.net in my status message and forced it to show up whenever someone messages me (which felt rude! but important). Wrote up a pros/cons document of async standup which referenced many of the benefits of properly practiced async communication, with the implication that we could adopt those principles in our regular communications.

I still get a "Hi" at least once a week. I've completely stopped responding to those. The cycle of grueling standups growing longer week by week until some form of reorganization cuts them back down continues.

If leadership says they're remote-first but doesn't understand the practice of async communication, I don't believe a job at that org can be good.

> I still get a "Hi" at least once a week. I've completely stopped responding to those.

A funny behavior I observed from those only-“Hi” people is that they will write their request after they don't get a response for a long-enough time.

"If I am available or not, please include your request in future messages so that I may fully respond in the event you're also not available"

Hi, bye, and thank you are implied. No need to say them in the course of business.

> My contact info is below in the event you want to verify my identity

You could take this a step further by proving who you are and a hash of the password you would like your password reset to. Like for example supplying a Yubikey TOTP as of the time of the e-mail should theoretically be sufficient; the IT people should be able to match that code against the e-mail time.

Unfortunately they may not be competent enough to know how to reset your password given the hash.

It goes both ways. Everyone is busy. Consider the following result:

Helpdesk is typing...

Helpdesk: "Hi"

(entitled to ignore you forever if you don't say hi back)

(... you finally do so more than 20 minutes later)

Helpdesk: "what's the servicenow ticket number?"

(you create a ticket and then after some lengthy amount of time getting escalated/reassigned your ticket status is blocked and you're asked to call the helpdesk number at hours that suit them and not you)

Reply on news.ycombinator.com