Comment by bigiain | Hacker News Reader

Comment by bigiain | Hacker News Reader

Parent Full thread

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.

Do I keep repeatedly asking? That's the right thing to do, but as a human, it's a hard thing to do.

Blunt answer: yes. Absolutely.

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")

No no no!

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...

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.

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.

> Workplaces with that dynamic are toxic.

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.

Even better, do so in person and then follow up with an email summarizing what was discussed and what clarification you expect in order to proceed.

You nailed it. Tell me you can't or won't do it, and I'll pull it back and re-assign it, or maybe just do it myself.

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.

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.

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.

When it works, it’s great. When it doesn’t, it sows the seeds of resentment.

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.”

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.

> 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...

Reply on news.ycombinator.com