5 ms·

I find it rather humorous in reading the comments that this seems to have hit an interesting nerve, viz. being asked to perform [stupid] tasks for someone else

I find it rather humorous in reading the comments that this seems to have hit an interesting nerve, viz. being asked to perform [stupid] tasks for someone else and then being monitored and reminded intermittently in a passive way without clear communication. Sometimes there are good and important tasks whose importance is clearly communicated, but which go undone. But, in my experience, the majority of tasks like this might need to be either (1) better specified so that they can actually be understood and completed or (2) communicate better what the importance of the task is with an honest evaluation by both people and comparing to the value of other workload priorities at present. We have a tendency to believe that our task is the most important one right now, and that our ideas are the best ideas, without understanding what someone else is really doing and without taking an objective look at why something else could be more valuable. We can use that ourselves when we try to assign tasks to others. Are we being fair to them, their priorities, and their workload? Maybe our task isn't all that important? Maybe we can communicate better with them to understand the totality of what they value, or maybe what they think a better alternative to our task would be. After all, Alexander the Great asked his troops if they had any ideas for strategies... and he won a lot.

teilo 8y ago
This is what immediately came to mind. The OA missed the fourth reason why his Canary McGuffin wasn't touched: Maybe you, who gave the task, haven't clearly communicated the problem, or the solution you are looking for. Now who is to blame in that circumstance? Presuming it's not an issue of laziness, or incompetence, or of higher priorities trumping your request, why are you looking at your McGuffin instead of communicating with the person you assigned the task?
- Aeolun 8y ago
  I think it was quite clear in the story that they talked to the person they requested it off at least 3 times. Giving them ample opportunity to ask about any information they might be missing.
- komaromy 8y ago
  > his her
- rimliu 8y ago
  This goes both ways. If the person given the task is not sure what they are supposed to do they should ask. How can you spend weeks on doing something if don't know what you should achieve?
- taneq 8y ago
  Same, my thoughts went straight to the quest giver. After receiving a response of "getting there" or "it's tricky" for the third time, rather than sitting back and smugly speculating on the deficiencies of the adventurer while "nothing happens", maybe they should have asked "what's the problem?" I'm seeing a bit of a pattern in these blog posts, where the author is more interested in proving their superiority over others than in actually getting stuff done.
  - xamuel 8y ago
    >more interested in proving their superiority over others than in actually getting stuff done. I've noticed this happens a LOT in all kinds of meetings. I myself am guilty of it, so now I try to think before I speak, "if I raise this pedantic point, will that actually help further the team's goals?" Usually the answer is NO.
- vidarh 8y ago
  The starting point of the article is that she discovered a communications issue: For whatever reason her counterpart is giving misleading responses when she thought she was communicating with them. The point is that this "canary McGuffin" revealed there was an issue that talking to them didn't. That issue might be all kinds of things, including poor communication prior, but that's incidental to the fact that having an idea of how the tasks should proceed means you have a non-intrusive way of checking if their communication means what you think it does.
wpietri 8y ago
Her description strikes me as containing so many process problems. All of this could be avoided with a kanban-style process with clear WIP limits, a visible backlog, and small units of work with frequent releases. I guess the whole adventure thing rubs me the wrong way. It reminds me of one of my favorite bits from Rick and Morty: "The thing about repairing, maintaining, and cleaning is: it's not an adventure. There’s no way to do it so wrong you might die. It’s just work."
- vidarh 8y ago
  Two issues with this: 1. You're not always in a place to enforce process, so you may have no way of getting that visibility. 2. No matter the process, at some point you have a unit of work that people might answer "working on it" or "it's more effort than expected" or similar. The effect per unit of work may be lower if the unit of work is small, but it is still useful to think about how to get visibility when the communication is faulty (as it clearly is if someone is saying "working on it" when they've not even started). This can apply to a months long project or asking someone to do a task that should take an hour - it has nothing to do with the overall project management, and everything to do with validating your inputs.
  - wpietri 8y ago
    I partly agree on #1. Although if someone is in the position to request work, they're in the position to influence process, and to request discussion of process. So I think "no way" is too strong. I think #2 is definitely false. Last time I started a company we used a kanban board, strong WIP limits, daily stand-ups, pair programming with pair rotation once or twice a day, and units of work that averaged a day in size. We never had a need to distrust what somebody told us. Even without all that, if units of work are sufficiently small, task flow is transparent, and your WIP limits are sufficiently low, then there's no reason to be getting into people's business on a task-by-task basis. If there's a real problem, it will be visible at the normal scale. In my view, a good process doesn't demand trust. It creates it over time.
    - vidarh 8y ago

