6 ms·

Having had been on both sides of this coin, I agree a lot of managers mis-manage meetings. But then there's those engineers who don't show up to meetings and t

Having had been on both sides of this coin, I agree a lot of managers mis-manage meetings. But then there's those engineers who don't show up to meetings and then a month later come to you with a "I don't know how we're deciding on some of these critical product features" and I don't know how to tell them its because they skipped some meetings where they could've been part of that discussion.

sokoloff 1y ago
Just tell ‘em that! We had an internal RFC comment/discussion meeting on a proposed engineering standard. In that exact meeting, a dev flipped out and expressed exasperation that they weren’t asked to comment on the proposal. In the exact meeting that was one in a series of opportunities to comment on the proposal…
- robertlagrant 1y ago
  Yes, this is pretty universal I think. Some people think software engineering in a team is writing code as much as possible, and doing anything else is bad.
- skywhopper 1y ago
  Did they get to read the RFC before the meeting? If they had access but didn’t use it, then this is out of line. But if they only got the RFC during the meeting when they were asked to comment, then flipping out is overboard but the feeling is understandable.
  - sokoloff 1y ago
    Fair Q. It was a multi-week process where the doc was published/open for written comment and then we had a series of meetings for live discussion as well. The engineer in question just completely mis-read where we were in the process and thought this was being announced as a mandate in the one particular meeting.
bargainbin 1y ago
100% this. As some who’s regularly derided by his colleagues for “hating meetings”: I don’t “keep meetings to a minimum”, I “keep meetings to a benefit”. If I’ve called a meeting it’s because there’s a benefit to the instant vocal communication. If you’re not there, you’ve not attended the meeting, no matter which tools you use to record, transcribe or translate. Conversely, if I thought I didn’t need to be in a meeting, then I wouldn’t send a tool to gather stuff for me to then just ignore the tool output - because I don’t need it. These tools are a sign of cultural rot from both participants and the fact people are even making them shows deep flaws in how we communicate in the modern workplace.
- coliveira 1y ago
  No matter how they're used, AI companies will create the artificial need for every company and essentially every worker to use these tools, even if they're not needed.
- pixl97 1y ago
  >Conversely, if I thought I didn’t need to be in a meeting, then I wouldn’t send a tool to gather stuff for me to then just ignore the tool output - because I don’t need it. The only way you know that you didn't need to be at a meeting is to be at the meeting. Catch-22 is a fun game. With dictation tools and analysis you can have meeting notes and then you or AI search for things that might affect you so you can reach out and correct the record. Simply put in modern larger companies there is too much going on at any given time. Most companies of any size are made up many purchased companies and their applications that are kind of glued together into a corporate structure. You can blame culture rot on the participants, but most of the time they are being asked to do too much in a dysfunctional organization.
theamk 1y ago
I'd tell them directly.. "You were invited to the meeting on 2025-MM-DD to discuss this, but you did not show up, nor did you follow up with organizers later. Sorry, you've missed your opportunity to comment" Seems direct and uncontroversial, and IMHO most people react well at this.
pk-protect-ai 1y ago
That's the thing, these meetings are B.S. Engineers need a task, time to think, and write about the solution and its cost. Period. Talking in a room full of people who love to hear their own voices and love to stroke their egos does not actually help engineers do their job. When engineers need to communicate, they communicate with their colleagues. There are tools for such communications that do not require talking and immediate responses. Being reactive (which is what meetings enforce you to do) costs more, as reactive and forced responses will be far more technically unsound.
- zdragnar 1y ago
  Feature development is rarely so cut and dry that you can hand a developer a task and let them run with it. To get there, you need a confluence of context and expertise from several domains: - what problem needs to be solved (user story) - what options are available (interaction design, technical capabilities) - what the cost of implementing each option is, and the opportunity cost of each level of implementation / each option (technical capability, resource management, sales, user research) - managing group consensus on the path forward (communication to technical and non-technical audiences) - break down of any large chunks of work into smaller tasks that can be done and planning the work to be done in series or parallel (resource management, technical capabilities) Finally, after all of that, you have a task (or several) that can be handed off. There's really no way to get here without at least some thought into the implementation details, as the business can't make the decision on which options without knowing rough timelines.
  - pk-protect-ai 1y ago
    Excellent, this all can be written, thought over and discussed in written form. I do not see how this all requires a meeting.
