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