|
| ▲ | jbc1 2 days ago | parent | next [-] |
| 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 2 days ago | parent | next [-] | | 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 2 days ago | parent [-] | | 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 a day ago | parent | next [-] | | 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. | |
| ▲ | MrJohz a day ago | parent | prev [-] | | If decisions are being made about the code or implementation, then the person working on that code should be in that meeting, surely. Otherwise there's no point making that decision. |
|
| |
| ▲ | pj_mukh a day ago | parent | prev | next [-] | | I realize introverts don't work that way, I know, I am one. But I've had some of the most brilliant ideas come through purely on a discussion nay sometimes an emotionally charged argument. Important decisions are almost never 2+2=4, if they were, they wouldn't be important and yes you wouldn't need a meeting (like I admitted, there's definitely a lot of unimportant meetings). But important decisions are almost always an exercise in coaxing, cajoling and persuasion, which is just extremely low fidelity on paper. Most engineers will look at their team leads and say "I don't believe in this strategy on paper", and all their team leads can say is "I was at the meeting. You had to be there" | | |
| ▲ | Propelloni a day ago | parent [-] | | I'm an introvert, too. I have no troubles participating in, or leading, or even fighting in group activities. Does it exhaust me? Yes, it does. I literally feel physical pain if I have to stay in company for more than maybe an hour. But value is created through interaction, not some process, paper stacks, or a lone wolf hiding in the closet, so I learned a long time ago how to communicate effectively, give and take feedback, organize tight meetings, and facilitate decision making. I'm actually a bit tired of introverts hiding behind their disposition. You can do something about it, and it's more than complaining. EDIT: Sorry, that was more rantish than I wanted. But I'll leave it here anyway. |
| |
| ▲ | sneak 2 days ago | parent | prev [-] | | Most people in meetings don’t type very fast, and find it easier to talk than to write. This means that prior to AI transcription/summary bots, there wasn’t much written documentation about the decisions and conclusions from meetings. Now hopefully that will change. | | |
| ▲ | a_bonobo a day ago | parent | next [-] | | In my org we have rotating minutes takers - it effectively takes them out of the meeting, but they do pipe up if an issue affects them directly. Of course people's meeting taking skills vary widely but I still find the human-made minutes far superior and accurate to whatever Copilot cooks up. | |
| ▲ | jbc1 2 days ago | parent | prev | next [-] | | I wasn't so much saying that there should be plenty of documentation generated during a meeting as saying that there should be plenty of documentation prior to the meeting. That the meeting is based on. | |
| ▲ | Cthulhu_ a day ago | parent | prev [-] | | I've also read a thing (dunno if it was opinion or fact) that posited that people's reading ability is directly correlated to a preference for video, I suspect it's the same with meetings. I read / write all day (including on here lmao), meetings are draining in comparison. But the people in those meetings don't read / write nearly as much as I do. I did once think that if the meeting were to be transcribed, people are outputting paragraphs of text in a short amount of time, just verbally. But keeping up with that is pretty draining, as you have to listen and process it, whereas with reading you can skim and re-read things easily. I sometimes think people's basic skills - reading and typing - are underdeveloped or not assessed, and they should be assessed when applying for a job that involves reading and typing. But I don't even think people consider reading/writing skills when looking for staff since the assumption is that everyone's is good enough. | | |
| ▲ | sneak a day ago | parent [-] | | I administer reading comprehension tests and typing speed tests to all candidates I consider hiring. It’s overlooked. Good ones who can’t type fast, I assign them typing lessons their first few paid days on the job, and a half hour twice a week thereafter for a while. I’m an outlier and can type 120wpm without trying very hard, but I expect 40-50wpm (touch typing, not hunt and peck) at a minimum from staff that work with computers and aren’t disabled. |
|
|
|
|
| ▲ | bargainbin 2 days ago | parent | prev | next [-] |
| 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. |
| |
| ▲ | pixl97 a day ago | parent | next [-] | | >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. | |
| ▲ | coliveira 2 days ago | parent | prev [-] | | 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. |
|
|
| ▲ | david-gpu 2 days ago | parent | prev | next [-] |
| 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. |
|
| ▲ | Neywiny 7 hours ago | parent | prev | next [-] |
| 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 2 days ago | parent | prev | next [-] |
| 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 2 days ago | parent | next [-] | | 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 2 days ago | parent | prev [-] | | 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 a day ago | parent [-] | | 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. |
|
|
|
| ▲ | grogenaut 2 days ago | parent | prev | next [-] |
| 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 a day ago | parent [-] | | 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. |
|
|
| ▲ | Aeolun 2 days ago | parent | prev | next [-] |
| > 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. |
| |
|
| ▲ | theamk 2 days ago | parent | prev | next [-] |
| 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. |
|
| ▲ | esskay a day ago | parent | prev | next [-] |
| > 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 a day ago | parent [-] | | 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 |
|
|
| ▲ | ferguess_k a day ago | parent | prev | next [-] |
| 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. |
|
| ▲ | Cthulhu_ a day ago | parent | prev | next [-] |
| > 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. |
|
| ▲ | bgro a day ago | parent | prev | next [-] |
| 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. |
|
| ▲ | marcosdumay a day ago | parent | prev | next [-] |
| Looks like your team isn't communicating the goals of your meetings well. |
|
| ▲ | 8note 2 days ago | parent | prev | next [-] |
| but i didnt get invited to the meeting in the first place! and i dont think my management chain was either! |
|
| ▲ | dickersnoodle a day ago | parent | prev | next [-] |
| 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. |
|
| ▲ | empath75 a day ago | parent | prev | next [-] |
| > "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. |
|
| ▲ | pk-protect-ai 2 days ago | parent | prev | next [-] |
| 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 2 days ago | parent | next [-] | | 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 2 days ago | parent [-] | | Excellent, this all can be written, thought over and discussed in written form. I do not see how this all requires a meeting. |
| |
| ▲ | woah 2 days ago | parent | prev [-] | | > 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" | | |
|
|
| ▲ | vb6sp6 20 hours ago | parent | prev [-] |
| [dead] |
