In this episode, Dave and Jamison answer these questions:

How do you politely tell a reviewer politely, “Your suggestion is stupid. I will not do it” when you get stupid review comments. If you don’t do it then the pull request can’t move forward because of unresolved issues. If you do it, then you’re compromising your design you’ve worked weeks on for some fly-by random comment.
A few months back, I volunteered as co-facilitator for my department’s NodeJS Guild meeting. At first, it was a struggle to get people to present. But I tried to lower the bar more and more until it was easy. I asked for 10-15m presentations, and eventually I realized people are happier “Kicking off a discussion” than they are “giving a presentation”. All the listeners are more engaged too, at least after the first 2 meetings doing this.

Now I want people to share half-baked code, or problems they are struggling with, as part of our discussions. I want people to be able to be vulnerable. If we don’t collaborate on common problems until we feel they’re polished and won’t reflect badly on us, then we will all waste time solving the same problems.

I also want this to scale across 15-25 small scrum teams. I think success could be my demise–if we have good discussions, then more people will come, but people won’t want to be as vulnerable with a larger group.

In general, I think my own scrum team is very open and vulnerable to each other, but the remote work in the deparment has created distance. I want to help create more collaboration on similar problems and solutions.

What would you do to keep this going, and improve it?

Episode 321: Politely, no and participation at scale 30:01 Share

Soft Skills Engineering

Shownotes Transcript

Episode 321: Politely, no and participation at scale