10 ms·

Going out on a limb. 95% of all substantial corporate meetings would be vastly, vastly improved if someone wrote up some dot point notes of said meeting, and c

by urthor 5y ago

Going out on a limb. 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?

jodrellblank 5y ago
> "Garden variety laziness." 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.html https://yosefk.com/blog/people-can-read-their-managers-mind....
FeepingCreature 5y ago
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?
- urthor 5y ago
  Ah but you see, in coding, before you write the test, you need a software developer and/or a team lead who gives a shit about writing tests. So it all comes back to the good ole "give a shit" factor.
  - ethbr0 5y ago
    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.
tibiahurried 5y ago
TL;DR: - Meeting -> Outcome -> Create tickets -> Assign - Developers: write scripts; value automation over documentation In my experience, people don't read documents. 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.
- nickjj 5y ago
  > In my experience, people don't read documents. 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.
- ethbr0 5y ago
  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.
Foobar8568 5y ago
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) .
- blowski 5y ago
  Exactly. If you a toxic culture, written notes won’t help you. If you have a healthy culture, it’s not a problem in the first place.
  - ethbr0 5y ago
    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)
    - atatatat 5y ago
      Sounds like you need to consider making a change, too.
      - Foobar8568 5y ago
        At the end of the day, you need to change as often as you have a reorg in a company.
    - nuclearnice1 5y ago
      What are the kinds of things people reverse their agreement s on? They change technical designs or timelines slip?
ofrzeta 5y ago
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.
amozoss 5y ago
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.
wpietri 5y ago
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. [1] https://www.allaboutlean.com/push-pull/ https://www.allaboutlean.com/push-pull/
- urthor 5y ago
  That's a really good insight.
thrower123 5y ago
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.
jodrellblank 5y ago
> "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?
ransom1538 5y ago
"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.
geekster777 5y ago
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.

by urthor 5y ago

jodrellblank 5y ago

> "Garden variety laziness." 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.html https://yosefk.com/blog/people-can-read-their-managers-mind....

FeepingCreature 5y ago

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?

urthor 5y ago
Ah but you see, in coding, before you write the test, you need a software developer and/or a team lead who gives a shit about writing tests. So it all comes back to the good ole "give a shit" factor.
- ethbr0 5y ago
  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.

tibiahurried 5y ago

TL;DR: - Meeting -> Outcome -> Create tickets -> Assign - Developers: write scripts; value automation over documentation In my experience, people don't read documents. 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.

nickjj 5y ago
> In my experience, people don't read documents. 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.
ethbr0 5y ago
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.

Foobar8568 5y ago

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

blowski 5y ago
Exactly. If you a toxic culture, written notes won’t help you. If you have a healthy culture, it’s not a problem in the first place.
- ethbr0 5y ago
  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)
  - atatatat 5y ago
    Sounds like you need to consider making a change, too.
    - Foobar8568 5y ago
      At the end of the day, you need to change as often as you have a reorg in a company.
  - nuclearnice1 5y ago
    What are the kinds of things people reverse their agreement s on? They change technical designs or timelines slip?

ofrzeta 5y ago

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.

amozoss 5y ago

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.

wpietri 5y ago

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. [1] https://www.allaboutlean.com/push-pull/ https://www.allaboutlean.com/push-pull/

urthor 5y ago
That's a really good insight.

thrower123 5y ago

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.

jodrellblank 5y ago

> "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?

ransom1538 5y ago

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

geekster777 5y ago

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.