Hacker News new | ask | show | jobs
by seer 2346 days ago
It's not about information sharing, dailies are crappy for that anyways. You should always have async information centre so people can get up to speed.

The idea is to be able to share the squishy emotional human bit of working with a team of people.

Without it I've seen people just slowly drift apart. You'd see a comment from a coworker on your PR and be like "argh who is this guys think he is! He's totally wrong" but if you can talk with him about it in video it becomes a lot less confrontational. You can apologise and be apologised to.

A jira board is just a means to have some shared concern to talk about. And done properly can leave you with a feeling of being part of something bigger, rather than a lonely coder talking to a computer.

1 comments

> You'd see a comment from a coworker on your PR and be like "argh who is this guys think he is! He's totally wrong" but if you can talk with him about it in video it becomes a lot less confrontational. You can apologise and be apologised to.

Unless that doesn't happen. Perhaps he digs in his heels that he's "right" when he's demonstrably wrong? Or 'he' is the team lead, and it doesn't matter whether he's right or wrong, we all now move in that direction "because". Having to have video/f2f in situations like that adds more stress.

Dealing with this situation now, and it's bad.

Well one thing that "How to win friends and Influence People", "Never split the difference" and "Non Violent Communication" in general has thought me is that it's very hard to "convince someone you're right". Dealing with people successfully to win them to your cause is a very hard skill to master, one that I'm struggling with myself.

A better strategy I think is to try to get emotionally in sync with the other person first. Win them as a friend so to speak. And visual queues in that case become paramount. Co-location is even better, but we're talking about remote now don't we.

People sadly don't usually listen to the facts, especially if there's an argument, and double that if the argument is public (more than two people involved). It requires enormous emotional courage to admit someone's right before a lot of people, so we hardly every do it. That's what most of the advice from those books is to get to know people first, gain their trust and talk to their emotions rather than the facts.

Dailies are not meant to fix that I think, more like keep the team working in the long run if it had a good start, and help leaders find out about problems quickly and address them elsewhere.

Going off topic a bit though but in your example - a team lead that's going off to a demonstrably wrong direction - well they have more things on their mind than that particular thing probably, "does my team listen to me" might be one of them or "other business consideration that we're not privy to" is another.

One way to approach this is to support them publicly but have a one-on-one with them and express your concerns, without personal judgement and the like. After which you can ask them to help you with a particular task, preferably one that you know will hit the problem where you've thought the direction would be bad. And never say "I told you so!" Help them through the arising situation and bam! You will have them on your side plus the project would be moving in a good direction.

Also a lot of times it might turn out that this direction was actually preferable. You'll get to say "yeah you were totally right" and win them to your side as well, and learn a new thing in the process!

> It requires enormous emotional courage to admit someone's right before a lot of people, so we hardly every do it.

I've got a couple of current situations where... the other person is not wrong (charitably "right"), but the timing and prioritization is poor. Or, they may be 'right' but for wrong or bad reasoning. (yes, doing "foo" in the code is good because is helps with code readability, but no, it doesn't bestow another layer of security to the project, and no, it's not a 'performance boost').

These are even harder situations to deal with, because, again, technically, the idea being presented isn't "wrong" or "bad" in an absolute sense, just... strategically, it a step in a demonstrably bad direction wrt to project progression and hitting deadlines.

> or "other business consideration that we're not privy to" is another.

I've been on teams of up to 50 people - divided in to multiple smaller teams - company in the hundreds of employees. Yes, there may be reasonings that I'm not privy to - completely understandable (expected). I've been on teams of 3-4, talking to an end client multiple times per week about goals/deadlines/etc. There should not be any reason for info siloing with respect to anything at that level (save, perhaps, financial considerations like salaries, contract amounts, etc).