Hacker News Reader

Comment by jasode | Hacker News Reader

The author wants to educate people on the benefits of (more) text communication, but I don't believe it will change minds.

Reading the sibling comment from papaf[1] and also a previous reply to me by jakubp[2] about talking things out instead of email, it seems like the higher meta-analysis is that some people have a predisposition to prefer synchronous (videoconference, phone call, cubicle visit) over asynchronous communication (email, chat).

One group really prioritizes synchro comm for "emotional nuance" etc. The other group prioritizes written text's dense information content and searchability.

So if the company has folks like papaf and jakubp, it doesn't matter if you have a blog article recommending structured emails over video calls. Some employees prefer not to communicate that way. In fact, the blog article just makes them express their disagreement with it. E.g. papaf saying we're not "efficient robots" and jakubp advising me that I should accommodate his communication style of in-person cubicle visits.

To prevent clashing, I guess the higher-level advice is to hire a team where everybody likes to communicate the same way.

[1] https://news.ycombinator.com/item?id=28651678

[2] https://news.ycombinator.com/item?id=20583427

View on HN

> it doesn't matter if you have a blog article recommending structured emails over video calls

Exactly! Funny thing is that if you send these people an article explaining the benefits of written docs (design docs, RFCs, proposals, any text document documenting a decision), they will just simply not read it.

I'm on a team where I believe we started gigantic refactoring and redesigning projects without being clear on the goals, non-goals, and tradeoffs we take. I proposed that before we start working on something huge, we should write a short document where we explain what, how and why we want to do.

I recommended them some articles, for example "Design Docs at Google" [1], and "Scaling Engineering Teams via RFCs: Writing Things Down" by Gergely Orosz [2], but I couldn't even convince them to read those articles...

I didn't even send them my favorite posts about the Amazon 6-page memo, because I knew they'd dismiss the whole idea in a second (no matter if I told them that we could do "OurCompany 1-page memo").

This lead me to the sad realization, that our team will never start "writing things down". In my opinion, it would force us to think things through, but it seems like they disagree, or they just don't care.

My coworkers will not even read a 3-paragraph ticket, but they'd love to talk about the same ticket for an hour in a video call. Then in 3 weeks, nobody remembers anything anyway, and they discuss it again.

[1] https://www.industrialempathy.com/posts/design-docs-at-googl...

[2] https://blog.pragmaticengineer.com/scaling-engineering-teams...

You want to convince them, but you won't meet them on their terms to do so? Maybe you should try having a conversation with them about it instead. Actually, a series of conversations. And be patient because influencing other people's base assumptions takes time.

Put yourself in their shoes, they want you to understand the benefits of in person communication, so they schedule meeting after meeting with you to talk about it. You are immediately fed up because you actually do already understand the benefits, and all these meetings are a waste of time.

Wouldn't you rather they demonstrate that they understand your point of view by writing up a document, or sharing an article, describing the benefits of in person communication that you could consider on your own time?

I'll also say, one of the big benefits of in person communication is getting real time feedback on body language and tone which tell you how the other person feels about what you are saying. If that's not something you care to do in this instance, when it's so important for you to gauge their opinions on it, is it any surprise that they think even more written communication will only put the team even more out of sync?

Thank you for your note, I'll keep it mind in case I try to get them to document things and / or read things.

The goal of my comment wasn't to document every attempt I made in the last months to convince them that writing some things down would be beneficial for the team. I do speak with them, we have video calls and we also talked about this topic multiple times.

I wanted to point out that it's a funny experience when you send a document to someone with the purpose of providing them a great overview, highlighting the benefits of these design docs... And nobody reads them.

I already understand the benefits of in person communication, I don't want to eradicate video calls, I'd just prefer to write our decisions down so that other people who were not part of a decision can read these docs and join later.

In the end, I understand that I'm trying to change the status quo and change the team culture, I know it's a hard thing to do, and I get it that it will take a while.

Fair point, I'm sure there's a lot you are doing that didn't fit in the little white text box. Good luck!

> they want you to understand the benefits of in person communication

