I have a classic rationality comment on the EA Forum that’s reasonably popular. I thought I’d crosspost here. The context is “What are work practices that you’ve adopted that you now think are underrated?”
***
CEA (my employer) 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 @amywilley and the (CEA) 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.
This is also called “tickets”. Tickets for tasks that happen repeatedly can have a workflow assigned to them, which can be as simple as a linear sequence of steps, but also more complex, and you can have a software that tracks them. Like, you click a button on your smartphone, and it will show you a list of tickets currently assigned to you, maybe also ordered by priority. When you move the ticket to someone else, it disappears from your list and immediately appears on their list. So the tasks are always remembered and always have a person assigned, until they get closed.
Tickets are usually used for predictable, repetitive tasks with known workflow. But nothing prevents you from creating a generic “workflow” containing only one step “solve the problem”, and using it for everything else.
When a new ticket is created, unless the owner is specified explicitly, the system should automatically assign it to someone. Then you just need the person “on call” who registers everything that happens, and creates a new ticket for that.
There are commercial solutions, such as the infamous Atlassian Jira (most companies use it, most users hate it with a passion), or free solutions… I don’t know what is currently the state of art. There is a list on Wikipedia.
I think every organization should use something like this; many individuals would probably also benefit from a personal ticket system. But there is an overhead with setting up the system (installing the software, setting up the workflows). Not sure of there is an online system where one could just register and start using it… if there is, someone please give me a link; if there is not, sounds like a business opportunity.
If you understand how the system is supposed to work, you could implement a poor man’s version using a spreadsheet. Each row is a ticket. Columns: ticket id, who is it assigned to, workflow type, workflow phase, description. Maybe create a wiki page for each ticket, and have it linked from the spreadsheet.
We use Asana for this. (It’s broadly great, and I don’t understand how Jira isn’t getting its lunch completely eaten. And I’m not just saying that because of my funder.)
I agree with a lot of this, though I think the mental attitude here is still extremely useful. For example, you may be dealing with something outside of your usual ticket system, or a ball may be smaller than something that would justify an Asana ticket.
My model of Atlassian business model goes like this: Take a popular open-source product, and make a crappy version of it with half the functionality and inconsistent UI, but make it possible to create plugins and sell them at your marketplace (where you take a cut). Then sell it for lots of money, and when anyone asks whether it has some functionality X, say “there is a marketplace with many plugins, I am sure there are many high-quality implementations of X”. Write in the contract that you only provide support for the basic installation without any plugins; if plugins are installed, proper functioning of the system is no longer your responsibility, and the customer should call the author of the plugin instead!
This seems to somehow work in practice. On one hand, you can check the checkbox “we provide support”, and also check the checkbox “our product supports X” when someone makes a plugin for X (so you soon provide more functionality than the original open-source project you copied… so when someone later proposes to replace your product with open-source, some manager will ask “but does the open-source solution provide integration with SharePoint?” or something like that), but when the customer installs the plugin for X, the support is no longer your problem. In theory, your product can be configured to do anything, but in practice, the customer is supposed to configure it in their own time, which most customers will refuse to do (somehow, spending $100,000 to buy your software is okay, but spending $10,000 to pay their employee his salary until he figures out how to configure it properly is not), so most customers will use the default settings, or the default settings plus a plugin. (And the integration with SharePoint does not work anyway, but no one is complaining about that, because the people who actually use the software do not care about SharePoint integration.)
This is too cynical, but I haven’t heard a better explanation that would fit the known data.
I have a classic rationality comment on the EA Forum that’s reasonably popular. I thought I’d crosspost here. The context is “What are work practices that you’ve adopted that you now think are underrated?”
***
CEA (my employer) 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 @amywilley and the (CEA) 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.
This is also called “tickets”. Tickets for tasks that happen repeatedly can have a workflow assigned to them, which can be as simple as a linear sequence of steps, but also more complex, and you can have a software that tracks them. Like, you click a button on your smartphone, and it will show you a list of tickets currently assigned to you, maybe also ordered by priority. When you move the ticket to someone else, it disappears from your list and immediately appears on their list. So the tasks are always remembered and always have a person assigned, until they get closed.
Tickets are usually used for predictable, repetitive tasks with known workflow. But nothing prevents you from creating a generic “workflow” containing only one step “solve the problem”, and using it for everything else.
When a new ticket is created, unless the owner is specified explicitly, the system should automatically assign it to someone. Then you just need the person “on call” who registers everything that happens, and creates a new ticket for that.
There are commercial solutions, such as the infamous Atlassian Jira (most companies use it, most users hate it with a passion), or free solutions… I don’t know what is currently the state of art. There is a list on Wikipedia.
I think every organization should use something like this; many individuals would probably also benefit from a personal ticket system. But there is an overhead with setting up the system (installing the software, setting up the workflows). Not sure of there is an online system where one could just register and start using it… if there is, someone please give me a link; if there is not, sounds like a business opportunity.
If you understand how the system is supposed to work, you could implement a poor man’s version using a spreadsheet. Each row is a ticket. Columns: ticket id, who is it assigned to, workflow type, workflow phase, description. Maybe create a wiki page for each ticket, and have it linked from the spreadsheet.
We use Asana for this. (It’s broadly great, and I don’t understand how Jira isn’t getting its lunch completely eaten. And I’m not just saying that because of my funder.)
I agree with a lot of this, though I think the mental attitude here is still extremely useful. For example, you may be dealing with something outside of your usual ticket system, or a ball may be smaller than something that would justify an Asana ticket.
My model of Atlassian business model goes like this: Take a popular open-source product, and make a crappy version of it with half the functionality and inconsistent UI, but make it possible to create plugins and sell them at your marketplace (where you take a cut). Then sell it for lots of money, and when anyone asks whether it has some functionality X, say “there is a marketplace with many plugins, I am sure there are many high-quality implementations of X”. Write in the contract that you only provide support for the basic installation without any plugins; if plugins are installed, proper functioning of the system is no longer your responsibility, and the customer should call the author of the plugin instead!
This seems to somehow work in practice. On one hand, you can check the checkbox “we provide support”, and also check the checkbox “our product supports X” when someone makes a plugin for X (so you soon provide more functionality than the original open-source project you copied… so when someone later proposes to replace your product with open-source, some manager will ask “but does the open-source solution provide integration with SharePoint?” or something like that), but when the customer installs the plugin for X, the support is no longer your problem. In theory, your product can be configured to do anything, but in practice, the customer is supposed to configure it in their own time, which most customers will refuse to do (somehow, spending $100,000 to buy your software is okay, but spending $10,000 to pay their employee his salary until he figures out how to configure it properly is not), so most customers will use the default settings, or the default settings plus a plugin. (And the integration with SharePoint does not work anyway, but no one is complaining about that, because the people who actually use the software do not care about SharePoint integration.)
This is too cynical, but I haven’t heard a better explanation that would fit the known data.
Sounds like a plugin-centric version of embrace and extend.
This is pretty great and I think honestly makes a good top-level post (albeit with maybe some fleshing out)