Ask HN: How to be a better contributor in meetings | Hacker News Reader

Ask HN: How to be a better contributor in meetings

7 pointsJackMiaguer7 comments

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?

View on HN

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

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

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

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

Come to meetings prepared. If it's a meeting where you need to generate ideas or suggestions, do your own brainstorming first.

My suggestion is to read Parkinson's law. Not everyone needs to contribute something every time. Some meetings include too many people anyway.

Recycling some replies. More context on 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 (understanding codebases, etc.)

- https://news.ycombinator.com/item?id=26591067 (testing pipelines, scaffolding, issue templates)

- https://news.ycombinator.com/item?id=22873103 (making the most out of meetings, leveraging your presence)

- https://news.ycombinator.com/item?id=22827841 (product development)

- https://news.ycombinator.com/item?id=20356222 (giving a damn)

- https://news.ycombinator.com/item?id=25008223 (If I disappear, what will happen)

- 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 (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 (product, architecture, and impact on the team)

- 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 (being efficient learning from video, hacks. Subsequent reply: https://news.ycombinator.com/item?id=22723586)

- 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=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 (communication, alignment)

- https://news.ycombinator.com/item?id=21808439 (useful things for the team and product that add leverage)

- 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 (management involvement as a spectrum)

- https://news.ycombinator.com/item?id=25922120 (researching topics)

- https://news.ycombinator.com/item?id=26147502 (keeping up with a firehose of information)

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

Reply on news.ycombinator.com