DHH: "Email gets a lot of hate these days, but it truly is the king of communication. Yes, we all get a lot, but consider the alternative: Every email that would otherwise had been a meeting or a phone call."<p>I used to believe that email was <i>the king</i> of communication. Then I was exposed to this idea that "email is not communication". I rallied against this idea, and with my engineer hat on, I still do. I have written some great technical emails that have gained praise from co-workers for their clarity, accuracy, and logic. These mails have saved long, uninformed discussions, and the time put into crafting them easily saved in the moment, and often again in the future.<p>But then I started to think, and observe the wider climate... all those times that a well crafted email was written and well received, but a key (senior) team player ignored the resulting email thread, or when you needed to persude and not just inform, or when you're about to meet a client, and you need that answer you emailed about a week ago, and never got.<p>This pattern occurs again and again with overloaded resources: they see a long, detailed email thread between senior team members, but they don't have time (can't be bothered?) to read it. They assume that those involved are being "lazy" and not picking up the phone (oh, poor misguided people - crafting clear written communication takes much longer). This, usually senior person, needs to get a handle on the issue, so they drop a meeting into the calendar with the key players (and usually everyone else who doesn't really care). When the meeting gets underway you're ultimately asked to summarise 2000 words of concise emails in 5 minutes, (which turns into 15 because of interruptions from the meeting organiser, who is often your boss). The result is that the meeting organizer has most of the picture, and assumes that their calling the meeting means <i>they</i> fixed the problem - but there was no lack of working to a solution before. Even if you start to include exec. summaries of discussions, threads, etc. <i>this still happens</i>.<p>It's how the senior person can affirm their status. Some of you will say that <i>that's broken</i>, or <i>that's toxic</i>, but it's the norm in every environment I've worked in: both remote and not. <i>At least, when it's not remote, these discussions can happen around a whiteboard, and naturally attract or call over the right people to resolve it more quickly... which will still then get documented in an email/wiki/Basecamp.</i> In both cases, email alone is insufficient. (My best practice now: organise a f<i></i><i></i><i></i> call every time there is a complex issue arising, and <i>then</i> write the email. This wastes my engineer time because no one really understands what the issue is, but hey: the issue cannot be "missed" or "forgotten"; no one has been "left out"; I have not been "lazy". The email thread still ensues, but this time the senior peoples feel included. Then if it drags on, pick up the phone again).<p>The second case - I'm not a copy writer. I doubt I ever will be. My writing has always been logical and technical in nature. I'm trying to explain a defect/complex trouble shooting procedure/entity design/user interaction flow/describe an algorithm/the logical meaning of the constructs in an API. But as I rise in seniority I'm expected to get people on board with initiatives, with new tools, new ways of working. I'd love to think that the facts will win that argument, and they can be laid out in a nice email. Well, I've been there, and tried that. In response I get numerous requests for screencasts or meetings to explain these things. Why? It's not a lack of understanding. These people see <i>some</i> value in what I propose, but they want convincing. They need to hear the passion, enthusiasm, have the opportunity to ask questions - they don't want it to be a directive, but a collaborative decision. Email is never going to work in that situation. And infact writing the email in the first place seems to be a waste of time.<p>(I work remotely ~3 days a week, have lead teams of fully remote staff. My remaining ~2 days a week are spent visiting customers or in the office. In the office, I rarely meet my team or my project teams. But I do get to interact with people from marketing, HR, other product consultants, go to lunch with them, build a social relationship that is not so easy to do over the phone. I'd never want to give up the freedom of remote working, but I have to have those ~2 days of face to face connection - that's how you build a <i>company culture</i>.)