CEA has long had the concept of “who owns this ball.”[1] 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.
I wrote this answer, and then realized I needed to give a shout out to @Amy Labenz and the events team, who really embody the spirit of this philosophy. Amy at one point bought like 40 styrofoam balls and had CEA write tasks they were worried might be getting dropped on them, and then we went around finding an owner for the balls, or deciding to drop them by choice.
For me full-time work(military) there are certain safety regulations regarding when things need to happen and who needs to sign off on them so they can go ahead. A recent example is when we had an emerging requirement that needed a general to sign off on something otherwise six months of planning for an event would be out the window. The general was out of our chain of command and thus wouldn’t need us to do the thing we needed, it would just be good training for his people. We had a requirement, they had a requirement and something got lost in the translation, causing us to either make several high-level phone calls or drop the glass ball.
CEA has long had the concept of “who owns this ball.”[1] 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:
***
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.
I wrote this answer, and then realized I needed to give a shout out to @Amy Labenz and the events team, who really embody the spirit of this philosophy. Amy at one point bought like 40 styrofoam balls and had CEA write tasks they were worried might be getting dropped on them, and then we went around finding an owner for the balls, or deciding to drop them by choice.
Strong agree! I really like how passing balls works in practice in the forum moderation Slack, it gives energy/momentum instead of draining it.
A small nitpick is that 🤾 to me looks like someone throwing a ball, and I would use ⛹️
When I met my boss he has a different but related theory. It’s about the steel ball, rubber ball and glass ball.
The steel ball you can drop and it won’t break, but you need to pick it up to keep going.
The rubber ball you can keep bouncing down the line.
The glass ball, once broken can’t be fixed.
You have to identify which item is which.
I like this
Anyone mind giving an example for a glass ball?
For me full-time work(military) there are certain safety regulations regarding when things need to happen and who needs to sign off on them so they can go ahead. A recent example is when we had an emerging requirement that needed a general to sign off on something otherwise six months of planning for an event would be out the window. The general was out of our chain of command and thus wouldn’t need us to do the thing we needed, it would just be good training for his people. We had a requirement, they had a requirement and something got lost in the translation, causing us to either make several high-level phone calls or drop the glass ball.
Thanks!