- woah 1y ago
  > Engineers need a task, time to think, and write about the solution and its cost. Period. Talking in a room full of people who love to hear their own voices and love to stroke their egos does not actually help engineers do their job. When engineers need to communicate, they communicate with their colleagues. Seems like when you say "engineers", you mean "people with my exact personality"
jbc1 1y ago
Even if the final nod of agreement happens in real time the actual decision making process for critical product features should involve planning, thinking, research, etc. There should be a strong paper trail such that everyone knows what the decision is going to be prior to the "everyone gets together and declares this is how things are going to be" step. If them missing some meetings means they're in the dark as to how those features were decided on then I can't see that as a defence of attending every meeting so much as a statement of BS meetings being so predominant in the company that all decisions are made through a BS process.
- MrJohz 1y ago
  This might not be quite what the previous poster meant, but in my experience it's often not that the developer missed a meeting and now doesn't know some critical piece of information. Rather, it's often that the developer has some knowledge about the code that changes how something should be implemented. Because they weren't at the meeting, nobody else knew about this, and it's only later, when the developer sits down to write the code, that everyone finds out. In this case, there's nothing to document from the meeting because the information wasn't shared in the first place. The information could only have been shared if the developer had been in the meeting. (FWIW, I've rarely seen this from a developer not being in a meeting entirely, but I've seen it a few times where a developer has treated the meeting as a "read-only" event, i.e. expected that other people provide all the requirements and not used their own expertise or experience of the code to push back on decisions.)
  - coliveira 1y ago
    The point in the parent comment still stands. There should be a paper trail so that the developer would have to confront the need to add such a detail. If the decision was made in the meeting alone, then it was lost in time as not all developers can be expected to be in every meeting.
    - scott_w 1y ago
      How? Meeting notes can never contain all the detail of the meeting and, if they do, there would be so much content that you'd likely miss them when you read the documentation. That's to say nothing of the time investment of the person to catch up on every document produced. In that case, you're essentially relying on the people in the meeting to know they should document that thing as important which, given the person who knows it's important isn't there, is pretty unlikely. Even in an ideal world, we'll have developers not in the meetings they need to be in. My contention would be that we should try to get people in the right meetings and, over time, the number of issues where someone isn't in the right meeting will be lower than if we just don't have those meetings.
8note 1y ago
but i didnt get invited to the meeting in the first place! and i dont think my management chain was either!
david-gpu 1y ago
It is helpful to communicate in advance what is the specific agenda of each meeting, so that people can make an informed decision on whether to attend. Also, it may be helpful to have the meeting organizer send meeting notes after every meeting, including action items assigned to specific people. The notes don't need to be extensive, but there better be an executive summary of what decisions were made, if any, and any unexpected roadblocks that were found. That's how things were done at one of the mega corps where I was employed and it worked great.
Aeolun 1y ago
> and I don't know how to tell them its because they skipped some meetings where they could've been part of that discussion. That there was a meeting where that decision was made between 55 minutes of crud doesn’t really mean anything to me though. I’m not wasting an hour of my day every day on the off chance today’s meeting will contain anything of importance.
- woah 1y ago
  Then just implement it I guess
grogenaut 1y ago
I had an engineer once show up to the re-scheduled "lets get the engineers ideas meeting before the yearly plan ships" meeting that we scheduled so they could be there who then proceeded to spent 15 minutes complaining how they didn't get any input before finally asking what the meeting was for, and finding out they had 45 minutes remaining to give feedback (they had skipped the meeting the previous day, and I wanted to make sure they gave their impact). (I tried to interject earlier but was asked "please let me talk" so I did).
- ralferoo 1y ago
  Why didn't you put "lets get the engineers ideas meeting before the yearly plan ships" as the meeting topic in the invite then? Otherwise you're expecting a whole load of people to turn up for a meeting with no idea what it's for. If you don't tell people what the meeting is for, you're implicitly saying that they don't need to know the topic until they arrive, and so you're signaling that they're not expected to be giving input and they're just there to listen to something - and in 90% of such meetings, they could be done better by e-mail. If you wanted feedback from the engineers, giving them a heads-up that this was their opportunity would have given them time to form their ideas into a succinct coherent point rather than an off-the-cuff ramble.