I doubt that. Mostly they just want to punt responsibility. (I've been in these shoes many times.)

A written record trail means the buck eventually stops somewhere. Talking it through without writing it down means you have plausible deniability.

This, I think, is at the root of the good and bad of written conversation.

At its best, it allows the author to articulate their thoughts and share it widely for readers to consume and archive efficiently.

At its worst, the author writes an unreadable polemic without any thought of the audience. To the writer, their point is clear, obvious, and unarguable. To the reader, it’s a muddled, angry rant. The readers then type their own polemics in response, disingenuously cherry-picking and taking phrases out of context. And on it goes.

Not all written conversations look like this, but a lot do.

I wrote an article (since it's written, I don't expect it to be actually read)[0] , about the importance of not writing too much stuff down (Ironic, I know).

I call it "concrete galoshes." The structure can become more important than the project.

That said, not having a structure can be absolutely deadly. It's not for the faint of heart.

I seldom write down a detailed project plan (I write about that here[1]. Feel free to not read it, as well). Instead, my projects start with what I call a "napkin sketch," and evolve, as they progress. The results can be amazing, but I also end up backtracking a lot, and tossing out a lot of code.

I feel that you can't work the way I work, unless you are highly experienced (I've been at it over 30 years). I make big decisions, on the fly, and I need to have a really clear idea of the ramifications of these decisions. Often, the devil is in the details. It's quite possible to decide to do something one way, and get there, and then realize that a corner case makes the design unusable, and/or downright dangerous.

I'm not a fan of "design by buzzword." Modern techniques are often marvelous, but they can be unsuitable for some applications. Having a toolbox available, that includes a wide range of options, is invaluable.

I am a fan of early, high-quality usable product. One of my techniques, is to leverage Apple’s TestFlight beta service, as early as possible. This allows non-tech stakeholders to have meaningful say in the project. Screenshots and interaction diagrams are fairly useless. They take a lot of time (and expense) to create, and no one reads them. They also tend to add unproductive rigidity to the project.

[0] https://littlegreenviper.com/miscellany/concrete-galoshes/

[1] https://littlegreenviper.com/miscellany/evolutionary-design-...

> I seldom write down a detailed project plan (I write about that here[1]. Feel free to not read it, as well). Instead, my projects start with what I call a "napkin sketch," and evolve, as they progress. The results can be amazing, but I also end up backtracking a lot, and tossing out a lot of code.

This is fine for a sketch, a prototype, or an exploration. If you do this to produce production, critical path code, on a professional team with others you're selfish:

- The team, not only you, maintains this work that they have no agency over.

- You skipped feedback loops, and ignored the expertise of others.

- You've removed information sharing and visibility as you go into your cave and come back out with a solution.

> I feel that you can't work the way I work, unless you are highly experienced (I've been at it over 30 years). I make big decisions, on the fly, and I need to have a really clear idea of the ramifications of these decisions. Often, the devil is in the details.

Yes, the devil is in the details. Get some feedback from other people and stop designing by mistakes I happened to notice and catch. The ones you didn't notice? They're bugs your teammates fix.

> you're selfish

Thanks for the insult. I appreciate the feedback.

I'll do me. You do you.

Have a nice day.

Everyone that works in development is literate but not everyone that works in development has good reading comprehension or is good at generating meaningful prose at a keyboard. Many people who work in development just don't like to read and consider it a chore.

I think an interesting interview question would involve reading. "What were the last 3 things you have read to learn something?" "Do you read for enjoyment?" Based on the results you could group people in terms of how they relate to text.

In my experience a key characteristic of a good software engineer is their ability to handle dense, technical texts. We do it all the time, from academic papers (less often) to documentation (every other hour). Not liking to read (?!), and thinking it's a chore, because we're only humans, will mean you won't do it unless forced and will either lack a deep understanding of a subject or reach for someone else to do it for you (RTFM).

Not a fan of the often repeated, flawed [1], "we have different modes of learning" mantra that sometimes comes with these discussions too. That myth is so hard to debunk likely because of this very issue!

1 - https://www.theatlantic.com/science/archive/2018/04/the-myth...

> I recommended them some articles

I have a slightly cynical take on why most programmers don’t read much: you can’t log “reading” into a time tracking system that has to add up to (at least) 40 hours a week.

You can log it under ‘working on project xxx’? Literally all my time regardless of what I do goes under there.

I guess it makes a difference for consultants, but they can log it under unbillable ‘administrative actions’ if the very necessary ‘continuous education’ does not exist.

If you have time could you reference your favorite posts on the Amazon 6 page memo?

I found this article on it: https://writingcooperative.com/the-anatomy-of-an-amazon-6-pa...

