• Engineers can't understand what users want
• Engineers can make some inappropriate solution
• Rollback occurs

• Keep to ask questions repeatedly until you completely understand.
• Ask for opinions to sales team if your task is related to sales side or clients.
• Clarify the definition of technical terms, make and share a document the definitions for understanding of another teams
• Prepare a document for the concrete instruction before the meeting, and left a memo about next action.

Sometimes, people are so concerned about the other person that they don't give accurate information

• For the sender:
  • Please be specific about your message and don't worry about how the recipient feels.
  • In PRs, you should communicate the importance of the fix. e.g. [MUST], [SHOUD], [MAY]
  • You can check the progress periodically to avoid misunderstanding of the receiver.
  • You can use emojis to make a good mood.
• For the receiver
  • Understand that your sender care about accuracy for you

• Engineers doesn't know what went wrong and loses confidence.
• Engineers degrade the quality of the work they do.
• Engineers stop trying to communicate things.

• Politely explain the context and make sure they understand what's wrong when you reject a PR.
• Praise the good points in the PR.
• Don't ignore it and react when someone does something.

• Spent too much time developing on wrong/not-intuitive design and later it turns out that this is not customers want.

• Ask user's feedback (internal / external) as early as possible.
• Don't spend too much time on less important details before getting feedback.
• Iterating design only is much cheaper than redoing development and QA work.

• Guildeline is updated but not everyone is aware of that.
• Mentor needs to explain the same thing repeatedly for new joingers.
• Information scatters across different places (GitHub, Notion, Goodle Docs, Slack, etc.).
• Waste of time to search for information.

• "You should be able to find the information by yourself by looking at XXX".
• "Before asking questions, search XXX by yourself."

• Probably we're not doing great job here today.
• Creating a meta guildeline for guildeline? How to write guideline and how to search for guideline?

• The same question repeatedly asked and answered.
• Problems don't get exposed before they become huge.

• Ask questions in dev channel instead of asking via DM.
• Share what you're going to do with others as early as possible to catch potential mistakes and/or course correct.

• (pretty much the same for #7).

• Focus on higher priority part and hand wave lower priority part, which is just good enough for getting feedback.
• Make MVP first.
• When you feel you get stuck, seek for brainstorming and other's input. Just summarizing problems for others might help you sometimes.