teilo 8y ago

This is what immediately came to mind. The OA missed the fourth reason why his Canary McGuffin wasn't touched: Maybe you, who gave the task, haven't clearly communicated the problem, or the solution you are looking for. Now who is to blame in that circumstance? Presuming it's not an issue of laziness, or incompetence, or of higher priorities trumping your request, why are you looking at your McGuffin instead of communicating with the person you assigned the task?

Aeolun 8y ago
I think it was quite clear in the story that they talked to the person they requested it off at least 3 times. Giving them ample opportunity to ask about any information they might be missing.
komaromy 8y ago
> his her
rimliu 8y ago
This goes both ways. If the person given the task is not sure what they are supposed to do they should ask. How can you spend weeks on doing something if don't know what you should achieve?
taneq 8y ago
Same, my thoughts went straight to the quest giver. After receiving a response of "getting there" or "it's tricky" for the third time, rather than sitting back and smugly speculating on the deficiencies of the adventurer while "nothing happens", maybe they should have asked "what's the problem?" I'm seeing a bit of a pattern in these blog posts, where the author is more interested in proving their superiority over others than in actually getting stuff done.
- xamuel 8y ago
  >more interested in proving their superiority over others than in actually getting stuff done. I've noticed this happens a LOT in all kinds of meetings. I myself am guilty of it, so now I try to think before I speak, "if I raise this pedantic point, will that actually help further the team's goals?" Usually the answer is NO.
vidarh 8y ago
The starting point of the article is that she discovered a communications issue: For whatever reason her counterpart is giving misleading responses when she thought she was communicating with them. The point is that this "canary McGuffin" revealed there was an issue that talking to them didn't. That issue might be all kinds of things, including poor communication prior, but that's incidental to the fact that having an idea of how the tasks should proceed means you have a non-intrusive way of checking if their communication means what you think it does.

wpietri 8y ago

Her description strikes me as containing so many process problems. All of this could be avoided with a kanban-style process with clear WIP limits, a visible backlog, and small units of work with frequent releases. I guess the whole adventure thing rubs me the wrong way. It reminds me of one of my favorite bits from Rick and Morty: "The thing about repairing, maintaining, and cleaning is: it's not an adventure. There’s no way to do it so wrong you might die. It’s just work."

vidarh 8y ago
Two issues with this: 1. You're not always in a place to enforce process, so you may have no way of getting that visibility. 2. No matter the process, at some point you have a unit of work that people might answer "working on it" or "it's more effort than expected" or similar. The effect per unit of work may be lower if the unit of work is small, but it is still useful to think about how to get visibility when the communication is faulty (as it clearly is if someone is saying "working on it" when they've not even started). This can apply to a months long project or asking someone to do a task that should take an hour - it has nothing to do with the overall project management, and everything to do with validating your inputs.
- wpietri 8y ago
  I partly agree on #1. Although if someone is in the position to request work, they're in the position to influence process, and to request discussion of process. So I think "no way" is too strong. I think #2 is definitely false. Last time I started a company we used a kanban board, strong WIP limits, daily stand-ups, pair programming with pair rotation once or twice a day, and units of work that averaged a day in size. We never had a need to distrust what somebody told us. Even without all that, if units of work are sufficiently small, task flow is transparent, and your WIP limits are sufficiently low, then there's no reason to be getting into people's business on a task-by-task basis. If there's a real problem, it will be visible at the normal scale. In my view, a good process doesn't demand trust. It creates it over time.
  - vidarh 8y ago