esskay 1y ago
> But then there's those engineers who don't show up to meetings and then a month later come to you with a >"I don't know how we're deciding on some of these critical product features" You write up meeting notes, tasks, etc right? If you've got engineers who are unaware of functionality because of a verbal meeting being missed you've got deeper problems to address.
- maccard 1y ago
  Not OP but yes and those meeting notes are turned into tasks with callbacks to the meeting they came from. Yet we still get the “where do these priorities come from” questions. You’re not asking for meeting notes you’re asking for a transcription which has the same problem as an email - people don’t read rhem
Cthulhu_ 1y ago
> But then there's those engineers who don't show up to meetings and then a month later come to you with a > > "I don't know how we're deciding on some of these critical product features" > > and I don't know how to tell them its because they skipped some meetings where they could've been part of that discussion. What else was discussed in these meetings? Was everything in there relevant to this one developer? This is what I find an issue in a lot of meetings, the majority is just not relevant to me; do I need to spend an hour of my time and attention span just in case there is something relevant? It's so draining. IMO someone organizing / fronting a meeting should fine tune the agenda of a meeting so that it's maximally relevant to everyone attending. Anything that is more broadcasting / announcement / "for your information" should be done async, not just because people want to skip a meeting but also because they may be absent, sick, living in another timezone, or needing the information down the line.
dickersnoodle 1y ago
You missed the part of the process where the results of the meeting were summarized and made available so said engineers can look up the results and see what decisions were made.
bgro 1y ago
Just add an agenda. Every meeting. What is the topic. What will be covered. What decisions are being made. No deviations without a new meeting or at least they need a settling time before they become concrete and people need active followups if they’re absent. People also need to read agendas and be prepared and also know what context this is about. “Is JavaScript better than java” isn’t a valid meeting agenda item. What are you even talking about this isn’t a comparable question. Is your team confusing java and js? You need to add context to the meeting that appeals to every person in it. Not just the Java vs js project you’ve been dealing with as yourself and 2 other people and now this has escalated to 5 teams and a 20 person emergency impromptu call with the director. You need to slow down and give context. Explain that this is in the context of candidate interview questions and not live engineering code being deployed. Meetings also need to have a timeline. 5 min overview 30 min demo 15 mins questions. Don’t just ramble on in the overview for 50 minutes and then say oh I guess we’re over time but I have no conflicts so I’m just going to keep going. No. Other people have conflicts and now they can’t participate in the decisions section that you’re choosing to gatekeep by ambushing surprise information in a meeting. If the meeting was deemed necessary in the first place why would it suddenly not matter now? That should be on the agenda. Again. No surprise information. Don’t ambush people on the spot with hidden topics. Engineers working on database integrations don’t need to context switch to answer random request to walk through how css works in a repo that was last updated 8 years ago. This causes all work progress to be delayed and momentum reset and there’s multiple of these every day because of random vague meetings doing this. Managers are responsible by default here. They are at fault if their team feels they cannot waste time in meetings because their time is not being respected. They need to ensure their team is at meetings they have decisions to make. They need to make sure or at least help escalate people hosting meetings are sticking to the agenda and having clearly defined and scoped questions that aren’t random or going to get lost in a sea of noise.
ferguess_k 1y ago
If it's critical it should always go through emails. And you can always tag everyone in the team to read the email. TBH if they ignore the emails they would also ignore whatever new features mentioned in the meeting because their mind is absent.
marcosdumay 1y ago
Looks like your team isn't communicating the goals of your meetings well.
empath75 1y ago
> "I don't know how we're deciding on some of these critical product features" You shouldn't be using a single channel to make critical decisions and this stuff should be documented and people should have multiple ways to be part of the decision making process.
vb6sp6 1y ago
[dead]
Neywiny 1y ago
I've even had one coworker, higher level than me, get repeatedly praised for how they multitask so much. But I've had them countless times distracted during meetings, and then they get irate some time later. "I wasn't consulted" "nobody told me" "nobody asked me permission" "I don't remember that meeting." If I'm in a meeting and say "my plan is to kick the computer until it works", don't come to me 2 months later and say it was a stupid plan, and worse get upset that you weren't asked. The point of the meeting is to have a forum for everybody to weigh in if needed. Not just to charge the program for an hour while you okay candy crush or listen in on another meeting.

