I'm likely in a Canary MacGuffin situation right now. What is the reason?
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.
So communicate that back to the person who asked you to do the task.
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!
Completely fair. But it always goes both ways, it's usually never as clear (to me) that one side is at fault.
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.
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...
This whole comment thread reminds me of my recent experience at an Amazon internship. I was trying to make my way out of the deep end, but my mentor was looking for whose fault it was; when the party with the upper hand decides to play this game, it's very difficult to escape.
Workplaces with that dynamic are toxic. You can't escape the blame game - you can only escape the workplace.
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.
I would go farther. The primary goal is to make sure that work can be distributed. It's not a team if you're all being held hostage by one person.
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".
Yes, but for many people who do not know how to do X, there is the chance that looking into the problem on one's own will result in a solution that can be accomplished in a reasonable amount of time. It's just unknown to that person at the start.
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.
If you ask for clarification from a third party and get no response, first escalate through increasingly low-latency communications channels, from email to your workplace's chat system to maybe an in-person visit.
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.
Usually when uncertain about something I'll try and approach it from several angles and batch up a number of questions to send them off in one go so that the person on the other end can answer them more easily and possibly gain extra insight as to what's amiss. But there are some people who are distracted and so when sent a list of five questions one of which is hard, they'll omit the answer to the hardest question... So with them I just resend a response with different wording and just that question. I'm usually not asking these questions of developers and instead communicating with stakeholders but yea, question weaseling is a thing, sometimes accidental, sometimes intentional, but it's good to resolve your question to a definite answer (including "I don't know")
How will the junior learn how to do it otherwise? Ultimately it's that first hand experience that will be the biggest lesson in teaching the junior.
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.
One important thing for anyone to learn is that they won't get work if they don't complete, or even just start work. The more effective someone is at working with other people the more valued they will be. Asking the right questions, and knowing which need to be asked, is an important skill to develop as well.
One interesting tooling idea might be, in whatever issue tracking system you use, to attach a TTL to assignments, so if the task doesn’t move to “done” (or “in testing” or whatever) by a certain point, the task reassigns to the original requestor/reporter.
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.
> If it's way more complex that I assumed? Tell me.
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.
Yeah. All the usual rules don't apply in dysfunctional workplaces. I hope you're either _really really_ enjoying the game industry, or getting enough runs on the board there and polishing your resume... Good luck there...
I know the feeling. I had a report (excuse me business intelligence query with nice printing) that I was working on that took up north of a couple of hundred hours. My problem was that I had to do the business logic (and gather a huge amount of domain knowledge) too. It was something of an effort, and I didn't make it to the shop for the key for a long while.
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.
That too is sort of a business needs driven application.
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.
I feel like I'm on the opposite end of that quite a bit. Quite often, colleagues come to me because they don't understand the task they're given, so I try to explain the pieces and how to learn about them. However, either I overwhelm them or they don't want to put in the effort, but eventually it ends up being: "do this, then that, and don't worry about how I knew to do that".
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.
I feel just as much empathy for my colleagues. No one is wrong, or right in this situation.
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.
Another view: Fucking up teaches you _way_ better lessons that studying and coursework.
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 tend to agree with you that fucking up teaches way better lessons, but it requires a foundation.
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.
Oh sure. Three decades worth of fuckups isn't something you can get in a bootcamp...
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...
> However, either I overwhelm them or they don't want to put in the effort
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).
I have a coworker who is similar to this. Not so much "do my work for me" group, but very much in the "will ask you for help and then turn down anything you tell them, while still getting it wrong".
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).
So the company you works at wants to pay people to make them money. When people start at a new job there's often a ramp-up time until they become productive and usually a second period until they're stable enough to lead others, but if someone is stuck in that negative efficiency state then it is something you should pass up the chain. If you're an experienced dev who is spending four hours a day holding the hand of someone new to the company that's an investment but if it's still going on months later then your manager will want to help the situation so that you can use your own time productively.
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)
Personally, I'll cut "the new hires" a lot of slack.
"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...)
Which is something I haven't yet had to do as it seems a lot of relevant people are picking up on this and there are mumblings going on of this person getting the axe soon.
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.
I end up in such situations too; your comments resonates.
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.
If you can pin them down to giving specific steps or details in smaller doses, that could help. You might be able to do that by researching enough that you have specific questions to ask and get them to answer just that question succinctly. Or asking for a good resource to get the key points. Sometimes experienced people don't remember what it was like to be trying to stay afloat in a new ocean and instead try to give a satellite image when you just need to know where the flotation devices are kept.
This is years 1-5 in STEM grad school, to a T. In fact, I'd say this is most 'thought-centric' work in general. When it does come together, it feels like it all falls into place at the last minute, like a practiced artist's drawing. But the YEARS of practice it takes to be able to make that swoop of the brush seem effortless are anything but.
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.
>>I've been given a task I don't know how to do. So I'm working diligently on learning enough about it.
>>...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.
I have communicated with no response given. I'm not obfuscating anything, and have spoken to other coworkers about the issues asking their help as well to understand context.
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.
Do you have someone who resides above these coworkers or coworker who you can appeal to for support and guidance? I realize this may be a painful step to take but you can't nor should you allow your employer to see your lack of productivity and effectiveness on the team because you aren't getting the help needed from seasoned team members leaving you to suffer on an island.
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.
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.
I'm fine with people thinking less of me, but the response is either they explain it in a way I don't understand, or they offer to give me an exact list of things to do (do it for me).
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.
I'm a guy who manages people who manage people. It's really important that you let the person who gave you the task know that you don't know how to do it. They may be able to help, or they may have a better use for your talents. Not telling them means you need to spend the time to acquire the skills to do the job, which may be a one-off, while they wait with increasing frustration and a lack of understanding of what the holdup is.
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.
I recommend updating the person that defined the task you are working on of your current status and the sub-tasks that you are working on. They will value any information you provide and may also provide you insight to accomplishing some of the sub-tasks (the key is under the doormat, make a copy). They will also probably value hearing about your thoughts and discussing potential alternatives, and if they are not then that is important to find out as soon as possible.
Perhaps the adventurer is asking themselves, "Hey, doesn't the task giver KNOW the guy who has the key? And they're really good friends? And they know exactly what they need? And where to get it? And what to do with it? So why are they asking ME to do it for them?"
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.
This is true. My comment is going to seem self serving because I am a project manager, but You Need A Project Manager! Someone who will ensure that things that need communicating get communicated. Someone who can see across the whole project and even multiple projects and communicate priorities clearly. Someone who will chase down deliverables and ensure everyone is unblocked. Very rarely will developers proactively reach out and admit they are blocked and can’t complete task A because team B needs to deliver task C first. They’ll just silently move over to the next Jira ticket. You need a project manager to pry it out of them! You need a project manager who can indeed read minds. Why is X not getting done? Why is Y ignoring her EMail? Why haven’t we heard from team Z for a week? Risk + inaction = crisis. Good project managers smell risk in the air before it turns into crisis, and take action.
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...)
This brought back flashbacks of people asking me to do things that required knowledge that only the requester had, using credentials that only the requester had, with support from people that the requester knows that I did not, and so on. I cannot personally fathom what brings people to do this since it seems to me like it is more work to give these sorts of tasks than to do them.
But the job of the manager is by definition to assign tasks. A bad manager doesn't delegate and tries to do everything herself. Not doing a task you agreed to as some sort of petty revenge or to teach a lesson is incredibly unprofessional. Just don't accept the task to begin with.
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.
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?
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.
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.
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.
>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.
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?
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."
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 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.
To me this sounds like a perfect example of failed communication.
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
Agreed. I'm sometimes the "adventurer", insisting to the random NPCs of the office that I'll get their quests done. But as anyone who has played such a game knows, the random NPCs' quests aren't always the most important thing to do. "Should I fight Ganon, or find this dude's missing cucco?" The cucco moves up the list if the NPC makes it clear I'll get a badass sword or something that will help with the whole Ganon thing.
> Second, maybe the task is stupid, and they're waiting for it to be killed. (How this matches up with the fact the requester is still asking about it and is starting to get concerned is another story.)
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.
Exactly. Figuring out which tasks are bullshit and just not doing them is an essential life skill. If you want someone to do something the best approach is to convince them it matters.
I've seen a couple posts from rachelbythebay that were like this: they expressed an unsettling eagerness to catch co-workers not keeping up. Maybe it's the type of work environment in which she's made herself useful, or maybe it's more the way she expresses herself than how she works in practice; whatever it is, though, it leaves a sour taste in my mouth.
Isn't this an exceptionally lossy, and circuitous feedback method?
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).
I don't see it advocating leaving out details at all. I see it suggesting that if you know the necessary steps or figure them out when you wonder why things are taking time, they become easy mechanisms for identifying if there's a communications problem (that again may reflect other problems). Whether or not you expressly communicates the next step at the start is incidental to that (at some point you stop breaking things down in further detail; no matter how detailed your plans are) - the only point is the existence of a required step that can be verified independently of a team or team member that is not being open with you about the real progress.
> 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.
Broadly, I kinda feel like you're comparing Agile and Waterfall.
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".
I remember a "MacGuffin" not to be some preliminary objective in a plot, but rather a meaningless, exchangeable objective that nonetheless is central to the plot. The Indiana Jones films serve well as examples: the specific artefacts he's trying to recover could be replaced with any other valuable item without meaningfully affecting the story.
(But there's the distinct possibility that I'm wrong, or that I'm splitting hairs, or just generally missing the point of analogies)
No, you're correct. I was going to point this out before I saw your comment.
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.
Things like "an user account in the system which you need to even start doing some work there" seem to fit your MacGuffin definition quite well. It's just an arbitrary trifle, but the meaning of it (and the meaning of the "worker" not having even made that user account) is quite central to the "plot".
A "MacGuffin" is about the objective, about what gets the technical side of the story (which is about an emotional trajectory) going. Imagine a screen writer suggesting a story, "There is this cunning agent and this girl and they are trapped in an air bubble below the ice in Antarctica. First they are cats and dogs, but then they bond over some obstacles and fall in love." Producer, "And why are they there, in the first place?" "Um, stuff, three-letter-agencies, a microfilm perhaps…" (That's your MacGuffin.)
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.)
Usually it's an object whose details aren't even bothered to be explained. All you know is that people want it, and their conflict drives the story. I can't remember Indiana Jones that well, but I suspect we know too much about why the artifacts are desirable for them to be classic MacGuffins.
You're not wrong, but that's the fun of neologisms. Their meanings don't always stay anchored.
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.
I think the problem is not so much using McGuffin in the neologism, giving Canary McGuffin a specific and well-defined meaning (which I have no problem with), but the incorrect description of the McGuffin as a screenwriting device given in the article.
Is the problem that this trope is attributed to screenwriting rather than writing in general? Or is there some other definition of MacGuffin floating around? The Reference [0] seems to agree with TFA.
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!
Another option four: They have their own job to do and perhaps your task isn't in their highest priorities? Or perhaps they want to work on it but haven't had the time to make proper progress yet.
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.
Being polite in a world of shifting priorities? Maybe they fully intended to dedicate time to it but another emergency/high priority pushes it down again. Or they want to work on it, and don't want it to be taken away, but haven't had the time yet.
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.
While I agree jumping to the conclusion that they're unreliable and flaky is ridiculous, being "polite" like that does no one any favors.
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.
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.)
From the perspective of the person receiving the request, this is just yet another request in a minefield of random tasks, all which have varying priority and deadline and complexity.
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.
I've been assigned tasks and simply essentially ignored them after any of my initial questions were ignored by those who assigned the task. Reasons include: task not assigned by my supervisor. No funding. No resources in general. No consultation. Person who assigned tasks has no authority to do so. These are similar and all have happened to me more than once.
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.
Ocarina of Time was the best Zelda game ever at the time of its release and in many ways remains so. Not at all relevant but she dropped the gauntlet in her opening comments.
And maybe I have a Canary MacGuffin of my own to let me know when your request is actually important to the business as opposed to simply being on your quarterly goals.
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.
I understand this situation applies if the “developer resource” is a direct report. However in many instances the dev may have multiple projects going on at once and there is some miscommunications on project priorities. Yes, this has happened to me and it’s why I abhor the phrase “developer resource”
To summarize, neologism Canary MacGuffin represents one likely, visible event (to the requestor) the requestee would have to do while Shaving the Yak (?)
I’m trying to imagine a technical problem where a worker would necessarily need to do something at the outset, and where it would be visible in the way suggests. Other than really contrived scenarios, I’m coming up blank.
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.
How about.... test this new feature in an app. 2 days later you check and they say no bugs to report so far but still testing some scenarios. Then you realize you forgot to add a necessary file, schema update, etc. That means the person testing could not have possibly been testing as the code would have errored in the first few minutes.
How about developing an interface to an external system using supplied credentials or where you needed to request credentials, and the supplied credentials were incorrect (generally always) or the request process takes a week. Either would have been fine if you had checked at the start and got the ball rolling.
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.
An interesting proposition. Though, oddly one that the game mechanics themselves can also have more fun with. Quite simply, it could be that your task is just a side quest. Sure, it is important to you, but not at all necessary in any meaningful way for the adventurer. Nor for any of the actually important things in the game world.
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.
> 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.
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.
I call that the "don't ask questions you know someone doesn't want to answer" philosophy. It is why I don't ask my kids "who made this mess?" It is asked in a way that typically tells the correct answer will make you upset.
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 am coming round to an idea of "event driven business" - where instead of taking a software project, estimating it, and then everyone else taking those estimates and turning them into your deadlines (we are blocked on you guys to deliver this), that a business should eventually realise that those deadlines force crappy quality, over pressures work and promises much like rachelbythebay is complaining of, realise and then just stop setting deadlines and have an entirely event driven schedule - write a test for "CrystalKeyHasBeenPurchasedByTeamZelda" and when that test returns true, hat next set of work can start - it's of a deadline, it's a dependency and if you don't like it, decouple.
not as i understand it - where is the linkage between a task - this involves a sort of linked list approach to tasks, where you cannot start a given task until a IRL test passes (and presumably you get a IRL acceptance automated test for finishing the task)
Reminds me of Van Halen and the infamous "no brown M&M's" clause of their contracts. They didn't really care about M&M color, but they did care that people setting up shows were paying close attention to detail because the shows had lots of complicated equipment and effects that could be dangerous if not set up properly. If they saw brown M&M's, they knew the contract wasn't being followed and stripped everything down to do a safety check.
Why didn't the adventurer mention that they were blocked? I feel like this is on them, though it would have been preferable if the task-creator had known the key was required. But, if I say I'm going to do something, and then don't do it and don't give any details why, it's always my fault.
To be fair, modern video games pretty much train you to ignore people that are just asking for things. Dragon's Quest is rather amusing in this regard. It will even handily keep a log of active quests with graphical pointers to where quests can be found. That said, to my knowledge, there is no penalty for not doing quests. They just pile up, endlessly.
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.
If people dislike the assigned task, or the way it has been suggested it be achieved, or think it is not important enough for them, or "beneath" them they should speak up.
Few things are more annoying than hearing "yes I will do that" when the person really means "no I won't".
This is kind of the inverse of detecting an exploit - If you as an NPC start leaving notes around the world describing the quest, and eventually someone makes a request to the shopkeeper for the crystal key, you know you have successfully injected instructions into a player's task queue.
Isn't this just a MacGuffin? A canary is specifically something I carry which alerts me of a terrible event about to happen or in progress. The crystal key is just a MacGuffin.
The name is meant to reference an item that serves as an indicator to what stage a task could be at at the time of checking. The word I would have used is "evidence".
There's a fourth explanation: Engineers don't get paid more for producing features faster (or on time), they just get more work. A smart/rational engineer eventually realizes they don't get rewarded for finishing tasks quickly or on-time, they get the opposite: more work. And promotion happens laterally not vertically, they get it by changing jobs because it's not obtainable by delivering more things on time or faster.
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.
>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.
Another related explanation is just simply that there are higher priority items, rather than just the priorities not aligning to working on any of Tasks A-Z efficiently.
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.
It sounds like you are suggesting objective based bonuses. I suspect that most engineers would completely balk at the notion of losing a bonus if they don't meet a deadline. Most engineers today feel entitled to all the bonuses for less work, not bonuses for meeting or beating deadlines.
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.