Where I work (backend software development), we do video calls and meetings all the time. Probably an hour every day or more is spent in direct contact. I see this as absolutely essential to get people on the same page - but none of the reasons that people have listed in this thread for why people prefer personal meetings apply to me. For instance, I am extremely grateful if someone writes up meeting notes, I read text documents all the time, and I often require continuous uninterrupted time and respect it in others, and I still prefer voiced meetings.
I think the primary reason is if I am trying to clarify an idea for a design or an approach, I will go to the people who have also touched that field of difficulty, and try to explain what I am trying to do to them in advance. The spoken medium in that case gives room for interruptions, immediate elaborations and feedback. A write-up either convinces or it doesn't; it can be edited but it has feedback cycles on the order of tens of minutes to hours. Spoken communication has feedback cycles of seconds, so even if I was going to write something up, I'd talk it through verbally first, anyways.
I made it through most of my career thus far, including pretty senior positions, where probably most of my days didn't have a formal meeting. It's been so strange to move to a big tech company where I could spend 30 hours per week in meetings if I was not pushing back.
Any they're all 30 minutes. What the heck do you expect to accomplish in 30 minutes? You spend 20% of the time waiting for someone to show up.
You don't have to spend 20% of your time waiting for somebody to show up! That's an organization culture issue.
For the daily team coordination meeting I run, we had a problem with that. So after one especially egregious delay, I asked how people felt about that. They didn't like it, of course. I then said I wanted a consistent start time, but was open as to when it was. At the hour? 1 minute after? 5 minutes after?
To my surprise, they picked 1 minute after. And everybody has stuck to it. A couple months in we'll occasionally have somebody turn up late, but the meeting starts without them, so they know not to do it again. It's great!
We also build an agenda on the fly, keeping the pace brisk. Usually we finish a few minutes early, and sometimes the meeting will be a zippy 10-15 minutes. It's possible to have good, useful meetings!
Funnily enough, my zippy meetings are the ones where an agenda, or at least a boundary, is set out in advance. Oftentimes we allocate more time than is needed to discuss, so we call it off the moment we're done instead of filling the time.
Part of this is because I'm also fine with interrupting and telling people to take something async if a group meeting is becoming a hyper-specific 1:1.
Soon enough, meetings remain direct and rabbit-hole free. Unless the entire purpose of the meeting was to collectively burrow into it.
All it takes is a little discipline, and clear expectations.
I'd suggest you read about managerialism, our reigning business paradigm. Spender and Locke's "Confronting Managerialism" really opened my eyes. If you think of management's purpose as making the business better, there's a lot that doesn't make sense. But it gets clearer if you think of it as caste dedicated to both individual and class power and enrichment, who also try to keep the business on the rails enough that there's something to have power over and extract money from.
Not that all managers are bad or anything; plenty of them are people just trying to get things done. It's a structural problem.
I think we agree. For me, the daily team coordination meeting has a clear initial agenda: go through each work-in-process item and quickly discuss it.
But that tends to spin off longer discussions, and there are often short things people want to raise with the team. So after we've gone through our kanban board, we'll have an optional period called "post". Long items go into Zoom chat as "Post: thing to discuss" and we give a few minutes to each.
I totally agree with blocking rabbit holes. Things that interrupt the fast run-through of the board get booted to post. Items there that are longer than a few minutes get booted to async or a topic-specific meeting, generally a smaller group than the team meeting.
One other trick I recommend: rotate leadership of the meeting once people have the hang of it. I ran mine myself for the first couple months. Then I ran it every other week, with somebody new swapping in. The weeks when people are responsible for keeping the meeting on track make them much better participants when they're not in charge.
Before everyone kind of expected ~3 minutes of lateness to be the norm, dependent on elevator and stairway congestion. And god forbid one person is traveling from another meeting in another building a bit of a walk away.
Tons of meetings are just fine with being 30 minutes. And even if we schedule something longer we should expect to give people time back if we don’t need the whole thing.
Way too many 39 minute things get scheduled for 60. While there logistics issues at physical events with multiple tracks I feel most conference talks should be 30 minutes too.
I'm a team lead and most days I'll have 1 maybe 2 meetings at most, but having 0 isn't unusual. Is that weird? I do talk to people on teams all the time though. I know what everyone is doing and how they are doing, just without having a voice/video call. We just text most of the time - I can be in 10+ ongoing conversations at the same time.
It’s culture thing. Personally, I prefer in-person or video meetings because it’s an event and people are usually focused on task. One on one calls are great too.
Text is good or bad. It’s an attention thief, and you never know what you are getting. Also, I find that platforms like Teams are great for the present, but awful for history and context.
In my experience 90% of meetings with more than 3 people are irrelevant to my work. Here's a couple examples:
"Standups" that are really PM status calls that constantly go down rabbit holes. My update is 30s or less, but the meetings are always 30 minutes long and usually run over.
"Code reviews" that are really run/monopolized by one person. The entire team is required to attend even if you have no code, but in practice no one other than the runner is allowed to provide feedback.
I've noticed a similar pattern at $JOB - we started doing a daily "WFH status call" in early April last year. There was nothing like it previously, just a weekly report on important bugs, support items, etc. that we worked on. And the occasional (less than weekly) meeting which would include the PM and dev team.
The calls started out shorter but over time they've become a hybrid of:
- "Here's the outlay for today." The shortest are just this which only happens when things are going smoothly and everyone's tackling things of moderate difficulty.
- "Here's something that's been giving me trouble" which prompts a few minutes discussion. Usually someone has a idea to pitch in which gets the person unstuck, but it can bleed into...
- "I wanted to bring up this thing I noticed" which pulls us into a bigger half-hour discussion with some possible followups scheduled with the more senior members.
So at the extremes, any given instance of this meeting could last from 10 minutes to 45 minutes.
We usually refer to this as a "stand-up" but I could see how someone from a more regimented team would understand it to be something with a more tightly defined purpose.
Seconding the other comment on not waiting for people. As soon as the clock changes to the start time we are beginning the meeting, and we're not catching anyone up if they're late. They can figure it out.
Obviously this gets a little slack if you're a super senior position (nobody's telling the company President they're not circling back on something already discussed) but for the most part meetings are much more efficient if you're absolutely ruthless with the clock. It's literally the only thing that nobody can control.
On the flipside you have to be equally ruthless about not going over time. At 5 min before the scheduled meeting end time we start cutting off discussions that have become circular and start determining if we need to have a follow-up or clarification meeting for something. My biggest rule for this is that it can't be the exact same group, you'll just end up having the same meeting again. These follow-up meetings are most effective if it's a subset of the original group trying to clarify some specific point.
30 minute meetings can be useful if you stick to these rules.
I haven't timed it, an hour may be off. Call it two for safety. We generally orientate meetings vaguely around mid-day. Having a flextime schedule helps, because some people only show up an hour before lunch so you can't plan meetings for the morning anyways.
That explains a lot of things though. It sounds like most of your meetings are terrible. Actually, if most of people's meetings in this thread are terrible experiences, that seems like it would explain their sentiments. In other words, meetings are mostly time loss, which you're of course trying to minimize.
(It really helps that we have a culture of "I don't think I can contribute to this meeting, I'm gonna head out.")
Almost all of my in-person meetings are technical debates - or group debugging sessions, where progress depends on randomly noticing something. In both cases, they scale well with number of members up to a point of four or so, where adding another participant generates more ideas than it costs time.
>they scale well with number of members up to a point of four or so, where adding another participant generates more ideas than it costs time.
That's the main thing I come across. Most meetings are well over four people. And personally, I already don't deal well with more than 3 people as most people work on a vastly different wavelength than myself.
Now consider all the "Agile" meetings are already 5+ people and often contain management types and people who are both higher on the chain of command and have no technical background either hogging the attention. Suddenly, most meetings I see become either a hybrid announcement + roll call, a "meeting" with ulterior motives (e.g. managers trying to measure "participation" as a way to grade employees) or a very rushed design-by-committee approach to solving something.
I dislike when management decides to join a technical meeting randomly and then spends the whole time being confused and trying to get folks to explain something to them. It’s happened at every place I’ve worked so far.
For the record I’m not saying they’re unintelligent, it’s just that explaining something like how a kernel module actually works to someone who doesn’t know what a kernel is tends to put a damper on the meeting if it takes 30+ minutes.
A previous boss was like this. Couldn’t avail himself for any of the status updates when I tried to-dutifully-keep him informed on project status, but would then show up to my team planning meetings, be confused, or get upset when he found out we were either not where he expect us to be in terms of progress, or that a minor decision was made among the group that he wasn’t roped in on (but doesn’t require senior management approval or consent)
Meanwhile in my “Sent” (aka “CYA”) folder…you can guess where this is going.
Meeting sizing is a good point. It feels like adding additional people is often done aggressively but thoughtlessly, so maybe the solution is to have a company-wide rule to counter-balance that tendency.
If voice/video meetings could have no more than 4 participants unless (insert somewhat burdensome exception process), all participants would presumably consider more carefully who should be added.
A more flexible rule that also might help a little would be to require a separate justification for the use of time to be filed for every single invitee.
It's just like of the signup process on your landing page. Make things you want to happen as effortless as possible -> make things you want to happen less more effortful.
In an evil afterthought: If people still keep inviting to many others to meetings, make the filing of the justifications only possible using a special intranet page, and make your least capable intern code that page. That should sort it out. }:->
We typically accomplish everything we need in less than 5 hours of meetings per week. Most of our engineers get to spend nearly all day actually writing code.
An average week is 2.5 hours of "core" meetings
* 1.5 hours - 30 minute "standup" 3 days per week. Skip the BS status updates. Planning, team discussions, etc all happen in this timeframe.
* 30 minutes of retro (1 hour biweekly)
* 30 minutes of 1:1
We generally keep planning meetings pretty light. A _really_ heavy week will be 10 hours of planning. A light week will be 1 or 2 hours talking about an upcoming feature.
Everything else happens by individuals, asynchronously.
Where I currently work, we're only doing standups every other day. It's usually around 45 minutes, and most weeks, that's the only scheduled meetings we have! Then of course if I or a colleague need help or want to discuss something, we'll have an impromptu call for it as needed.
And this ain't no startup either: EA DICE can probably safely be described as a rather large company these days..
Of course, it might well be different in other teams, being a backend web developer I'm part of a somewhat unusual team in the context of a gaming studio.
95% of all substantial corporate meetings would be vastly, vastly improved if someone wrote up some dot point notes of said meeting, and circulated the document as a courtesy.
In my time in the workplace I've seen this done in maybe 5% of meetings. The entirety of that 5% involved team leaders having a regularly scheduled catch-up with our divisional overlord, and I sat in or saw the memo.
Why don't these very basic things that would vastly improve productivity take place?
Garden variety laziness.
Unless you get over that very basic hurdle of couldn't give a damn, what's the point of all these other solutions?
Laziness situates the problem in individuals and as a deep characteristic, and I think neither is true.
Normally when I see ineffective meetings and missing communications, it's an organizational culture issue. The number one cause I see is what the Lean people call "overburden". I know somebody who was a big fan of circulating notes and tried to bring that practice to a new job. But they ended up giving up because a) bosses put too much on their plate to have the time for that, and b) everybody else was overloaded enough that they wouldn't read the notes anyhow.
That of course means everybody has even more work now, the work called "failure demand". Extra meetings. Doing the wrong work because of confusion. Dealing with delays trying to get information not communicated to them. Etc, etc. So good meeting notes become more needed and more difficult to adopt.
In my view, all of this is driven by not getting another Lean concept: push systems vs pull systems. [1] Work is not driven by actual demand and capacity limits, which is how pull systems work. Instead managers jam requests into the hopper with little regard for capacity, causing all sorts of downstream pathologies.
So if we want to actually fix this, we need systemic change, not individual blame.
I have been writing minutes, action lists, sharing documents meetings, 95% of people don't care and will come back to you a week later with a different opinions than what you agreed during the meeting, better, they'll pretend what ever despite written evidence.
Corporate world is a shit hole where the only thing that matter is the opinion of a decision level breaker (escalation point) .
I'd argue written notes / minutes do help in a toxic culture.
I've had the obligatory interactions with a few backstabbing and/or passively aggressive teams, and when things eventually explode and work their way up the leadership chain (hopefully to someone with more sense), it's a quick knife through "you said / they said" to produce a written document from a meeting 3 months ago, where the assumptions you've been operating under were agreed to by the other team.
Obligatory: producing said doc in this context makes you an asshole, and is a nuclear escalation. But some (rare) times call for that.
(If it's a habit, you should probably reflect on yourself and/or find a healthier place to work)
In my (thankfully limited) experience it was around responsibility and methods of escalation.
My read was that a team didn't want to be bothered with something, but I was working on a corporate priority, so we set a meeting, hashed out, and agreed on how issues should be brought to them.
When something happened down the road, the agreed process was followed, and they (surprisingly stubbornly) claimed they weren't responsible and shouldn't be contacted for this issue.
Typically scope of a project: feature x and y are agreed to not be included but two sprints before release they become a must have, because otherwise Sales suddenly cannot sell the product.
Do you have some tips on doing good writings? It's something I'd like to improve on but I haven't seen it done really well so far. If you have any recommended resources for learning more, I would be interested to dig in.
"In my time in the workplace I've seen this [notes] done in maybe 5% of meetings"
I go a step further. If it isn't on the agenda, we don't cover it. Just "spit-balling" or talking about things that are clearly not researched is a WASTE of everyone's time. If you want to talk about something, we want to take 10 minutes and research it too. Put it on the agenda and be prepared. We don't want to be ambushed into stupid decisions. "Let's use mongo!" out of no where is pointless and stupid. So that 95% can keep their unresearched ideas to themselves. Thanks. Personally I live by this quote: "Every stupid meeting starts with no agenda." NO agenda? Even better, meeting canceled.
Right, and we do do that for decisions that affect more than the people involved in the debate. However, we also have a wiki, and so anyone can look at it and see how a habit of writing things down decays - because people may write it, and read it, but nobody maintains it or cleans it up.
The only worthwhile document is a document with a clear owner that is routinely updated. This does not scale beyond a few pages per user.
When you talk to someone, you get their view at this point in time. You don't accidentally get their view five years ago which they've since revised; you are guaranteed to get, if not the accurate version, then at least the current one. When you talk to multiple people, you even have a chance to get the correct one. Notes cannot defend their argument and so must be taken on faith - or else to confirm your understanding, you end up talking to someone anyways!
In code, the best documentation is the test, because it must be correct. The second best documentation is a comment, because it's right there and hence hard to miss. Third is an external specification referenced in the README, because they generally change much more slowly than the code. Distant fourth is a self-written document in the same repository, because after all, how do you notice that something didn't change during review?
And I think this is somewhat the original talk's point: if the superiority of a given method is predicated on things happening (which rarely do) or things not happening (which often do), then it might not be superior.
If TDD is superior if leads write tests, but leads rarely write tests, then is it superior?
If meetings are superior if everyone shows up on time, prepared and generates documentation of the meeting, but nobody ever does those things, then are meetings superior?
Tl;dr - Be honest about your team's reality, and choose the optimal option for that reality.
Today many meetings have the form of a brainstorming, like totally agile you know. I think for meetings to make sense you should have a clear agenda and notes about the outcome, possible action etc. For the modern workplace that's probably too old-fashioned.
90% of the meetings that are landed on my calendar don't even have so much as a unique subject or a one-line description of what the meeting is about. Most usually, the scheduling party reuses an old invitation, so any information in the invite body isn't accurate anyway.
They're usually sent to me sometime after midnight, EST, for a meeting at 9 AM. When I did go to the office it wouldn't be uncommon to hit some traffic and arrive to find out you've already missed a meeting you didn't know about. If you did make it in, you were immediately ambushed with an angry customer who doesn't understand timezones or business hours.
At the big companies I've been at, it's because no one (myself included) will read them. Sure, they'll read them at first, happy to get back the 25 minutes. Then new meetings will replace that time until it cascades into a series of low-signal notes that are infeasible to keep up with.
Similarly, I've seen so many folks in leadership that get the feedback of "the engineers on the floor have no idea who you are, what you do, or why this re-org matters". The solution? Publish a biweekly newsletter about what they and the rest of the org does - that cascades with every other level of middle management doing the same. All getting filtered into the same unread folder, leading to the same feedback as before.
This is the kind of lazy non-explanation I was complaining about in the recent HN thread on "laziness doesn't exist". There are people who have perosnal incentives and counter-incentives, they work in groups which bring their own incentives. Things like:
- Socially, writing up notes and sending them out is often seen as secretarial work, women's work, low status work. People think their personal interests are better served by taking high status tasks, not low status tasks.
- As well as being a low status task, it could be seen as trying to usurp your manager's authority, if you want to be the one sending out "here is what we decided and who is going to be taking followup actions".
- Socially it could be "goody-two-shoes" behaviour if you weren't asked to do it, and lose the respect of some people.
- Socially, if a coworker got lumbered with a task nobody wanted, they might resent you sending an all-hands email "gloating" and making sure everyone knows about it, or you fear they might.
- Writing memo notes invites you to open-ended future scrutiny if anyone thinks the notes unfairly represented what they said or their participation. Coworker who thinks management is getting an unfair view of their contribution because of your biased notes, for example.
- There are power imbalances and adversarial relationships among people in meetings; writing memo notes may be seen as "I'm going to write down what you say so I can take it out of context and use it against you" or in an "I'm going to hold my seniors to account" way. Maybe some things in the meeting are spoken, deliberately so they are "off the record".
- If you think the notes will not be read, writing them feels like pointless make-work.
- It misunderstands the purpose of meetings as "productivity" when they are often for avoiding blame, feeling important, or pushing something back and forth because the people in the meeting don't have the authority to make the decision(s) which need to be made.
- If the company sees meeting records as important, it should be explicitly someone's job. If it's not someone's job, the company doesn't value it, so why should you? In the YosefK "Employees can read their manager's mind"[1] sense, employees are not there to make the company productive, they are there to make their managers happy.
- If meeting memos aren't regularly taken, and you want to start, you face all the possible problems of trying to push a change into an existing system and people's reluctance to change no matter what the change is.
- If tasks are assigned in the meeting, they should go into wherever the teams track work, not into generic forgettable group emails. If decisions are made, they should be logged in whatever documentation logs decisions, not generic email. If those are done the memo is redundant.
There are only a couple of quick ways through this, the first is an enthusiastic junior who wants to be seen to be helping and has little to lose because the worst case is a manager asking them to stop. The other is a high-status employee (socially, e.g. wealthy white male, contractor, friend of the boss) or organizationally (e.g. senior title, manager, leader) secure in their skills and life who have respect and can damn the consequences - although they would be more likely to use their power to skip the junk meeting or have the memo taking task assigned to someone less busy. For everyone else, all changes have risks, especially ones which include increasing your visibility while making the implied statement "you weren't doing things properly and I have a better way".
These things which really exist and do bother people casually dismissed as "garden variety laziness" is, I repeat, a lazy non-explanation.
> "95% of all substantial corporate meetings would be vastly, vastly improved if someone wrote up some dot point notes of said meeting, and circulated the document as a courtesy."
Has anyone tried putting at the top of the summary something like:
Meeting cost: 4 work hrs (8 people x 30 mins)
to draw attention to the fact that meetings aren't free, and put the decisions in context of how much it cost to get to them?
You're probably getting downvotes because you said "ticket."
Which speaks to another problem with most large company cultures: ticket shoveling. In a healthy company, every ticket should receive one of three outcomes.
(1) I can fix this, I work the ticket to completion, then request verification it's resolved.
(2) I cannot fix this, but I know someone who can. I add context if needed, forward it to the appropriate person, and stay appraised of it and available until it's completed.
(3) I cannot fix this, and nobody I know of can. I list out reasons why this cannot be fixed, and give any information I might have about alternative contacts who might(!) be able to help, and close the ticket.
In most companies, and I think this has been exacerbated by outsourced IT and contractual resolution SLAs, until everyone's internalized it as the way they and everyone else should act, you get something like this.
(1) Is work. This is to be avoided at all cost.
(2) I blindly forward a ticket on to anyone else who looks remotely responsible, to get it out of my queue, and then wash my hands of the entire matter and forget it ever existed. I certainly don't follow up or add context.
(3) I close the ticket without providing any reason why, or information I have about someone who might know something I don't, who could help.
A reliable metric I've come up with for measuring corporate and/or team disfunction is to count how many circuits a worst-case ticket can receive (where a circuit is: originator -> some number of teams -> originator/loop). My record is 3, before someone noticed.
I would like to add another interesting pattern that get exercised when a ticket is work, and forwarding will make it bounce back. You forward only to your IT support team one by one. And each member attempts to waste as much of the requester's time as possible. Each time waster is creative, but usually it consists of minimal efforts in asking question taking maximal effort to answer. Good chance the requester will give up on that ticket before the full team went at it, and would gladly agree to get that closed as remediated. Better live with a problem than a bigger one.
I think this is true too, but I don't blame folks.
I recently started a position which is the first time I ever worked as a non-freelancer. Previously I always wrote documentation for myself and my clients in self contained Markdown files.
But at this new place they use a combination of Confluence and Google Docs for any type of docs that don't necessarily belong in a repo's readme file (like ancillary topics, general knowledge and guides). It's not easy to find stuff unless you already know where to look. Confluence's full text search is also pretty lackluster.
Turns out keeping documentation and knowledge up to date when you're dealing with a handful of folks isn't easy. Especially if you factor in everyone contributing their own docs with their own writing style and patterns. It makes for a pretty inconsistent feel.
> "In my experience, people don't read documents."
I think this is worth calling out for its own discussion. Along with the traditional use of "RTFM" meaning "go away and stop bothering me", any amount of dysfunction in a sytem or company can be tolerated as long as someone has written about it in a document somewhere.
Poor design? Buggy implementation? Complex configuration? Poor defaults? Missing features with inconvenient workarounds? Arduous processes? All fine as long as it's been documented. And any comments about voluminous documentation and "I couldn't find it" become point-scoring "I know where the needle is in the documentation haystack so I win".
And as a user or customer, the last thing I want when facing your system being complex and unintuitive is a mountain of documentation to go with it. That adds insult to injury - you couldn't make a good system and you've made more work for me on top. How often have any of you read some good documentation about the internal workings of a system and left feeling intrigued and surprised and impressed? Occasionally, right? And how often have you trawled through documentation saying things like "to change the username field, simply log into our admin website, click accounts, click usernames, click customize, then download the XML customization file from the available template files, make the necessary changes, and simply raise a support ticket for us to install the new file" ? A poorly designed feature with an awkward process, with parts where detail matters (content of the file) left for guesswork, but at least it's all documented.
I want my intuition (experience) to carry me almost seamlessly through your system, and if it has a short amount of clear documentation which helps me then I'm OK with that. If you want me to commit to trawling through books worth of content to learn things which are your own proprietary lock-in buzzwords around Rube Goldberg kludge designs, I'm not as OK with that.
There's a conflict in what you say. If people don't read documents and will ask when they need something, why invest in creating heavy tickets filled with the text they don't want?
My team (and many XP teams) gets by just fine organizing things with cards that have a modest number of words on them (5-10, normally). When we need something, we ask. It works fine for us. We're a distributed team that has never met in person. But it also works fine for in-person teams: https://williampietri.com/writing/2015/the-big-board/
I called it ticket, you can call it card. I did not say it to be heavy. But should also contain enough info to get started or at least point to the right person.
What you are describing is definitely heavier than what I'm describing.
And I disagree it should contain those things. In the XP tradition story cards (which are conceptually different than tickets, but I'm fine with either term) are tokens for conversations. The more documentation you add, the more it drives people away from conversation. As you say, when people need something, they'll ask. And I think that's a strength, not a weakness.
Our meetings always felt like one construction worker digging a hole (doing work) while everyone else watched. Easily could have been solved with an agenda or someone telling to do the work post and not drag everyone else through the process of making a Jira ticket.
We eventually decided to have a meeting chairman, their job was to make sure there is an agenda and to keep it on topic. They also make notes of tickets that need writing and make sure it's done post. We decided to rotate the responsibility weekly since it's kinda a hassle, but it really helps having someone assigned to keep meetings moving.
We used a spreadsheet to rotate at first, but then found an slack app called tellspin that's been working really well for us. It reminds me a lot like pagerduty has a schedule, overrides, etc. Allows people to move shifts and stuff so the meeting leader role is always filled.
There are two types of approaches to working out a problem. One is to get everyone in a meeting and talk it over until a solution is reached. The other is for a single person to carefully think through the problem and possible solutions, write down a solution, and pass it around for (usually asynchronous) comments.
People who think meetings are really useful thrive in the first approach. The more meetings they have the faster they can get things done. People who prefer the solitary focused approach tend to see meetings as obstructions to progress, because they prevent them from actually solving problems by pretending to solve the problem while not making headway.
Which approach is right is highly contextual, and you can’t really argue it either way without falling back on personal preferences.
> we do video calls and meetings all the time. Probably an hour every day or more is spent in direct contact.
That's not all the time my friend. My usual day is 3-5 hours on conf calls, you gain 'popularity' as your time / seniority at the company rises. I get 50% of my actual work done during those meetings, while others talk in matters unrelated/distantly related to my work.
Video all the time? No, thank you. Our top 10 bank in the world is managing just fine without a single video call since forever. You get used to it very quickly, and the freedom it gives you is magical.
I'm not sure your definition of "all the time" matches anyone else in the industry, quite frankly. At the architect/staff level I'm lucky if I can only spend half my time on the phone or in some sort of meeting (includes the ad hoc group chat where we're discussing something via our internal equivalent of Slack). I get maybe 5-10 hours a week of coding, and it's usually either something extremely challenging that someone else has already spent weeks hacking on, or a super basic bug I grab to keep myself sane and in touch with the nitty gritty code stuff.
An hour a day is junior dev level meeting load at almost every place I've ever worked. Seniors are 2-3, arch/staff/principal 4-6 and managers all day long (all averaged over a couple weeks or so it obviously ebbs and flows).
I do one on one 5-15-min zoom meetings when I need to clarify things that need clarification after 1-2 text exchanges. Super useful to look at the thing together and align mental models in real time.
Other useful formats - look at work together with stakeholders and get instant feedback + clarification questions.
For almost anything else, meetings can be a time waste. Some communications do not require full bandwidth exchange but where tone is important, an efficient meeting can be a timesaver.
I agree with everything you said; but coming from a place where 20 +++ hrs a week is spent in video meetings (and that's after rejecting just as many invites), having only an hr a day means somebody somewhere, whether explicitly or culturally, already set up system and expectation when productive time is respective and meetings are minimized. In other words you are already in a place many of us only dream of :-)
For sure. This bald assertion in the post blew me away: "Working in a distributed team means working asynchronously."
This is just false. You and I live other approaches every day. I believe his way of working is fine for him, and he's welcome to it. But that doesn't justify sweeping dismissal of everybody else's experience.
Did you actually read TAF? They make it quite clear that this is their approach and in no way dismiss other view points. Your post reads like you are just trying to dunk on this article, and its weird.
Bald assertions like that do dismiss other viewpoints.
Yes, he has a header saying, "It’s solely based on my personal experience, and the experience of others I have talked to, watched, or read. Everything I say here is subject to debate and rebuttal, or you can simply have a different opinion."
But he's then stating things dramatically as universals in a way that excludes the experience of others. Not only is it an unpleasant experience for those, like me, who have different experiences, but it also means I can't really trust him to tell the difference between what happens to work for him and what might work for others.
>but it also means I can't really trust him to tell the difference between what happens to work for him and what might work for others.
No one can.
> unpleasant experience for those, like me, who have different experiences
Is it unpleasant being shown experiences that differ from yours? Can you elaborate on this with an example from the text and your own experience? I think it would help me understand where you are coming from if I could relate to it.
The way I see this - you are asking the author to write in a 'universal' style, that respects and acknowledges all view points without preferring one over another. I have two problems with that. 1) it defeats the purpose of sharing your experience and the preferences you have learned. 2) it is difficult ranging to impossible.
I'm not trying to put words in your mouth there, merely give you an opportunity to correct me and my impression.
Of course one can. People do it all the time. Look at medicine, for example. A doctor will write of personal experience with a few patients. But before making sweeping universal statements they'll talk with other doctors, form hypotheses, and gather data under controlled conditions.
Being shown different experiences is not unpleasant. What is unpleasant is having personal hypotheses stated as universal rules when they aren't.
> The way I see this - you are asking the author to write in a 'universal' style, that respects and acknowledges all view points without preferring one over another.
I am not. I am asking to show awareness of the limits of his knowledge. To leave room for the notion that differently situated people will have different experiences. And perhaps be willing to listen to those experiences in order to improve his understanding.
> merely give you an opportunity to correct me and my impression.
I am with you. I spent about 50% of my working days talking to the people I work with. So, so much better than breathing each other's air. And as a bonus, no one is reaching for my mouse and keyboard.
That said, I am not into this guy's shoes. His arguments make sense. I get it but my situation is different, plus I enjoy talking to the people I work with. Well, most of them anyway.
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.
> 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.
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.
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.
> 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.
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!
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.
>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.
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.
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 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.
> 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.
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.
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.
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.
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.
In my experience, many people prefer meetings over asynchronous communication because they can't write. I'm not referring to grammar or to spelling, but to being able to communicate effectively without a continuous feedback from the recipient of the message. When these people are asked to write documentation, the result is usually very sparse text with too many bullet points, table and images.
Good asynchronous communication requires a high degree of introspection, clarity of mind and empathy, that not everybody has. A meeting allows you to pass your message through successive approximations, as in adjusting what you are saying based on the reactions of the listeners and being pushed in the right direction by their questions. Unfortunately it is also much more time consuming, because everybody has to stop whatever they are doing and listen for 1-2 hours, while reading 2 pages of text would taken them 30 minutes and they could have scheduled it at their convenience.
I don't see much of a difference between older vs younger generations nor between native and non-native English speakers.
I'm open to accept that it's just my own experience and that it doesn't generalize.
I don't fully agree. I'm an ok writer, and don't mind writing documentation. But it takes time for me to write a good email. Like you say, you need clarity in your head. So basically you have to clear things out on your own before you can finish the document.
Compare this to a meeting: you just say what you are thinking at the moment. Others might join in and raise points you haven't thought of. So you start from there and readon further. Basically a meeting is clearing things out in a group, which sometimes is more efficient.
I prefer documentation with sparse text and lots of diagrams and images. It provides the high level context and I can fill in any gaps with a short follow up conversation.
For most people, the high level information is all they really need. The few who need to dig in more can hash out the details in a smaller more effective meeting without wasting everyone else's time.
Do you find it easier to learn something new from pictures and bullet points or from a long-form document?
That kind of documentation is not necessarily bad, but it depends heavily on context, which is not always shared across readers. So when the author and those they talked to are not available anymore, it quickly becomes useless.
Don’t get me wrong, I don’t think people should write War and Peace. Usually a good 2-3 paragraph introduction improves the quality of a document/email significantly. There you can provide the context that is necessary to fully understand the pictures and lists and diagrams you add after.
I disagree with a lot of this article because it assumes that we are efficient robots that just need things to be searchable and written down. Tools are also a bit lacking -- in theory writing stuff in a wiki is useful but then try finding the information with, say, Confluence search.
The article also assumes every one is a native speaker who can write quickly and clearly in a chat -- in a lot of international projects this is not the case.
I find that there is less chance for misunderstanding and aggression if you disagree over a video call. Also, human contact and informal communication make life and working more enjoyable.
> The article also assumes every one is a native speaker who can write quickly and clearly in a chat -- in a lot of international projects this is not the case.
You think non-native speakers have an easier time communicating in real time in a video call than through text? A video call is the worst case for a non-native speaker.
(Well, OK, a phone call is even worse. But being synchronous and relying on their ability to understand the spoken language are both terrible ideas if you're concerned about what makes things easy for non-native speakers.)
> You think non-native speakers have an easier time communicating in real time in a video call than through text? A video call is the worst case for a non-native speaker.
Oh yea, I forgot about this because I don't do video/audio calls.
A non native speaker is NOT exposed to spoken english daily. In some countries they even dub Hollywood movies so not even their entertainment is in english. And where movies are subtitled you tend to read the subtitles so you don't bother understanding accents, speech over explosions and stuff like that.
Written english is another thing, if you do programming. There's no point of looking for docs in your native language; the originals are in english and always more up to date.
So maybe the non native speakers have trouble because the OP speaks too fast / has an unfamiliar accent?
>because the OP speaks too fast / has an unfamiliar accent
Here's an unpopular opinion by a hard-hearing person with native English skills: the far majority of people are really bad at verbal communication as a way to transfer knowledge. Doubly so in complex areas. To top it off, I see barely any difference between people in roles that require speaking often and those who don't, except for frequent public speakers.
The reasons? Bad articulation. Speaking too fast. Speaking before you know what you want to say. Complicated explanations. Muttering "uh", "ah" and more. Diversions. The list goes on.
And it's not like the information on how to be a better speaker isn't out there. I can assuredly say the average person in a leadership position doesn't even take 5 minutes of their work day to do vocal exercises. That alone already helps a lot.
Meanwhile, people making informative videos and talks out of their own accord are much easier to hear and understand. The difference is night and day.
I am not a great communicator. I talk too fast, don't articulate my thoughts, start talking before the other person is finished (though I have a pet theory I picked up this habit from my first high-paced tech job working across 9 timezones with Indians =p ).
I am constantly trying to work on this part of myself-for both myself and others' benefit-but have to be careful to not get too anxious about trying to fix my communication.
I really appreciate this comment because I've found that when I talk to (close) friends about this challenge they do not consider communication something that can be much improved; communication style is mostly rigid. This baffles me because it seems like it would doom most bad communicators to a lifetime of bad communicating. This might be exactly how life works, I admit, but its an interesting way of getting to this obvious point.
Where do you recommend someone like me go to learn more about those vocal exercises you mentioned. That does seem like a great starting place.
I'm attending a series of lectures on project management, and the first one was great. I mean, it didn't contain any earth shattering information, but it was paced perfectly.
The second one was surprising by comparison, because while it wasn't that bad, it illuminated all the things that were spot on in the first one. For instance, it was just a little too fast for me to easily type everything on the slides as notes, which I think is approximately the pace at which I absorb information. At the same time, there was too much redundancy and filler so I tended to get lost figuring out where information should go in my outline.
If someone is otherwise a good and prepared speaker, a heavy accent can be adjusted to.
Go a little slower and prune the verbiage a little more seem to me like principles to come back to.
Apart from what you say about exposure (which is true), I'd say that written English is much easier than spoken English for most (if not all) native speakers, for several reasons:
- If you don't understand a sentence the first time, you can read it twice (or as many times as you want), and this very often helps as a non-native speaker - sometimes you misinterpret a word and this throws you off, but reading the sentence again clears the misunderstanding. It also can help deducing the meaning of an unknown word from context, etc. Of course in a video call you could ask the speaker to repeat, but this isn't functional if you do it often, and can make the non-native speaker feel ashamed of slowing the conversation too much, especially in work environments.
- This one only applies to related languages, but it's much easier to deduce the meaning of written words from other languages. Take the word "subtitles" in your text. Any Spanish speaker could infer that it is equivalent to "subtítulos" in Spanish, because it's spelled very similarly (Levenshtein distance = 2). But the pronunciation (/ˈsʌbtaɪtəls/ vs. /sub'titulos/) is very different (Levenshtein distance = 5).
- If you still don't understand a word, you can look it up. Or even hit Google Translate. Good luck with that in a video call.
- Written language is reasonably standard. While there can be some regional variation (color/colour, lift/elevator and so on); you get rid of all the diversity of accents which can be a huge deal for a non-native speaker.
Seriously, speaking as a non-native English speaker (at a quite good level now that allows me to speak quite comfortably, but obviously I went through all the stages of learning...) the difference between texting and phone/video calling when you're a non-native is enormous. The latter is like an order of magnitude more difficult.
> But the pronunciation (/ˈsʌbtaɪtəls/ vs. /sub'titulos/) is very different (Levenshtein distance = 5).
Levenshtein distance between conventionalized IPA orthographic representation is not a useful metric for the perceptual difference between two spoken sound sequences.
> Written language is reasonably standard. While there can be some regional variation (color/colour, lift/elevator and so on); you get rid of all the diversity of accents which can be a huge deal for a non-native speaker.
This problem actually comes up in writing too; I knew some Chinese students who were really offended by English typos. They had a point - lacking the pre-existing knowledge of English that lets me know what a typo was meant to say, they just had no way of finding out what a misspelled word was supposed to mean. You can't look up words that don't exist.
> Levenshtein distance between conventionalized IPA orthographic representation is not a useful metric for the perceptual difference between two spoken sound sequences.
I know. Just wanted to provide some metric for the quantitatively-minded, and because the example is hard to follow if you don't speak Spanish or read IPA, and I don't know any least bad quantitative metric. But qualitatively speaking, I can tell you that inferring the meaning of that English word from the written form is obvious even to a Spanish person with zero English knowledge, while inferring it from the pronunciation it's very difficult. And it's just an example, but it happens with many words.
> This problem actually comes up in writing too; I knew some Chinese students who were really offended by English typos. They had a point - lacking the pre-existing knowledge of English that lets me know what a typo was meant to say, they just had no way of finding out what a misspelled word was supposed to mean. You can't look up words that don't exist.
It can come up, but still, the normal frequency of typos is much, much smaller than the frequency of accent-specific pronunciation variants, which typically change several words per sentence. And with Google you can look up many light typos and it will come up with the correct form (although not things like using "of" instead of "have", of course).
I work as a non-native speaker in Korea. Speaking and listening is just insanely harder than reading and writing. I can be productive as long as I'm exchanging messages on Github/Messenger, but meetings are horrendous.
I have the opposite problem here in Japan. I can listen and speak pretty well, even in meetings, but written stuff kills me because of all the kanji...
And both of you should blame distributed work for this? For opposite reasons? You simply know spoken Japanese (much) better than written, while the poster above you knows written Korean (much) better than spoken.
A non native speaker wasn't born in an English speaking country, the rest are your assumptions. I'm non native and I'm exposed to and speak english every single day, and don't even live in an English speaking country.
Local customs may vary? I'm not a native speaker either and I do mix English and my native language even when speaking. I'd still say my spoken English is significantly worse than the written one.
I grew up in a bilingual en/fr environment. I mostly read in English and watch TV in English. Half of my ex partners are Anglo.
And yet, on calls where I'm the only non-native speakers, and others are American or AU/NZ, I just don't understand half the cultural references and can't say anything because they talk too fast and interrupt all the time. At best, someone might notice that I am frowning or bored.
Regardless whether text or video, some people are not there to listen to others. No easy way out of that one :)
Phone calls are better, as no one can see the group on the other end looking at each other in bemusement (if in a meeting room) or in a group IM chat (if not all in the same place) asking each other what the hell the speaker is talking about (was talking about, as the speaker's often moved on). That's assuming anyone not interested has not taken a bathroom break.
Sarcasm I hope detected.
Speaking in an international environment is a skill. It's not just about (I think the term is) paralinquistics (speed, accent, volume, etc), it's about thinking about who else is in the conversation.
> I disagree with a lot of this article because it assumes that we are efficient robots that just need things to be searchable and written down.
It assumes no such thing. If anything it assumes the opposite of your assertion, that we are not perfectly efficient robots able to instantaneously and fully recall the content of transient discussions. Written content is perennial and searchable, so it can be retrieved in the future if necessary without being limited by human foibles and memory.
Even if the search is bad and the system is not especially designed for it, I regularly manage to find information I dimly recall through search in discord and friends, something which would be entirely impossible using video calls. IME that is in fact a regular issue, people asserting that things were told during discussions and there's no way to confirm it, have context, … because the discussion was a voice / video call.
> The article also assumes every one is a native speaker who can write quickly and clearly in a chat -- in a lot of international projects this is not the case.
Have you been in that scenario, ever? Video calls are infinitely worse than typed text between non-native speakers. And if the call is not going to be in english… why would the written communication be so?
> I find that there is less chance for misunderstanding and aggression if you disagree over a video call.
I find that there are regular shouting matches over video calls, and collisions between speakers makes the experience miserable. It's also impossible to dive in and out and recover the information, if you arrive on a group discussion midway you can read the history, if you dive out for a bit you can read what you missed. On a video call, it's gone.
> Also, human contact and informal communication make life and working more enjoyable.
If there are "regular shouting matches" going on in any form of meeting then I would suggest the organisation in question has cultural problems way beyond the communication tool being used.
Have you been in that scenario, ever? Video calls are infinitely worse than typed text between non-native speakers. And if the call is not going to be in english… why would the written communication be so?
I am in this scenario every work day as a non-native speaker. I much prefer talking to people than trying to get the text correct.
I'm also in that scenario everyday with other 3 non native speakers from different countries, text is preferred unanimously. Tbh, that's the first time I encounter a non native speaker software engineer who prefers video calls.
While there may be some people who don’t enjoy human contact, I think it’s a little unfair to suggest that this is some kind of idiosyncratic preference of the original poster. It’s a basic human need. Most people who work full time will want to have some kind of social contact within working hours.
It was not clear from your post that you were referring to video calls rather than human contact in general. Here is the part I was responding to:
>> Also, human contact and informal communication make life and working more enjoyable.
>To you.
I think the vast majority of people would prefer having social contact via video calls to the alternative of having no social contact or having it only via text chat - yes. But I was not talking specifically about video calls.
> I think the vast majority of people would prefer having social contact via video calls to the alternative of having no social contact
I believe that too, but for me at least, video chat is for chitchat and banter and text chat for everything, including substance. This is the same for in person; I enjoy going with clients and colleagues to coffeeshops and bars, but we don't get much done in either (in bar, if with techies, actually more than you would think) but it is nice for the human contact.
> I think the vast majority of people would prefer having social contact via video calls to the alternative of having no social contact or having it only via text chat
Cursory evidence - namely, your up-versus-down-votes on this and the GP comment (both currently gray) - suggests that said majority is not really all that vast.
I think threads like this tend to end up with a specific subset of people reading them and weird voting patterns. Let’s look again at the point I was responding to:
>> Also, human contact and informal communication make life and working more enjoyable.
>To you.
Present the second statement to anyone outside a certain subset of HN readers and they would just sigh and shake their heads. But on HN we can actually have lengthy debates about whether or not humans are indeed social animals!
The votes are pretty even, incidentally. My comments have been alternately positive and negative.
It's also implying that you do need to train a bit to work efficiently in a distributed team.
> The article also assumes every one is a native speaker who can write quickly and clearly in a chat -- in a lot of international projects this is not the case.
These are two different things. Native speaker is one, having the skill of writing quicky and clearly is another. They're unrelated. Both are trainable. Not to mention that in my experience it's the native speakers (of English i guess?) have the worst spelling :)
> Also, human contact and informal communication make life and working more enjoyable.
And... informal communication has to be in a video call? It can't be in writing?
As for the human contact, I do recommend having a social life outside work. Distributed or not distributed work.
Source of statements: been working in distributed teams for 20 years, not since this pandemic.
And... informal communication has to be in a video call? It can't be in writing?
On video calls and in meatspace, you get to see peoples facial expressions, their smiles, they can move their hands and make gestures. I much prefer that to text.
As for the human contact, I do recommend having a social life outside work. Distributed or not distributed work.
You are correct but, personally, I think spending 8 hours a day without seeing faces is too much.
We work with people from all over the world, most not native speaking. For technical stuff, in our experience, voice or video calls are the most inefficient thing possible. Because spoken bad English is far worse than written, a lot of people have less than optimal internet bandwidth and latency and, worst, after the call the details are kind of lost. So first writing the main points in chat, if then some people (usually this is 1 person) want a call, we do a call and then flesh the details out over chat and in docs/wiki.
Informal comms is also via chat; far more so then in video as, because of the overchatter and bad connections, jokes and quips get lost far easier.
Ymmv of course but we avoid vid/voice like the plague, so far it hurt us with large amounts of miscommunication and time loss.
By the way, been doing this and like this for 25 years now.
> in theory writing stuff in a wiki is useful but then try finding the information with, say, Confluence search.
If the company/team wiki isn't organized to optimize for browsing to relevant documentation, then you might as well use google docs (which excels at search and is terrible for browsability).
A reasonable percentage of effort documenting something in a wiki should be devoted to making sure that people actually can find it, otherwise you're in cleaning-closet-in-disused-bathroom territory.
> I find that there is less chance for misunderstanding and aggression if you disagree over a video call.
If you put me in a video call with someone not more or less capable of communicating in our chosen common language I can practically guarantee that I’m going to want to murder them.
There’s nothing worse than sitting on a long call waiting for someone to finally understand what button you want them to click. Even better if you have 500ms delay too.
500ms ? you have it lucky , try 2000ms next time for real frustration. Bonus points if you can hear yourself back unless the recipient is muting him/herself
The assumption that text is always superior to a sync conversation is too strong. Often you get the crucial bits by interrupting someone mid discussion and asking for specifics.
But you can do that in text too.
I mean if it's wall of text dump, no; but if people keep their chat blocks short, then it's a two way convo. (or more)
One thing I personally hard disagree with is the author's view on chat/DMs; that they are by default and expected to be synchronous and immediate.
Unless urgency is indicated somehow, I see chat as asynchronous - an incoming question doesn't carry an expectation of immediate feedback. This is in contrast with, say, a phone call.
Some of the negatives of chat-heavy comms disappear under that mode. Like, why does encrypted e-mail need to have benefits over chat (apart from the interoperability, maybe).
Chat is new to society and we don't (yet) have strong cultural norms and expectations around how it should work. I think things like this are important to talk about when forming a team or starting to work on a project or in a new context.
I've done like three or four video calls at work since corona (=full remote). I don't get the US obsession with video calls. Voice is perfectly cromulent for almost everything (see: those 3-4 exceptions).
In distributed teams involving people from multiple countries you probably want to avoid both video and voice calls because on average everyone is much better at writing and reading English compared to speaking and listening.
There are people out there who would not even give a single sentence description of what they want rather it is "when can you jump on a call with me".
They assume the task is difficult to explain in text but to me it often sounds like they don't even have an idea of what they want really.
They want me to hold their hands and lead them through a journey of self discovery while on the ride we discover joy and surprise and at the end of the tunnel only to discover the project is radically abstract and the client is not happy to pay on a per hour basis.
A lot of people had very little video/voicechat experience before the pandemic. It doesn't occur to them, that the "downgrade" to audio-only is actually better than video+audio.
Text trumps audio in terms of communicating hard facts. But many people outside of the tech industry can't properly touch-type. Just consider how many people still make phone calls instead of writing an e-mail.
Many people in the tech industry can't touch-type!
Certainly in the UK, and probably Europe, where you are much less likely to have a comp-sci degree, it is very hard to create consistent requirements for devs like "touch type 60 words per minute" or "understands patterns and principles".
It would be great to have something, even an industry standard like exists for law, medicine and even some building trades to at least have a base-level of consistency. I think this would help communication a lot - the domain language like "this wouldn't work as a Singleton because we need to subclass it" is nice and terse but only if you know the words.
I meant, we had computers, but not a whole class full of them. Teaching kids one by one on the one computer per class would have been very inefficient.
Most of the meetings that I attend as a full-time remote employee are ones where someone is sharing a screen anyways. There's little screen real estate for anyone's webcam and I wouldn't really be interested in staring at them since I'm primarily looking at the shared screen.
The obsession is clear at least: Video calls are the narcissist's prime weapon of choice to fake useful involvement in a project. Many managers grade people on presence and eloquence in meetings.
What is not clear is why the actually productive people don't push back.
I do a lot of meetings on Zoom. The idea that I should instead carefully craft documentation for much of the work I do is an incredibly bad one. The ideas I develop are easy to misunderstand, and constantly in flux. Meanwhile, my teammates have other things to do than keep up with my confluence pages.
Usually such intensive documenting ideas are promoted by people with no respect for good documentation. But also, people with little understanding of how working relationships are formed and maintained.
> But also, people with little understanding of how working relationships are formed and maintained.
I didn't form and maintain a relationship with the team picking up the project after I left. Last I heard they formed a pretty useful relationship with all the documentation I left.
Hard disagree here. In practice, corporate wikis are always graveyards of outdated and incomplete information. The process usually looks like this:
1. Someone is excited about a new project and creates a wiki page with a lot of aspirational introductory content and a sketch of the rest of the page with TBD everywhere
2. Author gets busy on other things, leaves the company, or the project quickly diverges from the original vision
3. The original page stays in the wiki, adding negative value
Documenting is like exercising or eating healthy: doing it an average of once per month isn't worth crap.
It's not a problem with documenting stuff, it's a problem with corporations. Somehow very few companies have technical writers whose main job is keeping their docs healthy.
I think this strongly depends on how much time everyone spends on the wiki and how much love it is given in the first place.
I’ve had companies where it is exactly as you say. Which is especially frustrating because a search for the term you need yields 19 graveyard pages and 1 actual result.
But also companies where the wiki was a bastion of well kept and up to date information.
What I think it mostly comes down to is structuring. If you have little wiki fiefdoms, where every project gets it’s own page, and nobody gets to edit other projects, then you quickly end up with huge heaps of garbage.
If there is one space that the entire company has access to, which is well organized, it’s much easier to get rid of (or restore) information.
People keep saying reading body language and expressions is important and so in-person or video meetings are crucial. However in my experience in the software industry experienced people don't show their emotions from behind their poker-face. If people show emotions, they are mostly fake smiles and fake enthusiasm. If you don't get honest feedback from your team in text, you're not going to get it from body language either.
This is a well-written, cogent, and carefully considered article whose conclusions I disagree with almost completely.
Many of the specifics have already been discussed, but a major benefit of video calls has been missed: Screen sharing. Computer interaction is largely a visual medium in modern times. It is so much easier to look interactively, together, at something than to try to type out what's going on. This applies to both instructions on using or doing something, and especially to code review or discussion.
That doesn't mean you screenshare or call for most problems - you don't. But for some things it just ends up taking infinitely less time, especially when you are having trouble getting one side to understand via text.
I work for a fully remote engineering team that has been remote for more than a decade - COVID changed very little of my organization's culture, as far as I know (I joined after the pandemic started). One of our core rules is "if a conversation is not going well, or people don't understand what's being said, take it to video," and that has served us well.
Everyone I know uses YouTube as a de facto reference. They don't read blogs, Wikipedia, news articles or company documentation, rather they look for explainer videos or tutorials.
I mention that because I think it overflows into work interactions. I've had to deal with many complex problems, technically complex but also with business complexity needing collaboration to manage the objectives and risk. In these circumstances it really warrants a document or detailed email to tell others everything they need to know and consider, and yes it's going to require effort to absorb it. In recent years I've noticed that people almost never read these and ask for a video call. They want you to present it as if it were a YouTube video and you lose an hour trying to explain everything and losing much of it, because it's too much to absorb in real-time.
Maybe I'm a bad writer but I think few would dispute that it's the best way to transfer a block of information. As a rule of thumb calls only make sense for Q & A or discussions.
> Everyone I know uses YouTube as a de facto reference. They don't read blogs, Wikipedia, news articles or company documentation, rather they look for explainer videos or tutorials.
This comes as a complete surprise to me because I don't know anybody who uses Youtube for technical information. Everyone I work with primarily uses Google or DuckDuckGo to find answers on blogs or on stack overflow. If that doesn't work they check the official docs.
I've noticed this too but I don't think it's because of YouTube. I think some people just communicate differently.
There are a few people on my team that won't engage with written communication. Similarly, I have difficulty with video communication. It's just something you need to look out for when hiring and building teams.
I find people don't like calls if they don't have an opportunity to prepare for them well. A call that has a clear agenda, a clear purpose, a set of well defined outcomes, and (ideally) a document sent ahead of time for people to read and think about makes calls significantly more effective. Otherwise everyone just says they'll think about stuff and then you need a second call to get people's reactions.
Sometimes setting everything out in a document and an agenda can even make the actual call redundant, if people respond with their input early enough.
High latency: An idea that takes 30 back-and-forths to resolve may take minutes in a meeting but weeks in writing. Meetings really have negative latency because you see people react before you've finished speaking.
High effort: Even if you account for low bandwidth and reach the same % chance of being understood as when speaking, when that % "misses" the cost is high because of the round-trip-time. To counteract this, you spend even more time editing than you did getting your meaning across.
Emotional: I perceive people as meaner in writing than in meetings, and in response I become meaner. I don't want to and I try not to, but it can still happen.
Albeit I agree with the author on nearly every point, some challenges seem neglected.
"Write. Things. Down." may let a a competitor obtain some company's efficient ways/tools, especially such information is shared among departments ("view permissions") and with the high employee turnover rate. Even if it is not a real risk (in most cases it IMHO isn't) some (especially among senior managers) will think it is, and fight against this convention.
If you like the approach described in this article AND are able to hire you will probably describe your ways during job interviews, and in many ways attract candidates similar to yourself. Leading an old existing team not build by yourself towards this approach is a totally different matter because pertinent habits are among the most difficult to change.
Most pertinent tools (wiki and bugtrackers alike) publish each piece of information's history (who wrote what/when). It sometimes becomes a metric: people committing numerous or very useful information obtain consideration. Many organizations, especially large ones, have people unable to produce such input BUT nonetheless useful as 'crossroads': they usually have all most recent important info and are also able to say who may answer to a question. Other ancillary challenges include shyness (some are able to talk or write a mail to a direct colleague but won't commit any potentially widely-read wiki article) and 'weird' syntax/orthograph.
One of my clients employees struggles massively with asynchronous communication. He constantly spams one-liner after one-liner and demands immediate answers. Anything that involves working together on a sheet or a document becomes a pain in the butt.
Having to work with someone like this has caused our current project to take longer and become more expensive. I really wish corporations gave these people some basic training and tips on async communication. Some people just don't get it.
In my experience, both asynchronous teams and teams of people doing highly synchronized work, some spending most of their time together in voice chats or calls have worked great.
I appreciate the experience feedback from that article, but I wish some of the feedback was contextualized rather than presented as universal. The antithesis laid at the end of the talk helps a bit, but it is a bit reductive about the effectiveness being limited to ops.
I just scanned this, but some of it seems ludicrously wrong. Like rating chat a neutral face for "find" when honestly one of the biggest advantages to chat in my mind is being able to search for key terms long in the future and be able to turn up the exact transcript of the discussion you're thinking of. Or like this quote:
> Using interactive chat is a good idea for the kind of communication that requires immediate, interactive mutual feedback from two or more participants. If that is not the case, chat is not a good idea.
No. Just... no. This is so wrong it's absurd. The point of text chat instead of in-person chat is that it's asynchronous and it doesn't require immediate, interactive feedback. I'm honestly just baffled at how someone could actually use chat and come to this kind of conclusion.
I think neutral is a good rating for chat searchability. It's better than video or face to face chat. It's good for recalling the conversations you were part of. It's bad for discovering information you don't know about and you weren't part of.
The chat that doesn't require immediate feedback is called "email".
Otherwise you are stuck with "hey, can you help?" with zero details for when you actually get to take a look. Then you have to say "yeah, what's wrong?" and wait another hour. A properly written email would have solved the issue in a tenth of the time.
One of the reasons for having a meeting is knowing that most people won't read or watch anything you send them, and even if they read they won't recall much. That is why in film school my teachers screened films in class instead of just assigning them.
I prefer written communication because I like to think while absorbing information. As a result, when it's on a call, often I'll space out for a bit if I suddenly get a thought -- and then I'll have to ask the speaker to repeat themselves, which isn't very fun for anyone involved. Plus, I don't have the best memory when it comes to conversations.
Just the fact that written communication can be referenced (and searched!) at any point in the future makes it magnitudes better for me.
Even if a call is recorded (which it never is at my workplace), it takes a lot more time to go through a recording to find the bit you need, as compared to a quick and simple ctrl+F.
I feel like Discord can work OK for a small team. People can answer things asynchronously in the chat, organize in different channels or threads. And usually it is possible to sync up every now and then, and that can be useful.
I think its easier for people to start putting things in an issue tracker and then forget about them, and the other person doesn't even know about it, or dismisses part of it, writes a comment, the first person doesn't see the comment, etc. So people often need to discuss things directly and tools like an issue tracker can make it too easy to avoid resolving issues or talk past each other.
It depends though. I am talking about really small teams.
Calling remote work "distributed" is a buzzword. The work is distributed to different people, whether they're in the same building or not. The physical distance decreases the communication bandwidth between them.
"Distributed" teams are teams where everyone works remotely whereas "remote" roles may include those where some workers are in an office together. It's an important distinction.
We optimize to get things done. If a video call is warranted, we all hop on and get to the answer much faster than text. If the convo is inherently asynchronous, we use Slack. I don’t see the benefit in drawing lines in the sand. Each situation is different. We use impromptu meetings in most cases, not scheduled ones. It works like a charm. Being rigid about process is a classic productivity killer.
I have an objection to the author's blanket disregard for "pings" in chat - while the request could/should be worded a bit more clearly than just "ping", IMHO they're a valid way of requesting if an opportunity for synchronous communication is available in the (not that rare!) cases where asynchronous communication would be worthless.
If someone's blocking on some unclear thing which requires external input for progress, making an asynchronous request (i.e. writing the question directly) is not helpful since in such a case an answer is valuable if and only if it's synchronous. Writing a chat question that gets answered the next day has negative value, since it has the extra cost of the answerer reading the question and preparing the (now useless) answer.
If the other person is available for synchronous communication, that's great, there's an opportunity for a useful communication.
If the other person is not available for synchronous communication right now, that's fine as well, but then the replacement is not asynchronous communication with that person but instead something else that can actually be done right now - contacting someone else who is available, or doing some redundant experimentation/research, or just proceeding with an assumption that may later be falsified, etc, all of which aren't optimal but still clearly preferable to blocking until an asynchronous response arrives.
Sure, things can be done 100% asynchronously eventually, but that's not an optimal flow, going 100% async requires giving up many opportunities for helpful communication. Especially in international organizations I've far too often seen things delayed by days or even weeks where literal ten minutes of a synchronous comms (no matter if it's a phone call or chat or video) was completely sufficient.
Perhaps I'm looking at 100% async as an optimization on allocating time for communication that has some benefit of throughput - having more efficient schedules for people working - at a horrific sacrifice of latency - having much less effective schedules for resolving individual tasks.
Pings would be useless (and I'd concede that even harmful) in a world where status indicators in a chat app reasonably match actual availability for synchronous communication right now, but I don't live in such a world, people are routinely marked as "active" while they're working in meetings or deep work and don't want to be disturbed, and the opposite way around; so there needs to be some protocol of requesting synchronous communication - are there any ways that are substantially better than "pings"?
Even in the case where the explanation of the question is quite long, I think the onus is still on the asker to give information for the reciever to prioritise it. Because sometimes my availability for the discussion depends on how important that is versus my current task.
Need help debugging your CI build while I'm just churning out unit tests for my run of the mill work? Sure, I'll take up that discussion.
But hey, what if I'm working on a gethering data for a presentation to stakeholders tomorrow? Then your CI build has to wait.
But wait, what if you're debugging production being down? Well then you know what, my feature can wait.
So "I need help with <X> so that I can <Y>, are you around for a chat?" is ok. I can make a judgement call here and give you an answer.
"Ping"/"yt"/"Can we talk?" is not. You give me no information to prioritise your request.
Okay, that's a good point, a "ping" with sufficient context about the priority is a clear improvement.
I saw the original article's recommendation to add "no urgency" when appropriate, but the type of requests I was thinking about are those that actually are urgent but not that important, where it's no big deal if you can't answer right now, but then we'll proceed without your input at all instead of waiting for it.
I think there is space for more disruptive approach to meetings. Remember Elon Musk saying if he didn't find meetings productive, he would walk out? Stuff like that.
How about saying to people that if they don't see the value of a meeting, they shouldn't turn up. You start to see problems arise and people should then start to see why some of those "boring" meetings are actually important or perhaps how the same problems can be solved in another more productive way.
The difficult part is sometimes teaching devs that they do not exist in a vacuum and the business is more important than the tech. Sometimes they need to be in meetings to help others understand and sometimes they need to hear some non-tech truths, neither of which they would necessarily appreciate by default.
>I think there is space for more disruptive approach to meetings. Remember Elon Musk saying if he didn't find meetings productive, he would walk out? Stuff like that.
The last time I even suggested doing this, I was swiftly met with a "then I'll report it to HR" by the manager. Even though this was in video, with a clear tongue-in-cheeks approach. The majority of my colleagues had nowhere near the audacity to make such a suggestion, let alone actually do this. Reality is most developers aren't working together enough to make it a serious risk for managers not to listen, as the average dev is still replaceable enough.
>The difficult part is sometimes teaching devs that they do not exist in a vacuum and the business is more important than the tech.
You don't really need meetings for this though. Unless you're trying to convince a stubborn dev by showing him just how much more stubborn stakeholder X, who controls the money, truly is.
>Sometimes they need to be in meetings to help others understand
I fail to see how pulling the majority of the dev team to the meeting, while at the same time giving them zero time to prepare and zero development in their presentation skills, helps others understand much more if it wasn't something that was so trivial, you could've explained it in a short message. I'm all for helping the client, the higher-ups or any other non-dev who wants to know more and meet the business ends. However, the kneejerk reaction seems to be "let us meet". In reality, they want me to bridge the gaps between their perceived needs, their actual needs, my/our jargon and a way of communication they understand. New-age meetings with barely any preparation or research beforehand, being mostly a back-and-forth, no-holds-barred discussion, have barely ever been a suitable medium for that.
One thing I never see considered in these discussions is the terrible state of high-speed residential broadband in the United States. Whether or not my team wants to do constant video calls, I can't. One of the things I did when I first started working from home is set up my router with OPNSense in preference to the ISP-provided router, which gives me some visibility into fine-grained details of traffic.
Early on, the defense program I'm working on was big into pair programming. With a distributed team, this meant screen-sharing through Teams for hours per day. I could see turning on HD screen sharing and video feeds causes Teams to eat up 90%+ of my bandwidth, and additionally by tracking the data rates I'm getting through the WAN at different times of day and different times of the week, I can see very clearly that my ISP is throttling me when I'm using that much bandwidth. I may be paying for 400 mbps, but if I actually try to use that, I won't get it for more than a few minutes a day, or I'll get it for Netflix and Amazon Video, which are clearly paying for preferential treatment now that net neutrality is still not a thing (it will be interesting to see if they'll just started getting throttled as well if the FCC chooses to reinstitute net neutrality).
Unless and until my employer or whatever acquisition office for the contract we're working on is going to run a dedicated leased line to my house that guarantees me consistent high-speed access, or they're willing to pay the ISPs for preferential treatment like streaming services do, nonstop HD audio and video is simply not going to happen.
An hour a day is fine. I don't want to say never have any primarily voice-based meetings. Talking to people is important for many reasons. But at some point, when you've made a design decision, write it down. When you've begun implementing something, write down why you did it the way you did, how it works. It's easy enough to say documentation grows stale, so why bother? Then keep it up to date. Block out time in your work planning to do that. You wouldn't learn how to use the programming language you're learning, the operating system you're using, how TCP/IP and HTTP works, how a browser renders html, by asking the original creators of those tools. They wrote down how those things worked, and committed to a public interface, and you learn by reading as you're doing. I've been bit far too often by organizations that want to deliver fast and scrimp on documentation, and all the knowledge of why a particular design decision was made rest entirely in one person's head, and that person leaves, and the rest of us are left to reverse engineer whatever it is they did. You gain speed up front for your very first delivery, but then permanently cripple yourselves forever after.
Maybe the vast majority of developers are just making screwdrivers and it doesn't really matter. The plan is to deliver anything quickly, generate some hype, and get acquired, and they don't care about product longevity because they won't be around for it anyway. But at least some people are making jet turbine engines, or something worthy of being included in that rebuild civilization from scratch archive that documents how to create all of the lasting and essential technologies that enable modern life. That has to outlive you. It's already not scalable or workable to try to contribute to the Linux kernel by asking Linus Torvalds personally how it works. Thankfully, it has great documentation. But imagine if you were at Google trying to work on Android and wanted to ask Robert Love why it is doing a particular thing. He's not even there any more! Thankfully, he not only contributed to the wonderful kernel documentation project. He also wrote books about it! And they won't grow instantly stale because the design decisions were well thought out and the APIs are fairly stable because of it. Writing out the rationale behind your design decisions is one way to force yourself to make sure they are actually well thought out.
It’s gracious of the author to assume that the purpose of video calls is usually to convey information and solicit feedback, but the true purpose of most video calls is to exert some control over somebody who (the organizer thinks) needs a reminder of who’s in charge.
What's up with this guy repeating what he says is not science so it could be wrong? Is he unaware that science is wrong all the time too?
Science is not a religion! It bothers me how people think "science" is something not to be questioned when it's actually the opposite - always question science. Because not only are scientists funded by corporations with motives, they also like to get rich as much as politicians.
yep, global warming, no wait its global cooling, no wait back to warming now lets just rebrand as climate change so nobody can disagree with whichever direction we choose to go with this thing.
Where I work (backend software development), we do video calls and meetings all the time. Probably an hour every day or more is spent in direct contact. I see this as absolutely essential to get people on the same page - but none of the reasons that people have listed in this thread for why people prefer personal meetings apply to me. For instance, I am extremely grateful if someone writes up meeting notes, I read text documents all the time, and I often require continuous uninterrupted time and respect it in others, and I still prefer voiced meetings.
I think the primary reason is if I am trying to clarify an idea for a design or an approach, I will go to the people who have also touched that field of difficulty, and try to explain what I am trying to do to them in advance. The spoken medium in that case gives room for interruptions, immediate elaborations and feedback. A write-up either convinces or it doesn't; it can be edited but it has feedback cycles on the order of tens of minutes to hours. Spoken communication has feedback cycles of seconds, so even if I was going to write something up, I'd talk it through verbally first, anyways.
It’s an extraordinary week when I get as many as 40% of my working hours for focus time.
* Weekly cross functional syncs for the products I’m involved in, 2 hours.
* Weekly design and SLA/postmortem reviews for the org, 2 hours.
* Three interviews and associated debriefs, 4.5 hours.
* Standup, planning, and retro, 2.5 hours.
* Tech talks, knowledge sharing sessions, org and company all hands, 2 hours.
That’s before anything as-needed to work on a specific issue.
Any they're all 30 minutes. What the heck do you expect to accomplish in 30 minutes? You spend 20% of the time waiting for someone to show up.
For the daily team coordination meeting I run, we had a problem with that. So after one especially egregious delay, I asked how people felt about that. They didn't like it, of course. I then said I wanted a consistent start time, but was open as to when it was. At the hour? 1 minute after? 5 minutes after?
To my surprise, they picked 1 minute after. And everybody has stuck to it. A couple months in we'll occasionally have somebody turn up late, but the meeting starts without them, so they know not to do it again. It's great!
We also build an agenda on the fly, keeping the pace brisk. Usually we finish a few minutes early, and sometimes the meeting will be a zippy 10-15 minutes. It's possible to have good, useful meetings!
Part of this is because I'm also fine with interrupting and telling people to take something async if a group meeting is becoming a hyper-specific 1:1.
Soon enough, meetings remain direct and rabbit-hole free. Unless the entire purpose of the meeting was to collectively burrow into it.
All it takes is a little discipline, and clear expectations.
Needless to say when I just recently did that with the two program managers in a fortune 500 I got punished.
It leaves you wondering why these big corps have program and project managers when they:
- consistently don't have an agenda
- completely ignore scope
- don't even try to define scope
- keep talking about being productive
- keep getting promoted for creating powerbi dashboards of other people's work
Not that all managers are bad or anything; plenty of them are people just trying to get things done. It's a structural problem.
I don't know how you went about it in this case but, I've never called out.
All I've ever said is, hey...do we need to do this now?
But that tends to spin off longer discussions, and there are often short things people want to raise with the team. So after we've gone through our kanban board, we'll have an optional period called "post". Long items go into Zoom chat as "Post: thing to discuss" and we give a few minutes to each.
I totally agree with blocking rabbit holes. Things that interrupt the fast run-through of the board get booted to post. Items there that are longer than a few minutes get booted to async or a topic-specific meeting, generally a smaller group than the team meeting.
One other trick I recommend: rotate leadership of the meeting once people have the hang of it. I ran mine myself for the first couple months. Then I ran it every other week, with somebody new swapping in. The weeks when people are responsible for keeping the meeting on track make them much better participants when they're not in charge.
Before everyone kind of expected ~3 minutes of lateness to be the norm, dependent on elevator and stairway congestion. And god forbid one person is traveling from another meeting in another building a bit of a walk away.
Way too many 39 minute things get scheduled for 60. While there logistics issues at physical events with multiple tracks I feel most conference talks should be 30 minutes too.
Text is good or bad. It’s an attention thief, and you never know what you are getting. Also, I find that platforms like Teams are great for the present, but awful for history and context.
"Standups" that are really PM status calls that constantly go down rabbit holes. My update is 30s or less, but the meetings are always 30 minutes long and usually run over.
"Code reviews" that are really run/monopolized by one person. The entire team is required to attend even if you have no code, but in practice no one other than the runner is allowed to provide feedback.
The calls started out shorter but over time they've become a hybrid of:
- "Here's the outlay for today." The shortest are just this which only happens when things are going smoothly and everyone's tackling things of moderate difficulty.
- "Here's something that's been giving me trouble" which prompts a few minutes discussion. Usually someone has a idea to pitch in which gets the person unstuck, but it can bleed into...
- "I wanted to bring up this thing I noticed" which pulls us into a bigger half-hour discussion with some possible followups scheduled with the more senior members.
So at the extremes, any given instance of this meeting could last from 10 minutes to 45 minutes.
We usually refer to this as a "stand-up" but I could see how someone from a more regimented team would understand it to be something with a more tightly defined purpose.
Obviously this gets a little slack if you're a super senior position (nobody's telling the company President they're not circling back on something already discussed) but for the most part meetings are much more efficient if you're absolutely ruthless with the clock. It's literally the only thing that nobody can control.
On the flipside you have to be equally ruthless about not going over time. At 5 min before the scheduled meeting end time we start cutting off discussions that have become circular and start determining if we need to have a follow-up or clarification meeting for something. My biggest rule for this is that it can't be the exact same group, you'll just end up having the same meeting again. These follow-up meetings are most effective if it's a subset of the original group trying to clarify some specific point.
30 minute meetings can be useful if you stick to these rules.
Write up everything first for education and background, distribute that, then have a short meeting when there’s something actionable to do.
That explains a lot of things though. It sounds like most of your meetings are terrible. Actually, if most of people's meetings in this thread are terrible experiences, that seems like it would explain their sentiments. In other words, meetings are mostly time loss, which you're of course trying to minimize.
(It really helps that we have a culture of "I don't think I can contribute to this meeting, I'm gonna head out.")
Almost all of my in-person meetings are technical debates - or group debugging sessions, where progress depends on randomly noticing something. In both cases, they scale well with number of members up to a point of four or so, where adding another participant generates more ideas than it costs time.
That's the main thing I come across. Most meetings are well over four people. And personally, I already don't deal well with more than 3 people as most people work on a vastly different wavelength than myself.
Now consider all the "Agile" meetings are already 5+ people and often contain management types and people who are both higher on the chain of command and have no technical background either hogging the attention. Suddenly, most meetings I see become either a hybrid announcement + roll call, a "meeting" with ulterior motives (e.g. managers trying to measure "participation" as a way to grade employees) or a very rushed design-by-committee approach to solving something.
Meanwhile in my “Sent” (aka “CYA”) folder…you can guess where this is going.
If voice/video meetings could have no more than 4 participants unless (insert somewhat burdensome exception process), all participants would presumably consider more carefully who should be added.
It's just like of the signup process on your landing page. Make things you want to happen as effortless as possible -> make things you want to happen less more effortful.
An average week is 2.5 hours of "core" meetings
* 1.5 hours - 30 minute "standup" 3 days per week. Skip the BS status updates. Planning, team discussions, etc all happen in this timeframe.
* 30 minutes of retro (1 hour biweekly)
* 30 minutes of 1:1
We generally keep planning meetings pretty light. A _really_ heavy week will be 10 hours of planning. A light week will be 1 or 2 hours talking about an upcoming feature.
Everything else happens by individuals, asynchronously.
And this ain't no startup either: EA DICE can probably safely be described as a rather large company these days..
Of course, it might well be different in other teams, being a backend web developer I'm part of a somewhat unusual team in the context of a gaming studio.
At best, you might get a subject line.
95% of all substantial corporate meetings would be vastly, vastly improved if someone wrote up some dot point notes of said meeting, and circulated the document as a courtesy.
In my time in the workplace I've seen this done in maybe 5% of meetings. The entirety of that 5% involved team leaders having a regularly scheduled catch-up with our divisional overlord, and I sat in or saw the memo.
Why don't these very basic things that would vastly improve productivity take place?
Garden variety laziness.
Unless you get over that very basic hurdle of couldn't give a damn, what's the point of all these other solutions?
Normally when I see ineffective meetings and missing communications, it's an organizational culture issue. The number one cause I see is what the Lean people call "overburden". I know somebody who was a big fan of circulating notes and tried to bring that practice to a new job. But they ended up giving up because a) bosses put too much on their plate to have the time for that, and b) everybody else was overloaded enough that they wouldn't read the notes anyhow.
That of course means everybody has even more work now, the work called "failure demand". Extra meetings. Doing the wrong work because of confusion. Dealing with delays trying to get information not communicated to them. Etc, etc. So good meeting notes become more needed and more difficult to adopt.
In my view, all of this is driven by not getting another Lean concept: push systems vs pull systems. [1] Work is not driven by actual demand and capacity limits, which is how pull systems work. Instead managers jam requests into the hopper with little regard for capacity, causing all sorts of downstream pathologies.
So if we want to actually fix this, we need systemic change, not individual blame.
[1] https://www.allaboutlean.com/push-pull/
Corporate world is a shit hole where the only thing that matter is the opinion of a decision level breaker (escalation point) .
I've had the obligatory interactions with a few backstabbing and/or passively aggressive teams, and when things eventually explode and work their way up the leadership chain (hopefully to someone with more sense), it's a quick knife through "you said / they said" to produce a written document from a meeting 3 months ago, where the assumptions you've been operating under were agreed to by the other team.
Obligatory: producing said doc in this context makes you an asshole, and is a nuclear escalation. But some (rare) times call for that.
(If it's a habit, you should probably reflect on yourself and/or find a healthier place to work)
They change technical designs or timelines slip?
My read was that a team didn't want to be bothered with something, but I was working on a corporate priority, so we set a meeting, hashed out, and agreed on how issues should be brought to them.
When something happened down the road, the agreed process was followed, and they (surprisingly stubbornly) claimed they weren't responsible and shouldn't be contacted for this issue.
I go a step further. If it isn't on the agenda, we don't cover it. Just "spit-balling" or talking about things that are clearly not researched is a WASTE of everyone's time. If you want to talk about something, we want to take 10 minutes and research it too. Put it on the agenda and be prepared. We don't want to be ambushed into stupid decisions. "Let's use mongo!" out of no where is pointless and stupid. So that 95% can keep their unresearched ideas to themselves. Thanks. Personally I live by this quote: "Every stupid meeting starts with no agenda." NO agenda? Even better, meeting canceled.
The only worthwhile document is a document with a clear owner that is routinely updated. This does not scale beyond a few pages per user.
When you talk to someone, you get their view at this point in time. You don't accidentally get their view five years ago which they've since revised; you are guaranteed to get, if not the accurate version, then at least the current one. When you talk to multiple people, you even have a chance to get the correct one. Notes cannot defend their argument and so must be taken on faith - or else to confirm your understanding, you end up talking to someone anyways!
In code, the best documentation is the test, because it must be correct. The second best documentation is a comment, because it's right there and hence hard to miss. Third is an external specification referenced in the README, because they generally change much more slowly than the code. Distant fourth is a self-written document in the same repository, because after all, how do you notice that something didn't change during review?
So it all comes back to the good ole "give a shit" factor.
If TDD is superior if leads write tests, but leads rarely write tests, then is it superior?
If meetings are superior if everyone shows up on time, prepared and generates documentation of the meeting, but nobody ever does those things, then are meetings superior?
Tl;dr - Be honest about your team's reality, and choose the optimal option for that reality.
They're usually sent to me sometime after midnight, EST, for a meeting at 9 AM. When I did go to the office it wouldn't be uncommon to hit some traffic and arrive to find out you've already missed a meeting you didn't know about. If you did make it in, you were immediately ambushed with an angry customer who doesn't understand timezones or business hours.
Similarly, I've seen so many folks in leadership that get the feedback of "the engineers on the floor have no idea who you are, what you do, or why this re-org matters". The solution? Publish a biweekly newsletter about what they and the rest of the org does - that cascades with every other level of middle management doing the same. All getting filtered into the same unread folder, leading to the same feedback as before.
This is the kind of lazy non-explanation I was complaining about in the recent HN thread on "laziness doesn't exist". There are people who have perosnal incentives and counter-incentives, they work in groups which bring their own incentives. Things like:
- Socially, writing up notes and sending them out is often seen as secretarial work, women's work, low status work. People think their personal interests are better served by taking high status tasks, not low status tasks.
- As well as being a low status task, it could be seen as trying to usurp your manager's authority, if you want to be the one sending out "here is what we decided and who is going to be taking followup actions".
- Socially it could be "goody-two-shoes" behaviour if you weren't asked to do it, and lose the respect of some people.
- Socially, if a coworker got lumbered with a task nobody wanted, they might resent you sending an all-hands email "gloating" and making sure everyone knows about it, or you fear they might.
- Writing memo notes invites you to open-ended future scrutiny if anyone thinks the notes unfairly represented what they said or their participation. Coworker who thinks management is getting an unfair view of their contribution because of your biased notes, for example.
- There are power imbalances and adversarial relationships among people in meetings; writing memo notes may be seen as "I'm going to write down what you say so I can take it out of context and use it against you" or in an "I'm going to hold my seniors to account" way. Maybe some things in the meeting are spoken, deliberately so they are "off the record".
- If you think the notes will not be read, writing them feels like pointless make-work.
- It misunderstands the purpose of meetings as "productivity" when they are often for avoiding blame, feeling important, or pushing something back and forth because the people in the meeting don't have the authority to make the decision(s) which need to be made.
- If the company sees meeting records as important, it should be explicitly someone's job. If it's not someone's job, the company doesn't value it, so why should you? In the YosefK "Employees can read their manager's mind"[1] sense, employees are not there to make the company productive, they are there to make their managers happy.
- If meeting memos aren't regularly taken, and you want to start, you face all the possible problems of trying to push a change into an existing system and people's reluctance to change no matter what the change is.
- If tasks are assigned in the meeting, they should go into wherever the teams track work, not into generic forgettable group emails. If decisions are made, they should be logged in whatever documentation logs decisions, not generic email. If those are done the memo is redundant.
There are only a couple of quick ways through this, the first is an enthusiastic junior who wants to be seen to be helping and has little to lose because the worst case is a manager asking them to stop. The other is a high-status employee (socially, e.g. wealthy white male, contractor, friend of the boss) or organizationally (e.g. senior title, manager, leader) secure in their skills and life who have respect and can damn the consequences - although they would be more likely to use their power to skip the junk meeting or have the memo taking task assigned to someone less busy. For everyone else, all changes have risks, especially ones which include increasing your visibility while making the implied statement "you weren't doing things properly and I have a better way".
These things which really exist and do bother people casually dismissed as "garden variety laziness" is, I repeat, a lazy non-explanation.
[1] https://yosefk.com/blog/people-can-read-their-managers-mind....
Has anyone tried putting at the top of the summary something like:
Meeting cost: 4 work hrs (8 people x 30 mins)
to draw attention to the fact that meetings aren't free, and put the decisions in context of how much it cost to get to them?
When they need something they will ask.
A meeting should always have an outcome in the form of actionable work;just create tickets and assign them to people.
The ticket should capture all the necessary information to work on it. If a document is needed, it should be linked to the ticket.
As for developers, scripts, tools, automation works better than a boring, soon to be outdated document.
Which speaks to another problem with most large company cultures: ticket shoveling. In a healthy company, every ticket should receive one of three outcomes.
(1) I can fix this, I work the ticket to completion, then request verification it's resolved.
(2) I cannot fix this, but I know someone who can. I add context if needed, forward it to the appropriate person, and stay appraised of it and available until it's completed.
(3) I cannot fix this, and nobody I know of can. I list out reasons why this cannot be fixed, and give any information I might have about alternative contacts who might(!) be able to help, and close the ticket.
In most companies, and I think this has been exacerbated by outsourced IT and contractual resolution SLAs, until everyone's internalized it as the way they and everyone else should act, you get something like this.
(1) Is work. This is to be avoided at all cost.
(2) I blindly forward a ticket on to anyone else who looks remotely responsible, to get it out of my queue, and then wash my hands of the entire matter and forget it ever existed. I certainly don't follow up or add context.
(3) I close the ticket without providing any reason why, or information I have about someone who might know something I don't, who could help.
A reliable metric I've come up with for measuring corporate and/or team disfunction is to count how many circuits a worst-case ticket can receive (where a circuit is: originator -> some number of teams -> originator/loop). My record is 3, before someone noticed.
I think this is true too, but I don't blame folks.
I recently started a position which is the first time I ever worked as a non-freelancer. Previously I always wrote documentation for myself and my clients in self contained Markdown files.
But at this new place they use a combination of Confluence and Google Docs for any type of docs that don't necessarily belong in a repo's readme file (like ancillary topics, general knowledge and guides). It's not easy to find stuff unless you already know where to look. Confluence's full text search is also pretty lackluster.
Turns out keeping documentation and knowledge up to date when you're dealing with a handful of folks isn't easy. Especially if you factor in everyone contributing their own docs with their own writing style and patterns. It makes for a pretty inconsistent feel.
I think this is worth calling out for its own discussion. Along with the traditional use of "RTFM" meaning "go away and stop bothering me", any amount of dysfunction in a sytem or company can be tolerated as long as someone has written about it in a document somewhere.
Poor design? Buggy implementation? Complex configuration? Poor defaults? Missing features with inconvenient workarounds? Arduous processes? All fine as long as it's been documented. And any comments about voluminous documentation and "I couldn't find it" become point-scoring "I know where the needle is in the documentation haystack so I win".
And as a user or customer, the last thing I want when facing your system being complex and unintuitive is a mountain of documentation to go with it. That adds insult to injury - you couldn't make a good system and you've made more work for me on top. How often have any of you read some good documentation about the internal workings of a system and left feeling intrigued and surprised and impressed? Occasionally, right? And how often have you trawled through documentation saying things like "to change the username field, simply log into our admin website, click accounts, click usernames, click customize, then download the XML customization file from the available template files, make the necessary changes, and simply raise a support ticket for us to install the new file" ? A poorly designed feature with an awkward process, with parts where detail matters (content of the file) left for guesswork, but at least it's all documented.
I want my intuition (experience) to carry me almost seamlessly through your system, and if it has a short amount of clear documentation which helps me then I'm OK with that. If you want me to commit to trawling through books worth of content to learn things which are your own proprietary lock-in buzzwords around Rube Goldberg kludge designs, I'm not as OK with that.
My team (and many XP teams) gets by just fine organizing things with cards that have a modest number of words on them (5-10, normally). When we need something, we ask. It works fine for us. We're a distributed team that has never met in person. But it also works fine for in-person teams: https://williampietri.com/writing/2015/the-big-board/
And I disagree it should contain those things. In the XP tradition story cards (which are conceptually different than tickets, but I'm fine with either term) are tokens for conversations. The more documentation you add, the more it drives people away from conversation. As you say, when people need something, they'll ask. And I think that's a strength, not a weakness.
We eventually decided to have a meeting chairman, their job was to make sure there is an agenda and to keep it on topic. They also make notes of tickets that need writing and make sure it's done post. We decided to rotate the responsibility weekly since it's kinda a hassle, but it really helps having someone assigned to keep meetings moving.
We used a spreadsheet to rotate at first, but then found an slack app called tellspin that's been working really well for us. It reminds me a lot like pagerduty has a schedule, overrides, etc. Allows people to move shifts and stuff so the meeting leader role is always filled.
There are two types of approaches to working out a problem. One is to get everyone in a meeting and talk it over until a solution is reached. The other is for a single person to carefully think through the problem and possible solutions, write down a solution, and pass it around for (usually asynchronous) comments.
People who think meetings are really useful thrive in the first approach. The more meetings they have the faster they can get things done. People who prefer the solitary focused approach tend to see meetings as obstructions to progress, because they prevent them from actually solving problems by pretending to solve the problem while not making headway.
Which approach is right is highly contextual, and you can’t really argue it either way without falling back on personal preferences.
That's not all the time my friend. My usual day is 3-5 hours on conf calls, you gain 'popularity' as your time / seniority at the company rises. I get 50% of my actual work done during those meetings, while others talk in matters unrelated/distantly related to my work.
Video all the time? No, thank you. Our top 10 bank in the world is managing just fine without a single video call since forever. You get used to it very quickly, and the freedom it gives you is magical.
An hour a day is junior dev level meeting load at almost every place I've ever worked. Seniors are 2-3, arch/staff/principal 4-6 and managers all day long (all averaged over a couple weeks or so it obviously ebbs and flows).
Other useful formats - look at work together with stakeholders and get instant feedback + clarification questions.
For almost anything else, meetings can be a time waste. Some communications do not require full bandwidth exchange but where tone is important, an efficient meeting can be a timesaver.
This is just false. You and I live other approaches every day. I believe his way of working is fine for him, and he's welcome to it. But that doesn't justify sweeping dismissal of everybody else's experience.
Yes, he has a header saying, "It’s solely based on my personal experience, and the experience of others I have talked to, watched, or read. Everything I say here is subject to debate and rebuttal, or you can simply have a different opinion."
But he's then stating things dramatically as universals in a way that excludes the experience of others. Not only is it an unpleasant experience for those, like me, who have different experiences, but it also means I can't really trust him to tell the difference between what happens to work for him and what might work for others.
No one can.
> unpleasant experience for those, like me, who have different experiences
Is it unpleasant being shown experiences that differ from yours? Can you elaborate on this with an example from the text and your own experience? I think it would help me understand where you are coming from if I could relate to it.
The way I see this - you are asking the author to write in a 'universal' style, that respects and acknowledges all view points without preferring one over another. I have two problems with that. 1) it defeats the purpose of sharing your experience and the preferences you have learned. 2) it is difficult ranging to impossible.
I'm not trying to put words in your mouth there, merely give you an opportunity to correct me and my impression.
Of course one can. People do it all the time. Look at medicine, for example. A doctor will write of personal experience with a few patients. But before making sweeping universal statements they'll talk with other doctors, form hypotheses, and gather data under controlled conditions.
Being shown different experiences is not unpleasant. What is unpleasant is having personal hypotheses stated as universal rules when they aren't.
> The way I see this - you are asking the author to write in a 'universal' style, that respects and acknowledges all view points without preferring one over another.
I am not. I am asking to show awareness of the limits of his knowledge. To leave room for the notion that differently situated people will have different experiences. And perhaps be willing to listen to those experiences in order to improve his understanding.
> merely give you an opportunity to correct me and my impression.
Gosh, how generous of you.
That said, I am not into this guy's shoes. His arguments make sense. I get it but my situation is different, plus I enjoy talking to the people I work with. Well, most of them anyway.
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
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.
I don't see much of a difference between older vs younger generations nor between native and non-native English speakers.
I'm open to accept that it's just my own experience and that it doesn't generalize.
Compare this to a meeting: you just say what you are thinking at the moment. Others might join in and raise points you haven't thought of. So you start from there and readon further. Basically a meeting is clearing things out in a group, which sometimes is more efficient.
For most people, the high level information is all they really need. The few who need to dig in more can hash out the details in a smaller more effective meeting without wasting everyone else's time.
That kind of documentation is not necessarily bad, but it depends heavily on context, which is not always shared across readers. So when the author and those they talked to are not available anymore, it quickly becomes useless.
Don’t get me wrong, I don’t think people should write War and Peace. Usually a good 2-3 paragraph introduction improves the quality of a document/email significantly. There you can provide the context that is necessary to fully understand the pictures and lists and diagrams you add after.
The article also assumes every one is a native speaker who can write quickly and clearly in a chat -- in a lot of international projects this is not the case.
I find that there is less chance for misunderstanding and aggression if you disagree over a video call. Also, human contact and informal communication make life and working more enjoyable.
You think non-native speakers have an easier time communicating in real time in a video call than through text? A video call is the worst case for a non-native speaker.
(Well, OK, a phone call is even worse. But being synchronous and relying on their ability to understand the spoken language are both terrible ideas if you're concerned about what makes things easy for non-native speakers.)
Oh yea, I forgot about this because I don't do video/audio calls.
A non native speaker is NOT exposed to spoken english daily. In some countries they even dub Hollywood movies so not even their entertainment is in english. And where movies are subtitled you tend to read the subtitles so you don't bother understanding accents, speech over explosions and stuff like that.
Written english is another thing, if you do programming. There's no point of looking for docs in your native language; the originals are in english and always more up to date.
So maybe the non native speakers have trouble because the OP speaks too fast / has an unfamiliar accent?
Here's an unpopular opinion by a hard-hearing person with native English skills: the far majority of people are really bad at verbal communication as a way to transfer knowledge. Doubly so in complex areas. To top it off, I see barely any difference between people in roles that require speaking often and those who don't, except for frequent public speakers.
The reasons? Bad articulation. Speaking too fast. Speaking before you know what you want to say. Complicated explanations. Muttering "uh", "ah" and more. Diversions. The list goes on.
And it's not like the information on how to be a better speaker isn't out there. I can assuredly say the average person in a leadership position doesn't even take 5 minutes of their work day to do vocal exercises. That alone already helps a lot.
Meanwhile, people making informative videos and talks out of their own accord are much easier to hear and understand. The difference is night and day.
I am constantly trying to work on this part of myself-for both myself and others' benefit-but have to be careful to not get too anxious about trying to fix my communication.
I really appreciate this comment because I've found that when I talk to (close) friends about this challenge they do not consider communication something that can be much improved; communication style is mostly rigid. This baffles me because it seems like it would doom most bad communicators to a lifetime of bad communicating. This might be exactly how life works, I admit, but its an interesting way of getting to this obvious point.
Where do you recommend someone like me go to learn more about those vocal exercises you mentioned. That does seem like a great starting place.
The second one was surprising by comparison, because while it wasn't that bad, it illuminated all the things that were spot on in the first one. For instance, it was just a little too fast for me to easily type everything on the slides as notes, which I think is approximately the pace at which I absorb information. At the same time, there was too much redundancy and filler so I tended to get lost figuring out where information should go in my outline.
If someone is otherwise a good and prepared speaker, a heavy accent can be adjusted to.
Go a little slower and prune the verbiage a little more seem to me like principles to come back to.
- If you don't understand a sentence the first time, you can read it twice (or as many times as you want), and this very often helps as a non-native speaker - sometimes you misinterpret a word and this throws you off, but reading the sentence again clears the misunderstanding. It also can help deducing the meaning of an unknown word from context, etc. Of course in a video call you could ask the speaker to repeat, but this isn't functional if you do it often, and can make the non-native speaker feel ashamed of slowing the conversation too much, especially in work environments.
- This one only applies to related languages, but it's much easier to deduce the meaning of written words from other languages. Take the word "subtitles" in your text. Any Spanish speaker could infer that it is equivalent to "subtítulos" in Spanish, because it's spelled very similarly (Levenshtein distance = 2). But the pronunciation (/ˈsʌbtaɪtəls/ vs. /sub'titulos/) is very different (Levenshtein distance = 5).
- If you still don't understand a word, you can look it up. Or even hit Google Translate. Good luck with that in a video call.
- Written language is reasonably standard. While there can be some regional variation (color/colour, lift/elevator and so on); you get rid of all the diversity of accents which can be a huge deal for a non-native speaker.
Seriously, speaking as a non-native English speaker (at a quite good level now that allows me to speak quite comfortably, but obviously I went through all the stages of learning...) the difference between texting and phone/video calling when you're a non-native is enormous. The latter is like an order of magnitude more difficult.
Levenshtein distance between conventionalized IPA orthographic representation is not a useful metric for the perceptual difference between two spoken sound sequences.
> Written language is reasonably standard. While there can be some regional variation (color/colour, lift/elevator and so on); you get rid of all the diversity of accents which can be a huge deal for a non-native speaker.
This problem actually comes up in writing too; I knew some Chinese students who were really offended by English typos. They had a point - lacking the pre-existing knowledge of English that lets me know what a typo was meant to say, they just had no way of finding out what a misspelled word was supposed to mean. You can't look up words that don't exist.
Erm, just google them and take the recommended result?
In general I think searching with missspelled words is a quite solved problem.
I know. Just wanted to provide some metric for the quantitatively-minded, and because the example is hard to follow if you don't speak Spanish or read IPA, and I don't know any least bad quantitative metric. But qualitatively speaking, I can tell you that inferring the meaning of that English word from the written form is obvious even to a Spanish person with zero English knowledge, while inferring it from the pronunciation it's very difficult. And it's just an example, but it happens with many words.
> This problem actually comes up in writing too; I knew some Chinese students who were really offended by English typos. They had a point - lacking the pre-existing knowledge of English that lets me know what a typo was meant to say, they just had no way of finding out what a misspelled word was supposed to mean. You can't look up words that don't exist.
It can come up, but still, the normal frequency of typos is much, much smaller than the frequency of accent-specific pronunciation variants, which typically change several words per sentence. And with Google you can look up many light typos and it will come up with the correct form (although not things like using "of" instead of "have", of course).
I grew up in a bilingual en/fr environment. I mostly read in English and watch TV in English. Half of my ex partners are Anglo.
And yet, on calls where I'm the only non-native speakers, and others are American or AU/NZ, I just don't understand half the cultural references and can't say anything because they talk too fast and interrupt all the time. At best, someone might notice that I am frowning or bored.
Regardless whether text or video, some people are not there to listen to others. No easy way out of that one :)
Sarcasm I hope detected.
Speaking in an international environment is a skill. It's not just about (I think the term is) paralinquistics (speed, accent, volume, etc), it's about thinking about who else is in the conversation.
It assumes no such thing. If anything it assumes the opposite of your assertion, that we are not perfectly efficient robots able to instantaneously and fully recall the content of transient discussions. Written content is perennial and searchable, so it can be retrieved in the future if necessary without being limited by human foibles and memory.
Even if the search is bad and the system is not especially designed for it, I regularly manage to find information I dimly recall through search in discord and friends, something which would be entirely impossible using video calls. IME that is in fact a regular issue, people asserting that things were told during discussions and there's no way to confirm it, have context, … because the discussion was a voice / video call.
> The article also assumes every one is a native speaker who can write quickly and clearly in a chat -- in a lot of international projects this is not the case.
Have you been in that scenario, ever? Video calls are infinitely worse than typed text between non-native speakers. And if the call is not going to be in english… why would the written communication be so?
> I find that there is less chance for misunderstanding and aggression if you disagree over a video call.
I find that there are regular shouting matches over video calls, and collisions between speakers makes the experience miserable. It's also impossible to dive in and out and recover the information, if you arrive on a group discussion midway you can read the history, if you dive out for a bit you can read what you missed. On a video call, it's gone.
> Also, human contact and informal communication make life and working more enjoyable.
To you.
I am in this scenario every work day as a non-native speaker. I much prefer talking to people than trying to get the text correct.
We're not discussing human contact, we're discussing video calls.
> I think it’s a little unfair to suggest that this is some kind of idiosyncratic preference of the original poster.
So pointing out that people differ is "a little unfair" but asserting liking video calls is a universal human requirement and enjoyment is fine?
> It’s a basic human need.
History is full of people who happily did without.
>> Also, human contact and informal communication make life and working more enjoyable.
>To you.
I think the vast majority of people would prefer having social contact via video calls to the alternative of having no social contact or having it only via text chat - yes. But I was not talking specifically about video calls.
I believe that too, but for me at least, video chat is for chitchat and banter and text chat for everything, including substance. This is the same for in person; I enjoy going with clients and colleagues to coffeeshops and bars, but we don't get much done in either (in bar, if with techies, actually more than you would think) but it is nice for the human contact.
(Talking work context here if that was not clear)
Cursory evidence - namely, your up-versus-down-votes on this and the GP comment (both currently gray) - suggests that said majority is not really all that vast.
>> Also, human contact and informal communication make life and working more enjoyable.
>To you.
Present the second statement to anyone outside a certain subset of HN readers and they would just sigh and shake their heads. But on HN we can actually have lengthy debates about whether or not humans are indeed social animals!
The votes are pretty even, incidentally. My comments have been alternately positive and negative.
> The article also assumes every one is a native speaker who can write quickly and clearly in a chat -- in a lot of international projects this is not the case.
These are two different things. Native speaker is one, having the skill of writing quicky and clearly is another. They're unrelated. Both are trainable. Not to mention that in my experience it's the native speakers (of English i guess?) have the worst spelling :)
> Also, human contact and informal communication make life and working more enjoyable.
And... informal communication has to be in a video call? It can't be in writing?
As for the human contact, I do recommend having a social life outside work. Distributed or not distributed work.
Source of statements: been working in distributed teams for 20 years, not since this pandemic.
On video calls and in meatspace, you get to see peoples facial expressions, their smiles, they can move their hands and make gestures. I much prefer that to text.
As for the human contact, I do recommend having a social life outside work. Distributed or not distributed work.
You are correct but, personally, I think spending 8 hours a day without seeing faces is too much.
Informal comms is also via chat; far more so then in video as, because of the overchatter and bad connections, jokes and quips get lost far easier.
Ymmv of course but we avoid vid/voice like the plague, so far it hurt us with large amounts of miscommunication and time loss.
By the way, been doing this and like this for 25 years now.
Yeah, he must be new to distributed work :)
If the company/team wiki isn't organized to optimize for browsing to relevant documentation, then you might as well use google docs (which excels at search and is terrible for browsability).
A reasonable percentage of effort documenting something in a wiki should be devoted to making sure that people actually can find it, otherwise you're in cleaning-closet-in-disused-bathroom territory.
If you put me in a video call with someone not more or less capable of communicating in our chosen common language I can practically guarantee that I’m going to want to murder them.
There’s nothing worse than sitting on a long call waiting for someone to finally understand what button you want them to click. Even better if you have 500ms delay too.
Voice is accurate but not precise.
Different problems are resolved better by one than the other.
Brain storming better in voice. Technical details of an app that needs to be coded, writting is better.
Unless urgency is indicated somehow, I see chat as asynchronous - an incoming question doesn't carry an expectation of immediate feedback. This is in contrast with, say, a phone call.
Some of the negatives of chat-heavy comms disappear under that mode. Like, why does encrypted e-mail need to have benefits over chat (apart from the interoperability, maybe).
Chat is new to society and we don't (yet) have strong cultural norms and expectations around how it should work. I think things like this are important to talk about when forming a team or starting to work on a project or in a new context.
In distributed teams involving people from multiple countries you probably want to avoid both video and voice calls because on average everyone is much better at writing and reading English compared to speaking and listening.
There are people out there who would not even give a single sentence description of what they want rather it is "when can you jump on a call with me".
They assume the task is difficult to explain in text but to me it often sounds like they don't even have an idea of what they want really.
They want me to hold their hands and lead them through a journey of self discovery while on the ride we discover joy and surprise and at the end of the tunnel only to discover the project is radically abstract and the client is not happy to pay on a per hour basis.
Text trumps audio in terms of communicating hard facts. But many people outside of the tech industry can't properly touch-type. Just consider how many people still make phone calls instead of writing an e-mail.
Certainly in the UK, and probably Europe, where you are much less likely to have a comp-sci degree, it is very hard to create consistent requirements for devs like "touch type 60 words per minute" or "understands patterns and principles".
It would be great to have something, even an industry standard like exists for law, medicine and even some building trades to at least have a base-level of consistency. I think this would help communication a lot - the domain language like "this wouldn't work as a Singleton because we need to subclass it" is nice and terse but only if you know the words.
> consistent requirements for devs like "touch type 60 words per minute"
How are those two things related?
Is typing part of the computer science curriculum?
(In the Netherlands, and of course we used typewriters, since we didn’t have that many computers yet)
Edit: modified for clarity based on comment
I meant, we had computers, but not a whole class full of them. Teaching kids one by one on the one computer per class would have been very inefficient.
Modified the original comment.
A lot of experience typing (code) would tend to make someone more likely to pursue and complete a CS degree.
Then the difficulty on the other side of having to read since the host’s typing shows up in a side box instead of like a TV subtitle.
Sometimes we’ll have stakeholders call in on their iPad or whatever, but they’re passive so it’s best to avoid text if they do need to jump in.
What is not clear is why the actually productive people don't push back.
Easier to change jobs until the culture fits. Especialy with remote jobs.
I do a lot of meetings on Zoom. The idea that I should instead carefully craft documentation for much of the work I do is an incredibly bad one. The ideas I develop are easy to misunderstand, and constantly in flux. Meanwhile, my teammates have other things to do than keep up with my confluence pages.
Usually such intensive documenting ideas are promoted by people with no respect for good documentation. But also, people with little understanding of how working relationships are formed and maintained.
I didn't form and maintain a relationship with the team picking up the project after I left. Last I heard they formed a pretty useful relationship with all the documentation I left.
It's not just about you. Write it down so that everyone can benefit.
1. Someone is excited about a new project and creates a wiki page with a lot of aspirational introductory content and a sketch of the rest of the page with TBD everywhere
2. Author gets busy on other things, leaves the company, or the project quickly diverges from the original vision
3. The original page stays in the wiki, adding negative value
It's not a problem with documenting stuff, it's a problem with corporations. Somehow very few companies have technical writers whose main job is keeping their docs healthy.
I’ve had companies where it is exactly as you say. Which is especially frustrating because a search for the term you need yields 19 graveyard pages and 1 actual result.
But also companies where the wiki was a bastion of well kept and up to date information.
What I think it mostly comes down to is structuring. If you have little wiki fiefdoms, where every project gets it’s own page, and nobody gets to edit other projects, then you quickly end up with huge heaps of garbage.
If there is one space that the entire company has access to, which is well organized, it’s much easier to get rid of (or restore) information.
Many of the specifics have already been discussed, but a major benefit of video calls has been missed: Screen sharing. Computer interaction is largely a visual medium in modern times. It is so much easier to look interactively, together, at something than to try to type out what's going on. This applies to both instructions on using or doing something, and especially to code review or discussion.
That doesn't mean you screenshare or call for most problems - you don't. But for some things it just ends up taking infinitely less time, especially when you are having trouble getting one side to understand via text.
I work for a fully remote engineering team that has been remote for more than a decade - COVID changed very little of my organization's culture, as far as I know (I joined after the pandemic started). One of our core rules is "if a conversation is not going well, or people don't understand what's being said, take it to video," and that has served us well.
I mention that because I think it overflows into work interactions. I've had to deal with many complex problems, technically complex but also with business complexity needing collaboration to manage the objectives and risk. In these circumstances it really warrants a document or detailed email to tell others everything they need to know and consider, and yes it's going to require effort to absorb it. In recent years I've noticed that people almost never read these and ask for a video call. They want you to present it as if it were a YouTube video and you lose an hour trying to explain everything and losing much of it, because it's too much to absorb in real-time.
Maybe I'm a bad writer but I think few would dispute that it's the best way to transfer a block of information. As a rule of thumb calls only make sense for Q & A or discussions.
This comes as a complete surprise to me because I don't know anybody who uses Youtube for technical information. Everyone I work with primarily uses Google or DuckDuckGo to find answers on blogs or on stack overflow. If that doesn't work they check the official docs.
There are a few people on my team that won't engage with written communication. Similarly, I have difficulty with video communication. It's just something you need to look out for when hiring and building teams.
Sometimes setting everything out in a document and an agenda can even make the actual call redundant, if people respond with their input early enough.
Low bandwidth: Writing doesn't have inflection or body language, so you need more words to convey the same idea. More: https://www.youtube.com/watch?v=3bFsqk84frI
High latency: An idea that takes 30 back-and-forths to resolve may take minutes in a meeting but weeks in writing. Meetings really have negative latency because you see people react before you've finished speaking.
High effort: Even if you account for low bandwidth and reach the same % chance of being understood as when speaking, when that % "misses" the cost is high because of the round-trip-time. To counteract this, you spend even more time editing than you did getting your meaning across.
Emotional: I perceive people as meaner in writing than in meetings, and in response I become meaner. I don't want to and I try not to, but it can still happen.
"Write. Things. Down." may let a a competitor obtain some company's efficient ways/tools, especially such information is shared among departments ("view permissions") and with the high employee turnover rate. Even if it is not a real risk (in most cases it IMHO isn't) some (especially among senior managers) will think it is, and fight against this convention.
If you like the approach described in this article AND are able to hire you will probably describe your ways during job interviews, and in many ways attract candidates similar to yourself. Leading an old existing team not build by yourself towards this approach is a totally different matter because pertinent habits are among the most difficult to change.
Most pertinent tools (wiki and bugtrackers alike) publish each piece of information's history (who wrote what/when). It sometimes becomes a metric: people committing numerous or very useful information obtain consideration. Many organizations, especially large ones, have people unable to produce such input BUT nonetheless useful as 'crossroads': they usually have all most recent important info and are also able to say who may answer to a question. Other ancillary challenges include shyness (some are able to talk or write a mail to a direct colleague but won't commit any potentially widely-read wiki article) and 'weird' syntax/orthograph.
Having to work with someone like this has caused our current project to take longer and become more expensive. I really wish corporations gave these people some basic training and tips on async communication. Some people just don't get it.
I appreciate the experience feedback from that article, but I wish some of the feedback was contextualized rather than presented as universal. The antithesis laid at the end of the talk helps a bit, but it is a bit reductive about the effectiveness being limited to ops.
> Using interactive chat is a good idea for the kind of communication that requires immediate, interactive mutual feedback from two or more participants. If that is not the case, chat is not a good idea.
No. Just... no. This is so wrong it's absurd. The point of text chat instead of in-person chat is that it's asynchronous and it doesn't require immediate, interactive feedback. I'm honestly just baffled at how someone could actually use chat and come to this kind of conclusion.
Otherwise you are stuck with "hey, can you help?" with zero details for when you actually get to take a look. Then you have to say "yeah, what's wrong?" and wait another hour. A properly written email would have solved the issue in a tenth of the time.
If you're expecting a response, but don't care when it comes, that's ideal for chat.
Just the fact that written communication can be referenced (and searched!) at any point in the future makes it magnitudes better for me.
Even if a call is recorded (which it never is at my workplace), it takes a lot more time to go through a recording to find the bit you need, as compared to a quick and simple ctrl+F.
But people all work differently, so... :shrug:
I think its easier for people to start putting things in an issue tracker and then forget about them, and the other person doesn't even know about it, or dismisses part of it, writes a comment, the first person doesn't see the comment, etc. So people often need to discuss things directly and tools like an issue tracker can make it too easy to avoid resolving issues or talk past each other.
It depends though. I am talking about really small teams.
Significant disagreements likely arise about what this means.
The problem isn't so much that video calls can be warranted, but that different people can have wildly different understandings of what that means.
http://paulgraham.com/makersschedule.html
If someone's blocking on some unclear thing which requires external input for progress, making an asynchronous request (i.e. writing the question directly) is not helpful since in such a case an answer is valuable if and only if it's synchronous. Writing a chat question that gets answered the next day has negative value, since it has the extra cost of the answerer reading the question and preparing the (now useless) answer.
If the other person is available for synchronous communication, that's great, there's an opportunity for a useful communication.
If the other person is not available for synchronous communication right now, that's fine as well, but then the replacement is not asynchronous communication with that person but instead something else that can actually be done right now - contacting someone else who is available, or doing some redundant experimentation/research, or just proceeding with an assumption that may later be falsified, etc, all of which aren't optimal but still clearly preferable to blocking until an asynchronous response arrives.
Sure, things can be done 100% asynchronously eventually, but that's not an optimal flow, going 100% async requires giving up many opportunities for helpful communication. Especially in international organizations I've far too often seen things delayed by days or even weeks where literal ten minutes of a synchronous comms (no matter if it's a phone call or chat or video) was completely sufficient.
Perhaps I'm looking at 100% async as an optimization on allocating time for communication that has some benefit of throughput - having more efficient schedules for people working - at a horrific sacrifice of latency - having much less effective schedules for resolving individual tasks.
Pings would be useless (and I'd concede that even harmful) in a world where status indicators in a chat app reasonably match actual availability for synchronous communication right now, but I don't live in such a world, people are routinely marked as "active" while they're working in meetings or deep work and don't want to be disturbed, and the opposite way around; so there needs to be some protocol of requesting synchronous communication - are there any ways that are substantially better than "pings"?
Need help debugging your CI build while I'm just churning out unit tests for my run of the mill work? Sure, I'll take up that discussion.
But hey, what if I'm working on a gethering data for a presentation to stakeholders tomorrow? Then your CI build has to wait.
But wait, what if you're debugging production being down? Well then you know what, my feature can wait.
So "I need help with <X> so that I can <Y>, are you around for a chat?" is ok. I can make a judgement call here and give you an answer.
"Ping"/"yt"/"Can we talk?" is not. You give me no information to prioritise your request.
I saw the original article's recommendation to add "no urgency" when appropriate, but the type of requests I was thinking about are those that actually are urgent but not that important, where it's no big deal if you can't answer right now, but then we'll proceed without your input at all instead of waiting for it.
How about saying to people that if they don't see the value of a meeting, they shouldn't turn up. You start to see problems arise and people should then start to see why some of those "boring" meetings are actually important or perhaps how the same problems can be solved in another more productive way.
The difficult part is sometimes teaching devs that they do not exist in a vacuum and the business is more important than the tech. Sometimes they need to be in meetings to help others understand and sometimes they need to hear some non-tech truths, neither of which they would necessarily appreciate by default.
The last time I even suggested doing this, I was swiftly met with a "then I'll report it to HR" by the manager. Even though this was in video, with a clear tongue-in-cheeks approach. The majority of my colleagues had nowhere near the audacity to make such a suggestion, let alone actually do this. Reality is most developers aren't working together enough to make it a serious risk for managers not to listen, as the average dev is still replaceable enough.
>The difficult part is sometimes teaching devs that they do not exist in a vacuum and the business is more important than the tech.
You don't really need meetings for this though. Unless you're trying to convince a stubborn dev by showing him just how much more stubborn stakeholder X, who controls the money, truly is.
>Sometimes they need to be in meetings to help others understand
I fail to see how pulling the majority of the dev team to the meeting, while at the same time giving them zero time to prepare and zero development in their presentation skills, helps others understand much more if it wasn't something that was so trivial, you could've explained it in a short message. I'm all for helping the client, the higher-ups or any other non-dev who wants to know more and meet the business ends. However, the kneejerk reaction seems to be "let us meet". In reality, they want me to bridge the gaps between their perceived needs, their actual needs, my/our jargon and a way of communication they understand. New-age meetings with barely any preparation or research beforehand, being mostly a back-and-forth, no-holds-barred discussion, have barely ever been a suitable medium for that.
Early on, the defense program I'm working on was big into pair programming. With a distributed team, this meant screen-sharing through Teams for hours per day. I could see turning on HD screen sharing and video feeds causes Teams to eat up 90%+ of my bandwidth, and additionally by tracking the data rates I'm getting through the WAN at different times of day and different times of the week, I can see very clearly that my ISP is throttling me when I'm using that much bandwidth. I may be paying for 400 mbps, but if I actually try to use that, I won't get it for more than a few minutes a day, or I'll get it for Netflix and Amazon Video, which are clearly paying for preferential treatment now that net neutrality is still not a thing (it will be interesting to see if they'll just started getting throttled as well if the FCC chooses to reinstitute net neutrality).
Unless and until my employer or whatever acquisition office for the contract we're working on is going to run a dedicated leased line to my house that guarantees me consistent high-speed access, or they're willing to pay the ISPs for preferential treatment like streaming services do, nonstop HD audio and video is simply not going to happen.
An hour a day is fine. I don't want to say never have any primarily voice-based meetings. Talking to people is important for many reasons. But at some point, when you've made a design decision, write it down. When you've begun implementing something, write down why you did it the way you did, how it works. It's easy enough to say documentation grows stale, so why bother? Then keep it up to date. Block out time in your work planning to do that. You wouldn't learn how to use the programming language you're learning, the operating system you're using, how TCP/IP and HTTP works, how a browser renders html, by asking the original creators of those tools. They wrote down how those things worked, and committed to a public interface, and you learn by reading as you're doing. I've been bit far too often by organizations that want to deliver fast and scrimp on documentation, and all the knowledge of why a particular design decision was made rest entirely in one person's head, and that person leaves, and the rest of us are left to reverse engineer whatever it is they did. You gain speed up front for your very first delivery, but then permanently cripple yourselves forever after.
Maybe the vast majority of developers are just making screwdrivers and it doesn't really matter. The plan is to deliver anything quickly, generate some hype, and get acquired, and they don't care about product longevity because they won't be around for it anyway. But at least some people are making jet turbine engines, or something worthy of being included in that rebuild civilization from scratch archive that documents how to create all of the lasting and essential technologies that enable modern life. That has to outlive you. It's already not scalable or workable to try to contribute to the Linux kernel by asking Linus Torvalds personally how it works. Thankfully, it has great documentation. But imagine if you were at Google trying to work on Android and wanted to ask Robert Love why it is doing a particular thing. He's not even there any more! Thankfully, he not only contributed to the wonderful kernel documentation project. He also wrote books about it! And they won't grow instantly stale because the design decisions were well thought out and the APIs are fairly stable because of it. Writing out the rationale behind your design decisions is one way to force yourself to make sure they are actually well thought out.
Science is not a religion! It bothers me how people think "science" is something not to be questioned when it's actually the opposite - always question science. Because not only are scientists funded by corporations with motives, they also like to get rich as much as politicians.
Sure, science can be wrong, but peer reviewed resesrch is a lot more reliable than just some guy's opinion.