Thanks for putting these thoughts together @erlend_sh.
If a Close Enough consensus can’t be reached within a reasonable span of time, we’d rather end a discussion promptly and revive it later
I think it’s important to emphasize that making decisions quickly and efficiently does not need to imply the end to a discussion.
[Within the team,] knowing nothing is personal, we cut to the chase. This is the norm in our day-to-day dialogue, and we’re better communicators for it.
We feel so at home on Meta that we tend to speak in the same manner there as we do when addressing one another. We probably shouldn’t do that.
That’s fine and completely understandable. As a small team, you have limited hours and resources to devote to productive work, and can only spend so much time discussing it. @codinghorror often exemplifies an important characteristic that I feel many Product Managers are lacking: encouraging people to really defend their ideas.
But the discussion shouldn’t be discouraged, in my opinion, even if the idea is opposed. As a team member, if it becomes a drain on your time, I think there are other ways you can excuse yourself from the discussion while making the current position of the team clear.
But as a community, our resources are not as limited.
Some of us do not have the skills to contribute directly to the project, so talking about our ideas is our form of contribution.
Seen that way, our breaths and hours are not the ones you need to worry about wasting.
And for those of us with the skills to contribute, it’s not always clear how best to do so.
Which features are “pr-welcome”? Which are “plugin-material”? Which ones go against what the team wants to see in the product vs. just don’t have the time and attention to spend on?
Finally, it’s worth mentioning that you guys have made great strides to improve this over the time I’ve been participating here.
And it’s clear that you are making a more concerted effort to do so since you joined the team. Keep up the good work!