Because most documents are not written to be read. The are written to have something published. Ego, status, whatever. Similar to over architecting.

Spend more time making things more concise, and people will read.

Evidence: tiktok and other shorts

Oh! We work in the same place! Or at least close enough that it doesn’t matter what the actual name is.

>One group really prioritizes synchro comm for "emotional nuance" etc. The other group prioritizes written text's dense information content and searchability.

Don't forget the usefulness of email when you need the ability to reference past conversations. For some people, a faulty memory is a finely honed art.

I bet this is exactly why some people prefer direct communication that doesn't leave a trace ;)

I agree. Every time something important starts getting discussed, people want to jump in a video call so every history is erased afterwards.

That is a cynical assumption. I think in most cases, people don't want eternal back-and-forth that can happen with emails when it can make sense to have a single conversation where the objections can quickly be noted/considered and the subtlety can be understood.

Of course, in some cases, this has disadvantages but like most things, we should avoid making such absolute statements and allow intelligent people to work out whether written or spoken is a better idea for each topic.

that's why I send around meeting notes regularly. THEY hate it.

I stopped doing that because people take it the wrong way. Initially, I was just trying to be helpful with the notes (so people wouldn't forget what was discussed, people who could participate could catch up, etc). But I started noticing some people were looking at the meeting notes as if I was holding a gun at their heads for what they said during the meetings.

>But I started noticing some people were looking at the meeting notes as if I was holding a gun at their heads for what they said during the meetings.

My experience (as technical resource/lead and project manager) has been to make sure that meeting notes include all agenda items and the action items associated with them.

However, I always make explicit that this is my understanding and request feedback from all participants as to the accuracy, schedule and scope of action items.

I suppose that comes from long experience where you're given responsibility for ensuring the success of an effort/project but not given the concomitant authority to compel action.

That requires consensus building and buy in from all stakeholders.

Often, that's not an issue when the entire organization is focused on a singular product/service. But in large organizations, building consensus among the stakeholders is absolutely necessary for success.

In smaller organizations this is less of an issue, as someone with authority over all aspects of cross-functional efforts is likely directly involved.

As such, the metaphorical "this is going to be done. Do it now." coming from a person who can directly affect your compensation and continued employment is extremely effective.

That's not so in large organizations where authority is more broadly distributed.

It occurs to me that differences in the size and structure of an organization can have significant impact on how such processes evolve and either thrive or die.

> some people were looking at the meeting notes as if I was holding a gun at their heads

Ok, so… I’m usually super cynical, but how do you know you’re not projecting here? I know people that do this and as far as I can tell, they’re always appreciated. More commonly I see people ignoring those summaries than being threatened by them.

It doesn't have to be "in your face" but it has to have the main points and especially the future action items people are taking

It helps to screen share your notes so everyone is on the same page of what is written down which keeps everyone from "exaggerating" in the meeting and being later on surprised about that what they said is in your shared notes.

I like it. I can’t be in all meetings all the time, but I can read all the meeting notes and follow up if I have to.

Unfortunately, nobody sents any meeting notes, and they decide things that later get cited as ‘it was decided’, and I have to track back through history (and a lot of unwilling people) to figure out that ‘it’ was decided by two PM’s having a meeting at 12am with nobody relevant present.

Who then tell me to be in meetings if I want to have any influence on their decisions.

Meeting notes can easily become noise. One of the big dangers of meetings is spending lots of time talking and not making specific actions to make something happen. Instead of minutes, it would be better in my opinion to put any relevant points into the relevant tool: Trello, Jira, Teams Tasks or whatever gets used.

It's then easy to continue working with, if you are a bit wrong, you don't need another email with corrections, someone can just edit the task details or add more to it.

If I meet with people over a jira ticket, the notes will go in a comment on that ticket, etc. this is not a contradiction.

Also, I don't think that most meeting notes will or should be read in the far future, but I think they are invaluable to keep the bullshitting at bay.

Probably also depends a lot on your work context. I work in a large corporation, so a lot of time is spent negotiating between departments and the culture isn't very much trust based which is totally different from my previous job in a very small company where essentially social control to be honest was a lot higher.

I like both and I guess many people, too. But it depends on the people involved.

I think the big advantage of text is accountability.

Lots of people say lots of things (the other person wants to hear) ... and remember only some of it. I wasted so much time relying and then discussing forgotten promises, where I wished have had that exchange via text. And I actually believe, this is a big (unconscious) reason for many avoid written communication. Talk is cheap.

You’re totally right here. People want accountability because they want to increase honesty, which is obviously a worthy goal. But sometimes it backfires.

If I’m going to be held to account for everything I say in a meeting, I will be more careful about what I say and how I say it. That sounds like a good thing. But I think out loud. I voice opinions that I don’t necessarily hold to encourage others to voice theirs in a free-thinking conversation. People’s immediate feedback allows me to rapidly change my thoughts - asking for short bits of feedback is normal verbally, but laborious in writing. Also, when writing, I self-censor ideas because they sound wrong - but someone might have taken inspiration from one of those wrong ideas and corrected it.

The best medium in which to have a conversation thus depends on the participants, context and intent of that conversation.

Agree with this - and the other thing is subtle but it’s about trust.

If I am documenting things on emails just to create a paper trail for accountability, something about the culture in the company has probably gone awry and it means there is a lack of trust between people.

Documentation shouldn’t be a substitute for honest feedback and ensuring everyone does what they promise. (I’m not saying that tracking actions isn’t a good thing to do - but my primary purpose is to help people remember what they said rather than to hold them to account).

"People’s immediate feedback allows me to rapidly change my thoughts - asking for short bits of feedback is normal verbally, but laborious in writing. "

But that change of thought would be included. Important is, what everyone agrees to in the end.

Also, keeping track of the back and forth is useful for credit assignment later.

Why do you need “credit assignment”?

In those cases, someone claimed a idea as his work, when initially he opposed it.

If the culture you work involves people competing for credit, you've got bigger problems.

> Some employees prefer not to communicate that way.

I think it depends on the purpose of the team as to whether people should change.

I’m technology, if the purpose is to build things well then the people who like to emotionally nuance things in synchronous communication should do more async because that works better for building.

It really frustrates me when I analyze a problem, thoughtfully write up a solution and send it out. And then someone (or several) wants to meet to talk about it.

Then the meeting has nothing persistent than a feeling and the details get lost and a week later people forget the resolution. And want to meet again.

I guess if there’s no accretive development it doesn’t matter, like sales or restaurants or whatever. But there seems to be a better way to design and execute complex things.

> the people who like to emotionally nuance things in synchronous communication should do more async because that works better for building.

Citation needed. Pretty much everything of any complexity that has been built to date, in human history (including software), was built with synchronous communication (not to say things aren't written, but things are ALWAYS discussed).

> Pretty much everything of any complexity that has been built to date, in human history (including software), was built with synchronous communication (not to say things aren't written, but things are ALWAYS discussed).

What about open source projects like the Linux kernel and git? As I understand it discussion primarily takes place on the mailing lists, which are, by their very nature, a form of asynchronous communication.

Let me clarify, I’m not saying that we should never synchronously communicate, but that it is not the sole or primary communication.

My comment was about the tendency to avoid writing over speaking. I think we need lots of writing and some speaking.

Software in particular is easier to “say it in code” than to just talk and talk and talk.

I’d say my preference is write-up, then talk, then follow up with write-up.

My complaint is the constant redirection to only talk and never write up.

I agree, this is my experience as well. At the extreme ends, some people absolutely require synchronous communication / social interaction to be productive, while others' performance (and sometimes happiness) depends on the absence thereof (often perceived as inefficient or even a waste of time). They are inherently at odds with each other.

Personally I fall into the latter category and I do believe it's a better fit for a software engineering role in terms of getting things done, but I've also come to the realiziation that in our world, you'll eventually have to meet the others half-way. Hiring a team that shares the same communication style is often just too difficult (exacerbated by the fact many candidates aren't even self-aware enough to know which preferences they really have, or don't want to admit them).

I think we should nuance that a bit. Personally I'm an introvert, and naturally fall into the latter category like you. But at work, especially for management and direction, I find synchronous and social interactions way more efficient, allowing higher level discussions and vision and necessary to really move things between teams company wide. Written asynchronous communication seems more fit for intra team work, i.e. solidifying processes when the direction is clear.

This is a great summary and would also explain the tendency to want to meet in response to a thought out document. The author has wrestled with the topic long enough to write out a specific document. The receiver of the document has not yet spent this time, and needs to understand broad outlines. Besides this, if there is a meeting of equals, they might bring something to the table, the author hasn't thought about, or did but dismissed it for undocumented reasons. Let alone the buy in factor of a shared product vs 'you go build this, off you go'

I hate meetings for looking busy, but a 20 minute conversation can bring a week of work to actually implement the decision.

> The other group prioritizes written text's dense information content and searchability.

I would add that the other group also likely prioritises focus, flow, blocks of uninterrupted time for deep work and minimising context switching. For me personally the text-based content and searchability is way down the list compared to keeping the focus on my core tasks.

I think there is quite a lot more the author could touch on regarding the huge overhead and performance hit of context switching and the absolute importance of protecting your time against non-urgent interruptions if you're doing any kind of deep work. Makers vs managers schedule stuff. And yes, even managers should be doing deep work occasionally (I would argue often).

"focus, flow, blocks of uninterrupted time for deep work" is always going to be relative and a function of the company/work itself, rather than communication method.

I like a video call because I can block out that time and get the communication over, rather than struggling to discuss something over a longer period of time over async text chat.

Of course this just goes back to the grandparent's point - its all subjective and depends on how the individuals and teams work. There is no One True Solution with how to communicate as a team.

> I like a video call because I can block out that time and get the communication over, rather than struggling to discuss something over a longer period of time over async text chat.

Yep that's a fair point. I guess it depends on whether the nature of the communication is operations based or project based. For day-to-day operations where you may get lots of small queries and messages throughout the day, I vastly prefer text chat for this as opposed to someone calling me every 5 minutes, or sending a tonne of separate emails.

For more structured meetings, project planning/reviews etc. then I totally agree that blocking at the time and having a call can be a better way to do it.

This seems about right.

Personally I dislike getting on calls for stuff. I think the clarity of text is much better, and the fact that it’s asynchronous means I can look things up while responding, meaning my responses are more high quality.

It’s super frustrating being like this and then interacting with people who don’t want to write things out clearly or don’t want to read my responses, and then ask me to “hop on a call”.

'Can you talk me through this document you sent me'.

I might have limited my career progression briefly when I asked if they had read the document, then called them out on the lie - 'was the 2 paragraph summary at the start not clear'.

I now put the summary in the email body as well, apparently it is easy to miss the heading Summary.

"apparently it is easy to miss the heading Summary."

It is, when you are not paying attention, because you are busy with lots of other stuff. So putting the summary in the email seems lile a working pragmatic approach.

Allegedly they read the document, but somehow they didnt see the section at the start titled summary.

It was a lie - they didnt read the document, I was busy is the dog ate my homework level of excuses. If you are taking home 7 figures you should probably brush up on your excuses.

If you have time to ‘hop on a call’ and discuss things you are clearly not busy.

It’s almost like your busyness is paramount and the other person may never be busy in case you need to quick-question them at your whim.

In that case they will be so busy that they are not even able to read the summary in the email. Busyness is an excuse.

You're absolutely right. That's why many companies will have weekly team calls and then someone will write down a transcript and email it to everyone. It's the best of both worlds, because you can react to emotional nuances, yet you still have an email that you can search for and re-read as a reference later.

People get very confused when it comes async communication. In fact I have opted to stop calling it asynchronous communication and instead just talk about individual aspects of it and the benefits of those aspects in an applied manner at my company Over time you can slowly build people up to your level of understanding.

If you are not a team lead or similar you are fighting an exhausting and losing battle. If you are in a lead position then you have the power to show others by focusing on your own team and getting your team on that level via coaching them multiple times per week. That said, without commitment from your manager or peer teams it will be extra hard even as a team lead.

PS I'm in the coaching part right now with my team and have stopped calling it "asynchronous" communication.

>and searchability.

This can be achieved with meeting notes. These can even be posted "publicly", potentially in a cleaned up form, in a wiki so future employees see them unlike an email chain.

> future employees see them unlike an email chain.

This could also be done by using an internal forum or NNTP server so that those discussion threads are available to those who weren't present at the time.

I agree with your point, but I also think more nuance is possible in structure.

For me, sync and async are good for different kinds of things. So I think a good distributed team needs to get at least decent at both and uses them when they fit. We all know the horror of a meeting that could have been a memo. But we also know the horror of the interminable email thread that should have been a quick discussion.

Reply on news.ycombinator.com