CEA has long had the concept of "who owns this ball." I'm gonna have a hard time in this answer conveying exactly how much this has become a whole encompassing working philosophy for me.
Level 1: The alarm bells about dropped balls
If you are having a conversation and someone's like "we should do X"... Someone should really be the person owning the ball for doing (or not doing!) X.
If there's a "ball" (a task of some sort) that's sitting around and not moving forward, and anyone has any uncertainty about who's responsible for it, they should flag that.
Example: "Ok, who owns the ball of reaching out to GWWC?"
Level 2: Passing balls
Be extremely clear in your communication when you're handing off a ball to someone else, or taking on a ball. This prevents balls from getting dropped in the first place. We use dedicated emoji-jargon for this at CEA:
- 🏈 for handing off a ball
- 🤾 for catching a ball
Example: "I'm not sure what happened there, looks like a bug. 🏈 to you to fix?"
Level 3: Systems that prevent dropped balls
We have a round robin system in our code reviews, to make sure that each code review is assigned to a single reviewer, who knows that it's their job to review that code. The reviewer then assigns the task back to the original developer to address comments and/or merge the code. The code review can literally never be in an ambiguous state. (Ideally anyway. Human be humans, and it happens.)
Both our developers and our moderators has the concept of an "on-call" rotation, both developed by me. Quoting from the moderator on-call doc:
You should be aiming to ensure an efficiently running ship. It’s your job this week to make sure that everything’s running smoothly. That does not mean doing everything yourself. But this week, the buck of dropped balls does stop with you.
I think I've done a fair job of communicating the type of thing I mean, but it really goes quite deep and broad for me. As I predicted, moreso than this suggests.