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

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?

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.

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.

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

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.

Thanks for the insult. I appreciate the feedback.

I'll do me. You do you.

Have a nice day.

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.

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

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.

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

Evidence: tiktok and other shorts

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.

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.

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.

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.

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.

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.

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

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.

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

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.

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.

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

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.

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.

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 hate meetings for looking busy, but a 20 minute conversation can bring a week of work to actually implement the decision.

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

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.

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.

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

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.

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.

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

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.

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.

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.