At the same time, I joined another international team that practiced SCRUM and other agile stuff. And there were a lot of meetings/calls, given my team lead role. But you know what? It was almost the perfect example of "how it should be done" (and not only when it comes to meetings and calls).
The team had German roots, so order and punctuality reigned in all processes. You're expected to come to meetings on time; being three minutes late is a reason to apologize (although I never heard anyone being told off for it). At the same time, though, everything is strictly to the point. If you're needed, you have to come. If you're not needed, you won't be invited, no need to sit there warming a chair. If there's no agenda, there either won't be a meeting, or it will take 2 minutes (which isn't so bad, once a week).
Meetings related to the iterative development process (sprints, reviews, etc.) are usually agreed upon with everyone and scheduled at a fixed time on a fixed day of the week, for a long time ahead. Only the end of the project, World War III, or the switch to summer/winter time, which unfortunately is still alive in Germany, can interrupt that schedule.
If an unscheduled meeting is needed, the participants agree on a time among themselves based on free slots, and once agreed, everyone connects when needed. No "I'll give you a call sometime tomorrow afternoon" (meaning, sit and wait), no "we gathered at five, but the important participants can't make it, so let's wait till seven", and not even "quickly drop everything and answer the question I wrote three minutes ago".
Working on the home market in parallel was a bit wild in the light of such organization. Here we had to deal with unreliability, and demands to answer instantly at any time of day or night, and funny situations where rank-and-file employees switch to ferocious boss mode and demand everything at once. But fortunately, such situations are becoming rarer lately, and a professional approach prevails.
In short, the team was all about total Ordnung and dedication to getting work done. I must say that, apart from meetings, the work processes were set up really well too. Which, given that 100% of the participants were remote, almost shocked me at first. Everyone knows what to do and does exactly what's needed. No squabbles or conflicts, no off-topic stuff and no unique under-loved snowflakes. And all it takes is hiring pros and paying by the hour. At first I was puzzled about why I, the team lead, was even needed there, when everyone knew what to do without me. But more on that another time.
After a number of regular team lead <-> developer working calls, it became clear that even top specialists (and many of them were at least as good as me) sometimes need to talk things through and get confirmation that their ideas are right. And if the ideas aren't fully formed yet, discussing them on a call is all the more useful. But team lead <-> developer calls are usually the simplest: agreed, called, talked, went back to work, no point fiddling with the system logs.
One of the most disappointing meeting experiences, by the way, was a series of working calls with one of the biggest businesses in Russia. Everything professional, everyone a professional, everything very interesting, a good working group, and things seem to be moving. But the head of the department — bam! — changes every few weeks. Either the top management fears collusion and personal financial interest, or some other internal processes are going on. But as a result you end up in a kind of Groundhog Day. Having achieved some progress and maybe even agreements, you have to go back and start working through again what you've already worked through four times before.
All in all, having had my fill of calls, meetings and all this mess, I'd like to sum up this post with a short list of points. The dos and don'ts of meetings, calls and healthy work communication, so to speak. What, in my view, you should do and what, on the contrary, is undesirable, or disrespectful, or impolite, or simply deserves a smack on the head.
Notes and actions
Always do this. As mentioned in the first part, keep notes of the call (the PM can do it, or you can do it yourself), and also single out and record specific actions and who is going to take them.
Exception: one-on-one calls about a single question. For example, clarifying unclear points of a task with a developer. Although even here a summary comment in Jira is often very useful.
State the agenda
If you're scheduling a meeting with someone, try to state the agenda. First, it's polite: you already know what you're going to talk about, so why hide it from your colleague? Your secrecy can turn into suspicion, insecurity or nervousness for the other person. Especially combined with an arrogant "come and you'll find out". Keep doing that and, at best, you'll be considered an arrogant and unpleasant type. Why?
Openness (even about unpleasant things), on the other hand, sets a much better working mood. "Task ### turned out crappy, drop by at five, let's discuss what went wrong and figure out what can be done with it next" is much better, in my opinion, than "come by, we'll talk, you know what about".
It's easier and faster for me to ask colleagues than to google it
Some 18–20 years ago there was a guy in our department who worked on technical documentation. He was the living embodiment of the "it's easier for me to ask" principle that various people on the internet still regularly proclaim. If Alice, Yandex's voice assistant, had existed back then, he would surely have been the first to burn out a smart speaker with his [censored] questions.
The guy asked about absolutely everything, everyone, non-stop. "How do you translate this word into Russian? And this one? And how do you say this in English? And what's this window in the program? And how do I find that other window?" And any attempt to stop him (install a dictionary, show him a search engine, open the documentation for the program he was required to read for his job) always ended with the same answer: it's faster for me to ask you than to figure it out myself!
Remember, when you save your five minutes by asking a colleague, you:
a) deprive yourself of the chance to learn something;
b) steal those five minutes from your colleague.
And if with the first part you're only your own worst enemy, then by getting in your colleagues' way like this day after day, you'll very quickly turn them all against you. Soon after which you'll be out of the team faster than you can say "bye", and nobody will be sorry about it. Better just bang your head against a wall, [censored], it'll definitely be easier for your colleagues. And faster.
Exception: when it's about joint work and questions within your colleagues' competence that they're supposed to handle in that joint work. Or if you're a tyrant boss.
If you don't have to call — don't
Don't bother people without need. If you just give people time and a chance to focus, they'll solve many issues themselves and there will be no need to shake the air.
If there's no way to answer your colleagues' questions on the call, ask them to send the questions and reschedule the meeting for when the answers are ready.
However: sometimes a message like "Pete, Mary and Bob, quite a lot of time has passed already, why don't you get on a call and sort it out" works wonders, and the issue turns out to be solved a couple of hours later without any calls at all. Because nobody likes calls, and working is fun!
If you've written — give them time to answer
Avoid sending a message and then calling three minutes later asking "Did you get it, and why aren't you answering?" Normally, if a person isn't answering, it's because they're busy, for example. They'll answer when they're free.
In general, don't do that. Unless you're the boss, of course. When you're the boss, it's probably not very cool either (you're working with living people after all), but at least it fits into what many consider acceptable behavior from a boss. "I'm in charge, so if I ask something, it's the most important thing and must be answered immediately!" But if you're not in charge of anything, it looks utterly ridiculous.
And besides basic respect, of course, remember: when a developer takes on a task, they may need 15 to 45 minutes to focus, catch the wave and do their developer thing. Unexpected but very demanding calls easily knock a developer off that wave, which leads to lower productivity and higher irritation (which lowers productivity even more). That doesn't mean developers should be wrapped in cotton wool and never ever touched, but if there's a chance not to disturb a person, then don't.
If you're afraid the recipient will forget about you, see the next point.
Don't write in the chat, write in the ticket!
In general, all questions that require an answer and can't be allowed to be forgotten or missed should go not to chats and messengers, but to the relevant tickets. It's all upside:
— a notification from Jira or the like is harder to miss or forget, and if you forget, there's a page with the list of assigned tickets; sooner or later the person will either look at it themselves, or the project manager will nudge them;
— comments on one topic live on a separate page and don't get lost among all the other discussions;
— you can always read the history of who said and suggested what and when;
— it's easy to bring new people into the task: just give them a link and ask them to read and figure it out.
Hi!
Never do this. Don't send "Hi" as a separate message. People fall into two categories. The first write "hi" and then spend 10 minutes typing the next message. The second spend those 10 minutes wishing all the plagues of Egypt on the first.
First, you've distracted a person without saying anything. So I saw +1 in the chat and went to look, and there it is — Hi! And username is typing. Well, hi, damn it, thanks for the distraction. I'm not going to wait until you finish typing, I'll go back to work. And in 10 minutes, when you've formulated your thought, I'll get distracted once more to read it. Question: couldn't you have distracted me just once, the second time, when the whole text was ready?
By the way, many people think there's no need to write "hi" in a private chat at all. We said hello once four years ago and have been talking ever since. There's something to it, although personally I don't care. Just don't send your hi separately.
Verbal diarr… stream
Another variety of the same pain: a stream of quick short messages.
Hi
I'm looking at task 123
I have a question
Or even two
Can you help?
That is, my phone or laptop speaker dinged 5 times in a row, but if I open the chat, I won't see anything I could formulate an answer to. After which I'll of course get upset and mute that chat for 15–20 minutes, so that the stream of messages finally pours out into a description of the problem and runs dry. And then I'll read it.
It would be nice if chats had a setting that buffered messages from one person and delivered/showed them to me only once the person had been silent for N minutes. You could probably even come up with a formula. For example, count the average number of messages sent per 128 characters and multiply that by 60 seconds to get the delay.
Many people from all walks of life advise: think first, then open your mouth. There's no need to write 20 short messages that make nothing clear except that you speak without thinking.
Think about what you want to write, to whom, and what you want to get in return. And compose 1 (one!) message that the person can answer. Clear, sharp questions to the point always earn respect. Multiplying entropy does the opposite.
Hi, are you there?
A separate variety is "Hi, are you there?" followed by waiting for an answer.
Wait-iiiing for an answer.
Why are you asking? Will you ask your question only if I'm here? And if I'm not here, will you never ask it at all? Then the question probably isn't worth the attention, and I'm not here. Write what you wanted to talk about, and I'll decide whether I'm here or away on vacation.
Hi, let me know when you're online/ready for a call
I don't want to let you know when I'm online. You want to discuss something? To begin with, say what. First (see above), it's polite. Second, the most polite and professional form of inviting someone to discuss something looks like this:
Hi, Mary! I'd like to have a call with you and discuss what an idiot Pete is. I have free slots today 16:30–17:00, tomorrow from 10 to 12:30, and all day on Friday. When can you make it?
Don't ask Mary first when she's available. You need the meeting — so offer the options right away. It's proactive, and it's easier for the invitee to choose.
Nowadays, by the way, there are various services that sync with your calendar / availability and let colleagues see your free slots for meetings/calls without showing what you're busy with. Some don't just show them, but let people book a slot. If constantly telling colleagues when you still have time is tiring, get such a service and give your colleagues the link. This is usually done by people who have a lot of meetings (account managers, customer success managers, etc.)
Something like that. Not that these are any incredible revelations. But in my humble opinion, if we remember, or at least occasionally recall, these points, it will be a little easier, more productive and more pleasant for us to work together.
P.S. And the main thing to remember: if you're so smart and know how to communicate responsibly and politely, and someone else doesn't, that's a reason not to get into conflict but, on the contrary, to help the person. Well, at least by setting an example.