sokoloff 1y ago

Just tell ‘em that! We had an internal RFC comment/discussion meeting on a proposed engineering standard. In that exact meeting, a dev flipped out and expressed exasperation that they weren’t asked to comment on the proposal. In the exact meeting that was one in a series of opportunities to comment on the proposal…

robertlagrant 1y ago
Yes, this is pretty universal I think. Some people think software engineering in a team is writing code as much as possible, and doing anything else is bad.
skywhopper 1y ago
Did they get to read the RFC before the meeting? If they had access but didn’t use it, then this is out of line. But if they only got the RFC during the meeting when they were asked to comment, then flipping out is overboard but the feeling is understandable.
- sokoloff 1y ago
  Fair Q. It was a multi-week process where the doc was published/open for written comment and then we had a series of meetings for live discussion as well. The engineer in question just completely mis-read where we were in the process and thought this was being announced as a mandate in the one particular meeting.

bargainbin 1y ago

100% this. As some who’s regularly derided by his colleagues for “hating meetings”: I don’t “keep meetings to a minimum”, I “keep meetings to a benefit”. If I’ve called a meeting it’s because there’s a benefit to the instant vocal communication. If you’re not there, you’ve not attended the meeting, no matter which tools you use to record, transcribe or translate. Conversely, if I thought I didn’t need to be in a meeting, then I wouldn’t send a tool to gather stuff for me to then just ignore the tool output - because I don’t need it. These tools are a sign of cultural rot from both participants and the fact people are even making them shows deep flaws in how we communicate in the modern workplace.

coliveira 1y ago
No matter how they're used, AI companies will create the artificial need for every company and essentially every worker to use these tools, even if they're not needed.
pixl97 1y ago
>Conversely, if I thought I didn’t need to be in a meeting, then I wouldn’t send a tool to gather stuff for me to then just ignore the tool output - because I don’t need it. The only way you know that you didn't need to be at a meeting is to be at the meeting. Catch-22 is a fun game. With dictation tools and analysis you can have meeting notes and then you or AI search for things that might affect you so you can reach out and correct the record. Simply put in modern larger companies there is too much going on at any given time. Most companies of any size are made up many purchased companies and their applications that are kind of glued together into a corporate structure. You can blame culture rot on the participants, but most of the time they are being asked to do too much in a dysfunctional organization.

theamk 1y ago

I'd tell them directly.. "You were invited to the meeting on 2025-MM-DD to discuss this, but you did not show up, nor did you follow up with organizers later. Sorry, you've missed your opportunity to comment" Seems direct and uncontroversial, and IMHO most people react well at this.

pk-protect-ai 1y ago

That's the thing, these meetings are B.S. Engineers need a task, time to think, and write about the solution and its cost. Period. Talking in a room full of people who love to hear their own voices and love to stroke their egos does not actually help engineers do their job. When engineers need to communicate, they communicate with their colleagues. There are tools for such communications that do not require talking and immediate responses. Being reactive (which is what meetings enforce you to do) costs more, as reactive and forced responses will be far more technically unsound.

zdragnar 1y ago
Feature development is rarely so cut and dry that you can hand a developer a task and let them run with it. To get there, you need a confluence of context and expertise from several domains: - what problem needs to be solved (user story) - what options are available (interaction design, technical capabilities) - what the cost of implementing each option is, and the opportunity cost of each level of implementation / each option (technical capability, resource management, sales, user research) - managing group consensus on the path forward (communication to technical and non-technical audiences) - break down of any large chunks of work into smaller tasks that can be done and planning the work to be done in series or parallel (resource management, technical capabilities) Finally, after all of that, you have a task (or several) that can be handed off. There's really no way to get here without at least some thought into the implementation details, as the business can't make the decision on which options without knowing rough timelines.
- pk-protect-ai 1y ago
  Excellent, this all can be written, thought over and discussed in written form. I do not see how this all requires a meeting.
