5 ms·
Ask HN: How to be a better contributor in meetings
I've always been a person that works better by myself. That is not to say that I don't like bouncing ideas of other people, but I tend to think a lot better when I'm alone and focused.
This is somewhat harmful during design meetings as I feel like I'm not contributing enough because my brain doesn't work like that. Most of the time, when scrambling for ideas my brain just comes out with a blank.
Did anyone suffer from this problem and how did you fix it?
- Graffur 6y agoCome to meetings prepared. If it's a meeting where you need to generate ideas or suggestions, do your own brainstorming first.
- afarrell 6y agoFocus on “What is is a high value question that’s not getting asked?” Questions matter more than answers and if you ask clear ones it can help people understand things.
- softwaredoug 6y agoI will just say, this isn’t just a “you” problem, but a “team” problem. I’m loud and opinionated in meetings. And frankly a good manager or senior dev should be thinking of directly soliciting thoughts from quieter members of the team (and shutting up the loud ones a bit). It’s on them to create an environment that feels safe for you to voice your thoughts and it’s also on them to give you encouragement. Of course it’s on you to have something to say. I think “I don’t know, let me think about it and get back to you” is probably one of the wisest things you could say. Quiet people, slow to opinion, can contribute a great deal this way. It also wouldn’t hurt to force yourself to do some public speaking. For example a friendly meetup or an internal team lunch and learn. These groups are most of the time very welcoming and grateful for any talks they can get. This will help build your confidence in group settings. Who knows, you might even grow to enjoy it?
- JackMiaguer 6y agoThanks for the insight. I don't really have a problem with public speaking, I actually enjoy it. The problem is my brain, which stops working even when prompted for insight.
- Jugurtha 6y agoRecycling some replies. More context on https://news.ycombinator.com/item?id=26182988 https://news.ycombinator.com/item?id=26182988: Pick and choose (especially meeting notes, alignment, and the links on the bottom about video calls): - https://news.ycombinator.com/item?id=19924100 https://news.ycombinator.com/item?id=19924100 (understanding codebases, etc.) - https://news.ycombinator.com/item?id=26591067 https://news.ycombinator.com/item?id=26591067 (testing pipelines, scaffolding, issue templates) - https://news.ycombinator.com/item?id=22873103 https://news.ycombinator.com/item?id=22873103 (making the most out of meetings, leveraging your presence) - https://news.ycombinator.com/item?id=22827841 https://news.ycombinator.com/item?id=22827841 (product development) - https://news.ycombinator.com/item?id=20356222 https://news.ycombinator.com/item?id=20356222 (giving a damn) - https://news.ycombinator.com/item?id=25008223 https://news.ycombinator.com/item?id=25008223 (If I disappear, what will happen) - https://news.ycombinator.com/item?id=24972611 https://news.ycombinator.com/item?id=24972611 (about consulting and clients, but you can abstract that as "stakeholders", and understanding the problem your "client", who can be your manager, has.) - https://news.ycombinator.com/item?id=24209518 https://news.ycombinator.com/item?id=24209518 (on taking notes. When you're told something, or receive a remark, make sure to make a note and learn from it whether it's a mistake, or a colleague showing you something useful, or a task you must accomplish.. don't be told things twice or worse. Be on the ball and reliable). - https://news.ycombinator.com/item?id=24503365 https://news.ycombinator.com/item?id=24503365 (product, architecture, and impact on the team) - https://news.ycombinator.com/item?id=22860716 https://news.ycombinator.com/item?id=22860716 (onboarding new hires to a codebase, what if it were you, improve code) - https://news.ycombinator.com/item?id=22710623 https://news.ycombinator.com/item?id=22710623 (being efficient learning from video, hacks. Subsequent reply: https://news.ycombinator.com/item?id=22723586 https://news.ycombinator.com/item?id=22723586) - https://news.ycombinator.com/item?id=21598632 https://news.ycombinator.com/item?id=21598632 (communication with the team, and subsequent reply: https://news.ycombinator.com/item?id=21614372 https://news.ycombinator.com/item?id=21614372) - https://news.ycombinator.com/item?id=21427886 https://news.ycombinator.com/item?id=21427886 (template for taking minutes of meetings to dispatch to the team. Notes are in GitHub/GitLab so the team can access them, especially if they haven't attended). - https://news.ycombinator.com/item?id=24177646 https://news.ycombinator.com/item?id=24177646 (communication, alignment) - https://news.ycombinator.com/item?id=21808439 https://news.ycombinator.com/item?id=21808439 (useful things for the team and product that add leverage) - https://news.ycombinator.com/item?id=20323660 https://news.ycombinator.com/item?id=20323660 (more meeting notes. Reply to a person who had trouble talking in corporate meetings) - https://news.ycombinator.com/item?id=22715971 https://news.ycombinator.com/item?id=22715971 (management involvement as a spectrum) - https://news.ycombinator.com/item?id=25922120 https://news.ycombinator.com/item?id=25922120 (researching topics) - https://news.ycombinator.com/item?id=26147502 https://news.ycombinator.com/item?id=26147502 (keeping up with a firehose of information) - https://news.ycombinator.com/item?id=26123017 https://news.ycombinator.com/item?id=26123017 (fractal communication: communication that can penetrate several layers of management and be relevant to people with different profiles and skillsets) - https://news.ycombinator.com/item?id=26179539 https://news.ycombinator.com/item?id=26179539 (remote work, use existing tooling and build our own. Jitsi videos, record everything, give access to everyone so they can reference them and go back to them, meetings once a week or two weeks to align)
- frompdx 6y agoMy suggestion is to read Parkinson's law. Not everyone needs to contribute something every time. Some meetings include too many people anyway.
- hkarthik 6y agoDon't force it. It's an in-person skill that some people simply don't have, and as an Engineering Manager, I honestly don't think its particularly valuable. I find the quiet folks often have the most valuable insights. Push for more pre-work before meetings with documents to encourage async discussion at your company. Be the person person that reviews and comments such documents to add insights, and then ensure the person running the design meeting prompts any left over comments while running the meeting, to cover your items. This is how most forward-looking, remote-friendly companies work now. If you're not in such an environment, then consider moving to one. It will probably work out better for you.