Hacker News new | ask | show | jobs
by Leynos 660 days ago
It seems reasonable to me. I tell my reports to decline meeting requests unless the invitations include an agenda and a clear goal.

If you're asking for 30 minutes or an hour of someone's time, it is only common courtesy to tell them why.

If you send someone a message, don't just say "Hi". This is incredibly bad manners in the context of asynchronous communication. Give the recipient an opportunity to prioritize your message. You don't know what they are doing. They could be fire fighting. They could be tied up in a face-to-face conversation. They could be in deep flow. They might have three or four other messages to prioritize alongside yours.

If you don't give someone the information to make an appropriate prioritization decision, all you are doing is inducing anxiety.

This is all a matter of being kind and accommodating to your colleagues, enabling them to work with you effectively, and making it easier for them to help you.

Purposefully making your colleagues' lives more difficult is a recipe for an unpleasant working environment.

2 comments

> don't just say "Hi"

Agree, but

> If you don't give someone the information to make an appropriate prioritization decision, all you are doing is inducing anxiety.

Disagree here. I used to think the same "why you only sayibg Hi and not what you want", but I realized it doesnt have to be my problem if I dont let it become one.

You said Hi? Expect a Hello from me sometimes during the day. You needed something urgent? "Why didnt you tell me?". A "Hi" isn't urgent, so I know I dont feel the burden of not being able to assign it a correct priority.

A lot of people have trouble recognizing when their teoubles are really other people troubles in disguise.

"I tell my reports to decline meeting requests unless the invitations include an agenda and a clear goal."

We have a team that works this way 100% of the time, assuming the invitation is not coming from higher management.

They are always the last to deliver and the team with the most critical bugs. If you don't make time for back channel sync, you will become an isolated island and your product will eventually suffer.

How so? There is no excuse for sending a meeting invite without an explanation as to what will be discussed or what you hope to achieve. That just results in aimless meetings that either have too many unnecessary attendees or missing people who do need to attend.

When someone asks you to provide an agenda for a meeting, do you really just ignore them?

I don't know, but let me hypothesise.

When you work with complex stuff, there will always be one or two urgent meetings where the caller doesn't have time or the data to set up a proper agenda.

A meeting invite saying "oh shit, all hands on deck" does not need to be due to bad planning. Obviously this should not be the norm, but when it happens you cannot simply instruct your people to ignore it.

I hate to say it, but dealing with high priority incidents with a meeting invite saying "oh shit, all hands on deck" and no further information does not sound healthy. The organisation should have a proper incident response plan in place setting out communication standards and channels.
I think you are misunderstanding my message.

This should never be the norm. But when the work is challenging and non-trivial something like this happens once in a while.

If someone felt they had a genuine need for an important meeting with an unknown scope, unknown attendee list ("all hands" suggests that they don't know the nature of the issue or whose expertise will be needed in resolving it), unknown objective, and it sits outside of the normal incident management then I would still ask them what on earth the meeting was about. After the fifth time someone asked, and they had to take time explaining it, they might start regretting not giving any kind of context in the meeting invite.

> If you don't make time for back channel sync, you will become an isolated island and your product will eventually suffer.

This doesn't seem to align with your hypothetical example. Of course, for project sync, there should be regular sync meetings, and cross value stream meetings. There should also be design reviews and retrospectives (both regular and ad hoc). It would not be appropriate to schedule any of these without an agenda or scope.