woah 1y ago
> Engineers need a task, time to think, and write about the solution and its cost. Period. Talking in a room full of people who love to hear their own voices and love to stroke their egos does not actually help engineers do their job. When engineers need to communicate, they communicate with their colleagues. Seems like when you say "engineers", you mean "people with my exact personality"

jbc1 1y ago

Even if the final nod of agreement happens in real time the actual decision making process for critical product features should involve planning, thinking, research, etc. There should be a strong paper trail such that everyone knows what the decision is going to be prior to the "everyone gets together and declares this is how things are going to be" step. If them missing some meetings means they're in the dark as to how those features were decided on then I can't see that as a defence of attending every meeting so much as a statement of BS meetings being so predominant in the company that all decisions are made through a BS process.

MrJohz 1y ago
This might not be quite what the previous poster meant, but in my experience it's often not that the developer missed a meeting and now doesn't know some critical piece of information. Rather, it's often that the developer has some knowledge about the code that changes how something should be implemented. Because they weren't at the meeting, nobody else knew about this, and it's only later, when the developer sits down to write the code, that everyone finds out. In this case, there's nothing to document from the meeting because the information wasn't shared in the first place. The information could only have been shared if the developer had been in the meeting. (FWIW, I've rarely seen this from a developer not being in a meeting entirely, but I've seen it a few times where a developer has treated the meeting as a "read-only" event, i.e. expected that other people provide all the requirements and not used their own expertise or experience of the code to push back on decisions.)
- coliveira 1y ago
  The point in the parent comment still stands. There should be a paper trail so that the developer would have to confront the need to add such a detail. If the decision was made in the meeting alone, then it was lost in time as not all developers can be expected to be in every meeting.
  - scott_w 1y ago
    How? Meeting notes can never contain all the detail of the meeting and, if they do, there would be so much content that you'd likely miss them when you read the documentation. That's to say nothing of the time investment of the person to catch up on every document produced. In that case, you're essentially relying on the people in the meeting to know they should document that thing as important which, given the person who knows it's important isn't there, is pretty unlikely. Even in an ideal world, we'll have developers not in the meetings they need to be in. My contention would be that we should try to get people in the right meetings and, over time, the number of issues where someone isn't in the right meeting will be lower than if we just don't have those meetings.

8note 1y ago

but i didnt get invited to the meeting in the first place! and i dont think my management chain was either!

david-gpu 1y ago

It is helpful to communicate in advance what is the specific agenda of each meeting, so that people can make an informed decision on whether to attend. Also, it may be helpful to have the meeting organizer send meeting notes after every meeting, including action items assigned to specific people. The notes don't need to be extensive, but there better be an executive summary of what decisions were made, if any, and any unexpected roadblocks that were found. That's how things were done at one of the mega corps where I was employed and it worked great.

Aeolun 1y ago

> and I don't know how to tell them its because they skipped some meetings where they could've been part of that discussion. That there was a meeting where that decision was made between 55 minutes of crud doesn’t really mean anything to me though. I’m not wasting an hour of my day every day on the off chance today’s meeting will contain anything of importance.

woah 1y ago
Then just implement it I guess

grogenaut 1y ago

I had an engineer once show up to the re-scheduled "lets get the engineers ideas meeting before the yearly plan ships" meeting that we scheduled so they could be there who then proceeded to spent 15 minutes complaining how they didn't get any input before finally asking what the meeting was for, and finding out they had 45 minutes remaining to give feedback (they had skipped the meeting the previous day, and I wanted to make sure they gave their impact). (I tried to interject earlier but was asked "please let me talk" so I did).

ralferoo 1y ago
Why didn't you put "lets get the engineers ideas meeting before the yearly plan ships" as the meeting topic in the invite then? Otherwise you're expecting a whole load of people to turn up for a meeting with no idea what it's for. If you don't tell people what the meeting is for, you're implicitly saying that they don't need to know the topic until they arrive, and so you're signaling that they're not expected to be giving input and they're just there to listen to something - and in 90% of such meetings, they could be done better by e-mail. If you wanted feedback from the engineers, giving them a heads-up that this was their opportunity would have given them time to form their ideas into a succinct coherent point rather than an off-the-cuff ramble.

esskay 1y ago

