Lack of progress exposed by the Canary MacGuffin
rachelbythebay.com
rachelbythebay.com
I've been given a task I don't know how to do. So I'm working diligently on learning enough about it. But because I don't know how to do it, there are an infinite number of concepts that may or may not be required to complete the task.
So, I am using the time productively in the sense of breaking apart each piece I don't understand, building it myself, learning about it, and moving on to another one.
But I haven't collected the key from the shop. Every day, I write down what I need to do again, and it changes and evolves as I learn things. I try again to complete the task, fail again, use it as an opportunity to learn about that piece.
If I had just got the key, maybe the task is complete, but I am no closer to being able to obtain a different key, or providing any value on that surface area.
So I'm optimizing for my ability to get keys in the future, not getting this particular key.
Is that good? Bad? Lots of arguments in both directions I think. Maybe my optimizations are 25% what they could be with direct help. But having experienced direct help, what it actually means is someone talks over my head no matter how much I say I don't understand.
They don't get just how far away I am. Given the constraints, all that can be done is to improve to the point where their help, is help.
Hopefully that made some level of sense.
Such taks are sometimes what can be likened to quests from old adventure games: the quest giver doesn't mention the key, and the key is actually two lands and an hour of gameplay back. So you end up wasting couple more hours realizing this, and then backtracking, combing through every place you've been.
Such things are rightfully considered as bugs in quest design these days.
The best you can do is document, almost diary style, all of things you are doing to get to the goal and hope you have a project manager that will provide support and resources to get it all done. Frankly, all of my notes (which eventually went on a wiki for our group) helped in doing so much more.
Honestly, I think the whole question of "do you need domain knowledge to complete the task?" should be something to consider. Many folks do programming that isn't the same at each company and this tends to generate a different path that might not have a 'Canary MacGuffin' until very late in the process.
I also think that the whole "stupid task" is often mixed in the whole need / don't need domain knowledge. Many "stupid tasks" are related to the business process and often colored by not having technical resources with domain knowledge.
I once ran into a developer who thought it was stupid that we wanted some calculated amounts stored in the database. He didn't understand that other parts (oh, like the billing system) would have a problem redoing the calculation. Extreme, but one person's stupid is another person's ability to get paid.
It doesn't occur to someone without sales or maybe accounting domain knowledge that prices on a 'cut' order, bill, or other receipt, while numeric in nature, must be fixed and distinct to that order/line item when it's finalized. It becomes no longer a number representing what a given thing should cost in the future, it is now part of a record reflecting the contents of a legally binding contract.
Unfortunately, I don't think there's a good solution to either side of this. I mostly did what you did to get where I am, and I suppose I expect others to do the same.
Usually my advice is: study this, that and the other thing, and come back to me after 40 hours of study (without my guidance, it could easily be several times that). However, the other side wants something that will take <1hr, and when I give them that, they complain that they didn't learn anything.
It's a hard balance to strike.
You're exactly right that it ends up being, "do this, then that", and the problem with following those instructions is you learn almost nothing. You're running a playbook, and have no context as to why.
Before I did this, I followed that structure, and 6 months down the road, I had learned not nearly enough for the time frame.
So I've just stopped, and am following this approach. At the very least, I will (and do) know and understand a lot more. At the cost of being a complete deliverable sink.
The issue around communication is that, I really don't understand what is being said often. Essentially the things that people (rightly) assume is base knowledge, is not base knowledge for me.
So the only way to get there, is to really study, take courses, learn about and rip apart what these things mean. And that takes time. Lots and lots of focused, intentional time.
Now I'm building the foundation, and I'm learning a lot more, but I'm delivering a ton less. It's a challenge, but I will take responsibility for that, and just keep working hard to get better.
I often joke that the reason I get paid what I do is because of all the expensive mistakes I've already made on some other companies dime. A big part of my role as and older/senior tech guy, is to tell war stories carefully selected and curated to give very strong hints about how my less experiences junior devs are about to get things wrong.
Some people never learn from other's mistakes - but if you've got expensive mistake stories to share, try very hard to ensure the people smart/perceptive enough to benefit from them get to hear about them... Give them the chance to "stand on the shoulders of giants" (even standing on the shoulders of ordinary people is better than making the same dumb mistakes they've already learned from...)
I'm an older/senior guy as well. The difference is that, I decided to accept a role, that changed into a role doing something I had never done.
I was never a programmer, and I accepted a role that unknowing to me, ended up being a development role. I decide that it would be fun to become a developer, and explore this world.
I would be considered an expert in other similar fields, but not this field. The biggest misjudgement on my end was that I didn't understand how far behind I would be. I assumed it would take a lot of effort, and drive, but I completely missed how much it would take to become competent.
Still enjoying the experience, and am getting very excited towards a future where I can deliver and be relied on for critically important things.
But I think understanding that the greybeard over in the corner has those three decades, and that even if they fucked up using Perl running on hardware they physically touched/owned - they probably learnt some critical lessons that directly apply to your $language-de-jour running on $cloud-platform-of-the-week...
Become the person who'll get told, and listen too, their war stories...
I've seen both of these a lot. Eventually you end up classifying coworkers as "people who want to learn" and "people who try and get you to do any difficult work for them".
I will dial down the overwhelmingness and dial up the helpfulness a _lot_ if you land in the "eager to learn" group. If you regularly show yourself to be in the "do my work for me" group, I'll eventually just throw you some keywords to google and point out that I'm busy getting through my work (possibly while Ccing your boss if I'm in "a mood" or if you do this all the damned time).
Let's pretend our infrastructure is a home kitchen with a failing microwave oven.
"Hey, why isn't this button on the microwave working?"
"Because that's a refrigerator, not a microwave"
"No I KNOW it's not a microwave, but how do I get it to heat up my lunch?"
"Refrigerators don't heat things..."
"Sigh I know how microwaves work, why isn't THIS one working?"
I really wish I were being hyperbolic about this, but I'm not. Lately I've taken your tactic and just throw them keywords and proffer that I'll help them out when I can break away from other items. It hasn't failed that after a couple of cycles they'll say "Hey you were right about that microwave" and in my mind I'll say "no kidding".
On a darker note: there's quite a few of us who don't think this engineer is long for the company (they were hired only a few months ago).
"A few months" is way within the "still trying to work out who the fuck they are and how they fit in".
If they haven't bailed on the company in ~12 months, but are still asking the same lack-of-understanding-questions they've been asking all along, that's when I redirect my effort/energy elsewhere and dial my help back down to just offering relevant search keywords and a "sorry, I'm busy, maybe ask my boss to schedule a meeting after the end of this sprint if you still need help?" response (In writing. With an auditable paper trail...)
There have been more than one occasion where I'd find a potential solution to an issue this engineer is having, send it over to them as a helpful gesture-and I'd watch as they pull up the link, scroll immediately to where the commands are, bypassing every bit of text that gives insight into what commands are about to be ran, dependencies to interrogate before, or considerations that may be unique to a specific instance, and start slapping away at the keyboard without a clue in the world what the command they're entering is actually going to do.
I think it's less a skills gap but an issue with someone who is baked into their ways and hasn't been shaken loose from them on a more functional team.
It's a hard situation and I've been lucky that I haven't been stuck with anyone who can't overcome that initial learning phase, but if you find yourself there you should try and unload the problem to people more HRy and save yourself the stress.
(All the above, BTW, is not to imply that one-person rockstar programmers are a thing (they aren't) and skills vary, I am only talking about extreme scenarios)
edit >> (unless you work with assholes that see the student form as a sign of weakness)
I don't mind discovering a task I've assigned someone is actually way more complicated and time consuming that I expected (although I'd appreciate an explanation so I can recalibrate my assumptions), and I don't even mind finding out a team member I've assigned a task to is not yet skilled or experienced enough to understand the best way of doing it or to complete it in a reasonable timeframe.
What _does_ bug me (as RachelByTheBay alludes to) is the complete radio silence where I've been kinda expecting the job to pop out of the queue completed for the last few days/weeks, only to finally after giving you the benefit of the doubt and not wanting to seem like I'm micromanaging you - discover it's barely been started and doesn't look like it'll _ever_ get completed.
If it's way more complex that I assumed? Tell me. If you're way out of your depth? Tell me. If you think it's a stupid task and you're not going to do it and hope it goes away? Just fucking tell me!
For example, I've asked several times for clarification and got no response back. Now you're busy, and rightly so, you deliver far more than I do, but I considered those ignored contacts. Maybe you legitimately just missed them.
Do I keep repeatedly asking? That's the right thing to do, but as a human, it's a hard thing to do.
The reality is, there needs to be a communication channel back and forth, there is no hiding the details, but the channel needs to be there, and respond. If either side doesn't fulfill that minimum, there is going to be a lack of information.
Blunt answer: yes. Absolutely.
If you still don't get a response after escalating as far as you feel comfortable - then that's what you need to report to your manager, so they can do their job and make sure you get the information you need.
Try and avoid thinking in terms of "at fault". The primary goal is to get the work done. Mostly it never descends into blame storming and fingerpointing - so try and avoid behaving like it's got there before it does.
You don't need to "keep repeatedly asking", but you do need to ensure you've communicated clearly. If you asked for clarification and didn't get a response, follow up at least once, and make sure you follow up when you decide you need to shelve the task until you get a response (possibly in that first follow up).
"Hey $boss, I haven't heard back about the question I asked about $task on $date. I can't move forward without a response, so I'll put this task aside until that's resolved. If it's still urgent or critical, let me know, and let me know if I should continue chasing up that question with you or with someone else. Thanks, $communicative-co-worker."
Your last sentence is key - communicate. Both ways. With the prime intention of getting things done, and clear language explaining when things are stalled at your end and what needs to happen to un-stall them. If you're doing all that - you'll make your co workers and bosses very happy, and you'll have all the paperwork you need if things _do_ end up in a blame storming session later on. But don't optimise for the blamestorming, optimise for getting things done and clear communication...
In that context there is no blame, there's just information: Work can't be distributed for reasons, reasons that should maybe worry us. One of the least likely reasons is "person X is stupid". Far more common is "person Y and Z have a serious case of the Curse of Knowledge".
YET, if said person raises concerns immediately, there's also the potential for that work to get reassigned in a manner that never gives the said person to learn how to do X.
I agree that this is a selfish action, and ideally we do not act in such ways when under pressure to perform and work as a team. But I've found that this psychology often explains why teams find themselves with facing a Canary MacGuffin.
I'm slightly baffled by the premise of the original piece. If you set a task and hear nothing except "go away and leave me to it" updates for a long time, instead of checking up on magic keys, isn't it more useful to have a detailed progress session? Maybe ask for an approximate ETA?
In a non-toxic workplace it should be possible to do this in the spirit of fact-finding without raining blame on anyone.
The problem with that is that, weighted by number of job openings (for internship/begining/otherwise-not-already-successful candidates), most[0] workplaces are toxic.
If you can find somewhere to escape to, go for it, but sometimes you can't.
0: The exact proportion one sees will vary, but basically bear in mind that if people aren't quitting in disgust, your own workplace is less likely to be looking for replacement shmucks.
Tell me "you're on it", and what choice do I have? Any action I take will be seen as "undermining a junior engineer who needs to grow".
Don't ask me why I know this.
The main reason this doesn’t work is because one of the biggest use cases for such tools is to formally promise that you’re going to do something (see, your bug report/feature request is in our backlog, you can track this ticket!) with no intention of ever actually doing it.
Perhaps the solution is something in-between - assigning the task to the junior, expecting honesty and communication from them, and pointing them in the right direction as they need it. With competent but inexperienced junior, this works and results in a stronger team.
Now imagine your job is to wander around and find things, fix some, but mostly inspire others to weed their own gardens, so to speak.
Eventually you step in the wrong place.
“Click.”
So you can just tell me that I'm going to need to start working unpaid overtime nights and weekends until it's "done" for some unspecified definition of done? Nope, sorry, fell for that when I was young and stupid, not going to fall for it again.
>>...Is that good? Bad?
Whether that's good or bad depends, but at the end of the day the important thing is that you should communicate the status fully to the person who assigned you the task, rather than obfuscate it by saying things like "still working on it" or "it's a bit trickier than I thought".
Being assigned tasks you don't know how to do is fine. It's how you grow as a professional. However, there is a fine line between a task you don't know how to do but can learn in a reasonable amount of time, vs. a task you don't know how to do and can't learn in a reasonable amount of time. The latter, in my experience, is what results in the "Canary MacGuffin" scenarios Rachel describes, and it can be frustrating for everyone involved.
Ultimately, the responsibility for figuring out the difference lies with the team lead or scrum master or whoever assigns tasks in your company. But they need you do be transparent with your level of skill and knowledge to be able to do that.
The key is that I have to continue to communicate even with a lack of response. That is my responsibility, to not take a lack of response as an excuse to stop communicating.
That sounds like a problem to me. I don't know your situation, but when this happens to me, I am blunt and assertive that I don't understand what they're saying, like "I did not follow any of what you just said. I have no idea what X and Y are, and my understanding of Z is... Is that correct?"
in the short term people may think less of you, but in the long-term you will actually learn this stuff assuming you have a helpful mentor. If the senior engineer's job is to break things down for junior folks, and you're not understanding their explanation, then they're not doing their job.
Neither of those deals with the fundamental issue.
I have 0 issue with being assertive. It's a lack of basic knowledge that can only be acquired by backtracking, and doing.
If you have an advisor/boss that will suffer those years, thank them, even if they are a total jerk. Most won't suffer it at all.
The person who gave you the task is at fault for not confirming that this is within your skillset. So don't feel like this is all on you.
Perhaps they resent a poorly communicated request. Perhaps the task giver does this literally ALL THE TIME ... getting other people to do their work. Maybe the adventurer wants you to fail, because you do this all the time, and like, maybe for once you should do it yourself.
There's lots of reasons things don't get done in projects. Mind-reading and coming up with explanations about why someone is failing in the project is a shitty replacement for communicating needs and wants clearly in an organized fashion.
That is, when a project has a project manager, the project fails because of the project manager.
And while not every project requires or deserves a dedicated PM - every project needs someone who'l own the PM responsibilities. It can be _very_ hard as one of the devs on a very small project with no PM to "smell the risk in the air" while you're deep down the rabbit hole of coding - but if nobody does it things are very likely to eventually grind to a time wasting halt.
Great Project Managers are worth their weight in single malt scotch. (or substitute your personal very expensive substance...)
That is also 100% true when a project does not have a project manager.
Reminds me of the old gag-with-a-painful-truth: "A meeting without an agenda accomplishes precisely everything on the agenda".
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.
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?
her
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.
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.
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.
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."
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.
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.
Every question answered with “I am on it” or “top of the list” is often no real question intended to get deeper knowledge about the issues, but a rhetoric question acting as colourful wrapping for a “get it fucking done”.
Yes it might be legitimate for you to tell them to get it fucking done ― but will this help? If you are lucky it might, but there are better ways.
Instead of monitoring them it could turn out to be more productive to make clear why this task is important to you (”It seems unimportant but it is blocking important Task X”), why it is them who need to do it (”I know it is annoying, but I can’t do $Y because of reason $Z”) and finally really ask them (”Maybe you have a better idea how to solve this”). This will show them why it is important to you, why they are the only ones who can help and that they have at least a little bit of control over it.
Most people like to help other people. But if you just treat them as a blackbox taking instructions and executing them (like a computer), you will get a smaller chance Iof getting a result.
A carnary dies when something fails this carnary stays alive if something fails, so it is not a carnary. Also a MacGuffin is itself meaningless, it is just there to move the plot along and could be swapped out with any arbitray other MacGuffin (a mysterious parcel, a tiny plastic container, a black suitcase, ...)
I know a carnary MacGuffin when I see one, and when I see it, I run
There is often surprisingly little relation between a thing being stupid and not worth doing and how much some party wants it to be done.
Notwithstanding the potential existence of fourteen other simultaneous MacGuffins to be obtained at the highest priority that has the plucky adventurer spinning plates and shaving far-off yaks, about which the requester has no visibility.
When I'm managing a team, I'm spending all of my time ensuring that any obstacles are obvious, and that everyone has the stuff they need. This article seems to recommend leaving out details and waiting for people to ask for that detail.
Normally I'd prefer to be as clear as possible.
1. Our goal is to meet [objective], by [timeframe].
2. The plan is to accomplish [supporting tasks].
3. [Supplies] for tasks can be obtained here. Likely you will need X.
4. Distribution of duties is thus.
Notes: Any ideas that will accomplish objective faster/better are welcome. When we run into large obstacles or need help say something. Identify bad decisions (especially mine) before they cause big problems or waste a bunch of time.
Conversely this article wants to stop at step #1, and then wait for people to figure out 2 & 3 on their own. Which is probably exactly why they haven't started work.
Perhaps I've been blessed with excellent team members, but I've only encountered a handful of truly lazy people. Whereas, I commonly encounter fractured teams because of competing objectives, unclear tasks, and ambiguous goals. Engineering tasks to have hidden canaries is trying to solve the uncommon problem (lazy professionals), by exacerbating the more common problem (ambiguity during a coordinated effort).
If I'm "Valuing people over processes" I'll quite likely stop at #1, and rely on my people/team to work out the plan (#2) and supplies (#3) and task breakdown (#4) amongst themselves.
This does though, require a team willing and capable of resolving ambiguity, who'll proactively communicate their decisions and ask for assistance/resources. Your "uncommon problem" of lazy professionals is always going to be a killer, but if you're trying to do (original manifesto style) Agile with a team who're not confident or experienced enough to make it work - you'll end up with a way worse outcome from ambiguity than with an experienced/confident "Agile team".
> Perhaps I've been blessed with excellent team members, but I've only encountered a handful of truly lazy people.
But it's not necessarily about being lazy, but about people juggling multiple priorities, and finding it easier to fob people off with a "working on it" than explaining why their likely totally legitimate reasons have prevented them from getting further. Yes, this signals organisational issues with communication, but being aware this implies a problem does not make it go away - people don't like being the bearers of bad news, so it typically takes a lot of work to get visibility in these type of situations.
Often this is people trying hard to do their best, and delivering as fast as they can, just doing it by sacrificing taking time for feedback to stakeholders.
> Engineering tasks to have hidden canaries is trying to solve the uncommon problem (lazy professionals), by exacerbating the more common problem (ambiguity during a coordinated effort).
You don't need to engineer tasks to have hidden canaries. For most tasks there will be canaries all over the place. The article even explicitly makes the point she has not set anything like this up intentionally, but have seen them when wondering why tasks take a long time.
And this would also reveal ambiguities: Maybe the cause is that the team is building something, but it's different from what you expect and so doesn't affect the canary. In which case that is still a valuable indicator of a problem you may not have caught as quickly otherwise.
(But there's the distinct possibility that I'm wrong, or that I'm splitting hairs, or just generally missing the point of analogies)
I think to maintain the significance of the term, it should be limited only, as you point out, to only objects of meaningless, exchangeable value. Kinda drives home the point that the MacGuffin is not part of the plot in any meaningful way, it just serves as a motivation to get things moving.
Personally, I find this neologism highly satisfying. It is a novel combination of two precise idioms that when combined have the precise (although not necessarily obvious) meaning ascribed to the term by its creator. Many neologisms are strained at their creation, and only become idiomatically comfortable after years of use. This seems right, right now. Kudos to Rachel by the Bay!
The example I had in mind was the Rabbit's Foot in Mission:Impossible III. Perfect example of McGuffin: it motivates the entire plot of the movie, but at no point it becomes clear what it is (other than Simon Pegg speculating about it). It's in a canister, the bad guys want it, and Tom Cruise has to stop them from getting it.
So a MacGuffin for a software project may be like: "Boss, I see the specs, but what is this service for?" – "Stuff" – "???" – "Now, see, there's this little country, I think it's called Zamunda, and the prince really wants this, and, since he happens to know the nice of our CEO, we could make some points, if we get this right. Don't ask!"
(Note: In the original form of the joke quoted by Hitchcock and as retold by Truffaut, the MacGuffin is actually a magical tool for hunting lions in Scotland, the real joke being about it remaining undisclosed. However, Hitchcock used it in terms of a story driving objective that just serves the purpose of an external motivation, a black box that could be as well empty as far as we know.)
If it's important enough that it's actually blocking team progress then that's a management problem, but nothing in this seems to indicate it's anything like that.
> You see them again a bit later, and they insist they're
> "working on it". Time passes. Again, you hear from them:
> "top of my list".All of these seem more charitable, and contribute less to a toxic work environment, than automatically assuming that all of your colleagues are manipulative, dense or flaky because they have more important things to do.
Just be honest and explain you've been caught up with higher priority issues and haven't made progress. That gives the asker an opportunity to explain why the task is more important than you thought, find someone else with less on their plate to do it, or at the very least understand what's taking so long.
https://www.snopes.com/fact-check/brown-out/
The story goes that they used this as a quick test to see if the venue management had read the contract. If not, the crew would need to check all the technical specs. (Adequate power, controlled risk of fires, etc.)
Even if all the things they have to do are easy, just juggling them all is logistically challenging. Without the right process or motivation, there is nothing making the author's "nothing task" require immediate attention. It is common for a "simple" request to end up taking 3-6 months, because there's no obvious way to balance work on that task against all other work.
The hope is that team integration paradigms like DevOps can help identify and alleviate them. Take these blockers (that's what they are, not "canary macguffins", just old blockers) and automate them or remove them entirely. If you can't, add a step that allows your request to jump the line. Involve your managers, but use empathy and open communication.
Do we have to add CMs to check if stuff is happening?
Do we have to add explanation for CMs so people will solve our problems?
I get why the status update lying part offends but I'd also say the project manager who tolerates this isn't really project managing. Setting traps isn't the height of high performance I'd be aiming for.
But let's say you assigned a task and know the magic key is required. And the magic key is never accessed or acquired. You as project manager have failed. Did you reveal this dependency as a requirement? Are you sure that dependency is real? And why did you wait so long?
I've got a project in my history where I was expected to use a corporate credit card to purchase server time on AWS but didn't. When asked why I said I'd found better internal resources that worked at higher performance for the time needed. Imagine my surprise when I got criticised by immediate manegemenr for not spending 30k but praised by upper management for saving 30k and delivering ahead of schedule.
The real reason was that someone had 30k they wanted burnt before financial end of year but didn't state this as a goal. The project instead simply optimised for real cost and schedule instead, offending the management that wanted the money burnt.
By the way, the canaries in the coal mines usually died. I feel that tech in general should remember details like this and not create delicate metaphors for real events that had gruesome realities. Something is only a canary when the messenger died during delivery of that message. Just my $0.02 worth.
And ignoring you is probably better for me because if I tell you properly to go pound sand, you're a whiny little pain in the ass who is going to go bitching up and down the management chain about me obstructing your quarterly goals.
I'm normally pretty amenable to helping someone else, but I do have my own stuff to get done. If I'm not helping, I'm either busy or don't see the importance of what you asked--and I'm generally pretty straightforward about telling you both unless you've burned me before.
If you want my help, you either need to convince me of the importance or convince one of my bosses of the importance so that they put it into official channels.
Or, more common and more depressing: talk to contrived API z, where the WIP canary would be pointing out that the documentation is still missing.
I task you to add a feature to a system. I know you either haven't been involved with that system previously, or not recently enough that you can access it without contacting so and so to get the necessary credentials or whatever. For instance, you might need to be added to a particular set of group members for certain private GitHub repo to obtain source code; something I point out to you at the outset. Perfectly reasonable situation; nothing contrived about it. Yet I may now contact so and so myself to learn if you've come around to get what I know you need.
I have occasionally resorted to 'last' to see if someone has been active on a host I know they should have been accessing for one reason or another; typically to troubleshoot something I've asked them to look at. Often there are 'dev' hosts where the bulk of work occurs. Anyone touched it this week? I've deliberately left database instances down to see if the person that is supposed to be using it either notices and asks why and/or starts it themselves.
In an ideal world we suffer no dysfunction; people pursue their commitments. In the real world people make claims that they can't or won't live up to for a whole host of reasons, often times because they've been put in a position for which they lack the ability or haven't been provided the time, tools, authority and/or budget to cope with properly. A wise person detects this early. A naive person gets told stories and played for a sucker.
Sometimes just dropping a hint that you're not entirely oblivious to the real state of affairs is enough to get someone off the dime. (I talked to so and so yesterday; she's expecting to hear from you...)
Over time people learn that I'm not the one to play. That tends to reduce the net dysfunction, at least in my life.
Unless you are the CEO or have remarkable autonomy, you are executing someone else's vision. Over-communicating advances and next steps builds a lot of trust in large orgs.
That is, I reject the 3 explanations at the end. It could be that the person is very reliable, the task isn't stupid, and the person is unable to complete your quest without an item. In a world where things are constantly getting prioritized, it is just not making it to the top of the list. Isn't necessarily at the bottom, either, but needs to be "on the way" for the person to get it done.
This seems to be more common when you have people push goals without sharing success metrics. As much as I was annoyed by Measure What Matters, there is some element there to consider.
Lots of people just don’t want to say “This isn’t a priority, and I’m not working on it.” It’s easier (and it sometimes ends the conversation faster) to say “I’m working on it, it’ll be done sometime!” and kick the can down the road.
To that end, it is much better to ask questions such as "can you get over here and help me clean this?" Or, in the project management space, "when can I see the plan on how we are going to do this?" Even a "what do I need to cancel for this to happen first?" Even better, nether presupposes that the answer is "progress."
I'll pass on this one.
I don't think this is any different than any other open world game I have ever seen. Sure, some will have time bound quests. Most aren't, though.
Few things are more annoying than hearing "yes I will do that" when the person really means "no I won't".
As long as engineers are paid based on salary/wages this will always be the case, and has been the case in every company I've worked with.
I don't think this is 100% true, and the problem you are describing doesn't necessarily follow the cause you put forth.
Problem: Engineers do not work through tasks quickly because they aren't rewarded for completing tasks.
Solution (hypothetical): Reward engineers for completing certain tasks.
Problem: How do you value how much a task or feature is worth?
Solution (hypothetical): A task's value is correlated with the impact on the business's bottom line.
Anyone who's worked at a large SV tech firm can see the problem coming - engineers will only want to work on valuable, front facing tasks, and maintenance and technical debt tasks never get cleaned up. For example, Google[1], ties their promotion system to the value of the tasks you have done at Google - which obviously leads to a lot of gaming the system to increase your worth. So while I agree there might be a motivation problem, I don't think it's clear cut that the compensation model is the solution.
Then the question is why are they saying things like "top of my list" when it's not? If they are saying that anyway. Maybe because they think they'll get punished for talking back to you about the priority list? Or just hope you'll go away.
Meanwhile if someone is aware of one of these canaries, it's asshole behavior to hide its existence from the person who is carrying out the related task, up to some limit of obviousness. There's something to this concept beyond just any tracking mechanism like "did they open that file in Perforce for edit?" (Ignoring they can work offline, or otherwise defeat the canary monitoring while still "collecting" it.) When it's something you know is needed to make progress, put it and all the other intermediate steps in the Tasks List for a work item if you know them; breaking things up into concrete realizable chunks is how we make progress and prevent floundering.