Productive Disagreements Ask v Guess • Ask - it’s fine to ask for anything but you may be told no as an answer • Guess - avoid requests unless you are sure the answer will be yes
Productive Disagreements Personality & Customs • Type of environment brought up in - cultural and caregiver norms • Natural tendencies to ask/guess; wanting to move forward v not wanting to offend • Explicit v implicit in communications
Productive Disagreements Company Culture • Trust in the team. Trust in the leadership. Psychological safety can affect how anyone behaves. • Already established (cultural) norms on how to interact, ask for advice, learn, collaborate. • How much of a top down “tell” setup the company has.
Productive Disagreements Key Aspects • Curiosity - ask questions • Empathy - put yourself in the recipients shoes • Cultural sensitivity - be mindful of the experiences others may have had before now • Openness - be ready to learn, but also to share your knowledge/opinion
Productive Disagreements Knowing Limits • Times to speak up and when to let things go • Be realistic • What do you want to get out of the disagreement if you do speak up?
Productive Disagreements Build Relationships Never forget that there are more humans involved in the disagreements. A positive disagreement can move you both forward. It creates and builds relationships that make further communication easier.
Productive Disagreements Cheat Sheet •Provide links to anything you might reference. Provide reasoning or examples where appropriate. •Share knowledge you’ve picked up as you explain why something could be improved •If something is great say so! Positive feedback is as valuable as things that need a little more refinement. •Make suggestions that are actionable, or be clear if a suggestion can be ignored. •Treat a review as a conversation •Ask questions. Try and learn without judgement. Questions foster discussion. Statements foster debate. If the answer comes back as something you think is not great in the code, then approach that situation but don’t assume from the outset. •For things which must be changed, focus on the code and the problem being solved, not the author. Use suggestions and specifics to guide what you feel needs to be done. •Answer questions the PR author might have raised if they are asking for specific input
krider2010
dpys
mirie_sd
ange
scalar
tdys13
nrinetcom
lycorp_recruit_jp
shintaro_fukatsu
fnifni
%20zoom.jpeg){kind=avatar}
avosalmon
shingo_kawahara
yositosi
destraynor
lauravandoore
chrisshort
brettharned
brad_frost
speakerdeck
stephaniewalter
yeseniaperezcruz
sferik
ammeep
nonsquared
jmmastey