> But then there's those engineers who don't show up to meetings and then a month later come to you with a >"I don't know how we're deciding on some of these critical product features" You write up meeting notes, tasks, etc right? If you've got engineers who are unaware of functionality because of a verbal meeting being missed you've got deeper problems to address.

maccard 1y ago
Not OP but yes and those meeting notes are turned into tasks with callbacks to the meeting they came from. Yet we still get the “where do these priorities come from” questions. You’re not asking for meeting notes you’re asking for a transcription which has the same problem as an email - people don’t read rhem

Cthulhu_ 1y ago

> But then there's those engineers who don't show up to meetings and then a month later come to you with a > > "I don't know how we're deciding on some of these critical product features" > > and I don't know how to tell them its because they skipped some meetings where they could've been part of that discussion. What else was discussed in these meetings? Was everything in there relevant to this one developer? This is what I find an issue in a lot of meetings, the majority is just not relevant to me; do I need to spend an hour of my time and attention span just in case there is something relevant? It's so draining. IMO someone organizing / fronting a meeting should fine tune the agenda of a meeting so that it's maximally relevant to everyone attending. Anything that is more broadcasting / announcement / "for your information" should be done async, not just because people want to skip a meeting but also because they may be absent, sick, living in another timezone, or needing the information down the line.

dickersnoodle 1y ago

You missed the part of the process where the results of the meeting were summarized and made available so said engineers can look up the results and see what decisions were made.

bgro 1y ago

Just add an agenda. Every meeting. What is the topic. What will be covered. What decisions are being made. No deviations without a new meeting or at least they need a settling time before they become concrete and people need active followups if they’re absent. People also need to read agendas and be prepared and also know what context this is about. “Is JavaScript better than java” isn’t a valid meeting agenda item. What are you even talking about this isn’t a comparable question. Is your team confusing java and js? You need to add context to the meeting that appeals to every person in it. Not just the Java vs js project you’ve been dealing with as yourself and 2 other people and now this has escalated to 5 teams and a 20 person emergency impromptu call with the director. You need to slow down and give context. Explain that this is in the context of candidate interview questions and not live engineering code being deployed. Meetings also need to have a timeline. 5 min overview 30 min demo 15 mins questions. Don’t just ramble on in the overview for 50 minutes and then say oh I guess we’re over time but I have no conflicts so I’m just going to keep going. No. Other people have conflicts and now they can’t participate in the decisions section that you’re choosing to gatekeep by ambushing surprise information in a meeting. If the meeting was deemed necessary in the first place why would it suddenly not matter now? That should be on the agenda. Again. No surprise information. Don’t ambush people on the spot with hidden topics. Engineers working on database integrations don’t need to context switch to answer random request to walk through how css works in a repo that was last updated 8 years ago. This causes all work progress to be delayed and momentum reset and there’s multiple of these every day because of random vague meetings doing this. Managers are responsible by default here. They are at fault if their team feels they cannot waste time in meetings because their time is not being respected. They need to ensure their team is at meetings they have decisions to make. They need to make sure or at least help escalate people hosting meetings are sticking to the agenda and having clearly defined and scoped questions that aren’t random or going to get lost in a sea of noise.

ferguess_k 1y ago

If it's critical it should always go through emails. And you can always tag everyone in the team to read the email. TBH if they ignore the emails they would also ignore whatever new features mentioned in the meeting because their mind is absent.

marcosdumay 1y ago

Looks like your team isn't communicating the goals of your meetings well.

empath75 1y ago

> "I don't know how we're deciding on some of these critical product features" You shouldn't be using a single channel to make critical decisions and this stuff should be documented and people should have multiple ways to be part of the decision making process.

vb6sp6 1y ago

[dead]

Neywiny 1y ago

I've even had one coworker, higher level than me, get repeatedly praised for how they multitask so much. But I've had them countless times distracted during meetings, and then they get irate some time later. "I wasn't consulted" "nobody told me" "nobody asked me permission" "I don't remember that meeting." If I'm in a meeting and say "my plan is to kick the computer until it works", don't come to me 2 months later and say it was a stupid plan, and worse get upset that you weren't asked. The point of the meeting is to have a forum for everybody to weigh in if needed. Not just to charge the program for an hour while you okay candy crush or listen in on another meeting.