In the software development industry, a lot of time and resources are spent on meetings. Many managers have calendars filled with meetings most of the time. Personally, I don't like meetings. I always try to minimize communication if an issue can be resolved without a face-to-face meeting. I apply this rule both at work and in life. For example, I prefer to refuel my car using an app, and I try to order food and other services without needing confirmation from an operator, and I did this even when such an approach was not so common. If I need to find a place, I will open a map in the app, instead of asking passers-by for directions.
My reluctance to waste time or be inefficient has resulted in our software development department carefully monitoring the time our developers spend on meetings. On average, a developer has only 2 hours and 15 minutes of mandatory meetings per week, including four 15-minute stand-ups, a 30-minute one-on-one meeting with a manager every two weeks, and 60 minutes for various meetings such as planning and demonstrations. The rest of the time, about 5 hours and 45 minutes, is spent on other activities in MS Teams, including chats and individual calls. Although we believe that this time should also be optimized, we focus mainly on key meetings to ensure that every minute spent is valuable.
For comparison, according to a study by Atlassian, the average worker spends up to 31 hours a month on unproductive meetings. That's about 8 hours a week, which is equivalent to a full work week for one employee out of a team of five people every month. If we convert this into working days, it means that on average four people are working, and one is constantly in meetings. This does not take into account additional time spent on informal discussions and ad-hoc meetings, which further reduce the time available for direct work on product creation. Thus, developers actually spend less than half of their working day on direct development, which is a worrying sign for any organization striving for innovation and efficiency.
Much has already been said about how meetings are often excessive, and yet developers continue to spend precious man-years on meetings. Meet less, spend time wisely - these loud calls are heard everywhere, but in practice, everything turns out to be much more complicated. It is unlikely that there is a universal recipe, otherwise we would have gotten rid of this headache long ago. Instead of looking for a magic pill, I decided to share with you our approaches and principles that guide us in finding solutions and show what results this leads us to.
Holding many meetings is abnormal
Every time we face the need for a meeting, we actually see a reflection of a deeper problem. A meeting should not be seen as an inevitability for which there is no alternative. On the contrary, the time spent on a meeting is often just a patch that hides real problems in the organization or even serves as a tribute to established customs.
The complexity of the modern world sometimes seems like a compelling argument in favor of endless discussions. However, this complexity does not always justify the need for meetings that are held "just in case", to "keep everyone informed" or in the hope of a random contribution from a participant.
Following the principle of minimal necessity for meetings, we not only reduce their number but also strive for maximum efficiency of each meeting. Before planning a meeting, we ask ourselves questions: Can we do without it? What is its purpose? Can the same goal be achieved in another way? Is the presence of each participant necessary?
Meetings and gatherings are very expensive. And the problem is not even that they are expensive, but that the costs for them are invisible. Imagine: a team gathers for an hour-long discussion, and a whole man-day seems to evaporate. And in a day you can do so much: fix a bug, reduce technical debt, or even implement new functionality.
Of course, sometimes meetings are necessary, but they tend to grow uncontrollably. It's like fighting excess weight: first, you allow one small weakness, then another, and it seems like nothing terrible. But over time, these "small weaknesses" turn into a serious problem. So it is with meetings: it seems that these are just short calls, but when you start to summarize, it turns out that they take up a huge amount of time.
In the end, we face the fact that one working day a week is spent on clearly unproductive meetings. If we also take into account all the calls and discussions, then about half of the working time is spent not on direct work, but on communications. Developers strive for productive work, and our task is to provide them with this opportunity through optimization. We can try to improve the coding process, but it is difficult and costly to significantly increase its efficiency. At the same time, half of the time spent on communication represents broad opportunities for improvement.
Recognizing the fact that not everything is solved by meetings, that their large number is not normal and that this is the first thing you can start optimizing, i.e. in fact, recognizing the problem, is the basis of our culture, further optimization.
Meetings are expensive, costs are invisible and tend to increase.
This value is communicated from the moment an employee is onboarded, where a separate section on communication efficiency is highlighted in their training program. It is also regularly emphasized by me at one-on-one meetings with development managers, who, in turn, will convey this principle to developers and product managers. If necessary, the issue of meeting efficiency is raised at general meetings to ensure that everyone on the team understands the importance of this problem and actively participates in its solution.
Getting rid of unproductive meetings
Recognizing that meetings can turn into a costly habit and have a tendency to increase, we maintain constant control over their number and quality. Meeting optimization is not a one-time action, but a continuous process that requires regular auditing.
Corporate messengers and chats provide analytical data that can be used for monitoring. These data include, but are not limited to, information about the number of messages sent by a user, their participation in calls and meetings. These indicators help us adapt audit approaches, taking into account the unique needs and features of our company.
We pay attention to metrics that can signal problems in processes. For example, an excessive amount of time spent in chats or organizing meetings may indicate inefficiency. Analyzing this data, we take measures to optimize working time.
In our fully distributed team, we have learned to effectively track activity in MS Teams. I insist on analyzing not only the time spent on scheduled meetings but also any distractions. If someone spends more than 20% of their time on communications in chat or calls, we see potential for optimization. This applies to both developers and managers. The solution may not always be to reduce the number of meetings, but we are always looking for ways to reduce the need for unnecessary interactions.
There are always meetings that can be canceled without harming the process, and the losses from their cancellation are often significantly less than the costs of holding them. An audit of meetings is necessary because organizers and participants themselves often do not notice the inefficiency of their meetings due to various objective reasons, and sometimes an outside view is needed to realize that regular meetings no longer bring the expected benefits.
There are always meetings those can be canceled.
As an example from our practice, I can cite a situation when a meeting, originally intended for three people, including me, gradually expanded due to the addition of three development managers. Initially, they actively participated in the discussion, but over time their contribution decreased, and they became silent participants. After I asked them about the value of these meetings for them and for the company, it became clear that their participation no longer brings added value. As a result, we decided to reduce the number of meetings and exclude development managers from them.
The 'Silent Day' initiative has become another step in optimizing our work process. Considering the flexible work schedule of our team, we noticed that many colleagues work hard during the first four days of the week, sometimes working more than the usual eight hours. This led to the fact that by Friday they had only four hours of working time left. If you add meetings to this day, then it risked becoming almost unproductive.
Realizing this, we introduced 'Silent Day' on Fridays, refusing all scheduled meetings, including stand-ups. This decision allowed employees to focus on completing tasks and approach the weekend with a sense of complete satisfaction with the work done. The results exceeded all expectations: the company did not suffer, and the employees were satisfied.
If you can't cancel, replace then
In an office work mode, opportunities for communication, clarification, and adjustment arise at every step throughout the day, which means that the threshold for misunderstanding is much higher. However, remote environments lack the numerous, easily accessible conversations that are available in the office, and therefore require strategic, quality communication and collaboration.
If there is a need for communication, then you should always think about whether you can use other ways of exchanging information. When simultaneous presence of people is not required, or an instant response, then you should turn to asynchronous forms of communication.
From past experience. When we analyzed how developers work, we identified that always and without exception, when a developer takes on a new task, they calls the manager and starts to find out what and how. I had to work with the manager to come to a format that would have as few questions as possible, as a consequence, and calls. Thus, we saved not only developers' time, the manager's time was saved too, it led to fewer interruptions, more productive work.
In essence, we are looking for ways to abandon synchronous communication - this is a chat or a call in favor of asynchronous, when communication occurs between participants with delays between message exchanges, and participants control when and how quickly they respond.
An example from our practice: we refused to hold status meetings on Friday and, in general, eliminated the need to discuss the details of task statuses. This became possible thanks to an agreement that developers will carefully and clearly fill out task statuses and leave informative messages to commits. Status reports are now generated automatically. Messages to commits contain enough information to prevent the need for additional questions. Here is a real example of a report to one of the developers:
It can be seen that a fix was written for one of the tasks, and the task was closed. For another task, the review was completed without the need for corrections, and the developer started working on a new bug.
If you can't cancel a meeting, you can replace it with something else
Asynchronous communication requires your employees to receive quality information. In asynchronous environments, workers need to adapt to the need for clear and concise communication, which improves quality and avoids unnecessary calls and chats. Here, written communication skills become important. Fortunately, now you can ask ChatGPT to tidy up the text, making it clear and understandable. We pay for a subscription for employees. So special skills for structuring thoughts are not even required now. The main thing is to write the basics.
If you cannot not cancel, regulate them
When canceling meetings is not possible, it is important to introduce clear boundaries and prepare for the meeting. Meetings should be divided into types and introduce a certain regulation for each of them:
Decision-making meetings should include no more than three people. If the participation of a fourth is required, most likely, this is to obtain information that can be requested in advance or during a meeting and let the person go.
Team status meetings with the participation of three to seven people require a stricter regulation. Each participant should prepare and have the opportunity to speak for two minutes. It is important to avoid discussing information that is already available to all participants.
Webinars, including demonstrations, planning, and updates for the entire company, require special preparation and clear presentation of information so that each participant can understand the general direction and goals of the company.
We have strict time frames: a status meeting is no longer than 15 minutes, the standard duration of meetings is no more than 30 minutes, and company-level webinars do not exceed one hour.
From recent experience. There was a meeting for 70 people. The CEO and managers talked about the monthly update. Every minute of such a meeting is more than a man-hour. I could talk for a long time about the technological achievements of our department, but it would be incomprehensible and not interesting to most. Instead, we focused on making sure everyone understood the general direction of the company's movement, its goals, and the decisions made. The format of the meeting was revised and clarified based on internal surveys and feedback. The goal of each department was not to boast of their successes, but to clearly and understandably present the essence of what is happening so that each division understands how their work affects the overall result.
Preparing for such a format took me four hours. Initially, without preparation, I could tell everything in a 10-minute speech, but I reduced it to 3.5 minutes. The difficulty was to balance and separate the description of features from their importance and value, which are the responsibility of other departments, and focus on the specifics of the work of engineers, how we work, what we are preparing for, what telemetry we collect and why. I made several recordings of my performance to fit within the allotted time, and in the end, spending four hours preparing, I saved the company more than seven man-hours. Reviews showed that my goal was achieved: people understood the significance of our work for the company.
Meetings should be held in accordance with clear rules and after detailed preparation of participants
Thus, the larger the audience, the more thorough the preparation should be. Organizers and speakers should prepare for performances to make the most efficient use of time and the attention of listeners. For us, this is not just words, we closely monitor this.
Conclusion
The practices and approaches described in this article are effective in our company. I will be very happy if my experience inspires you to change. Many of the problems and examples that I cited, I met in other organizations. And what seemed impossible to change, in fact, turned out to be quite feasible when efforts and attention were applied.
If you strive for optimization and improvement of efficiency in your company, start by reviewing meetings. Meeting optimization not only saves time but also often reveals and eliminates deep imperfections in internal processes. Thus, by improving the approach to meetings, you are essentially optimizing and improving the overall work, making it more productive and focused on results.
Hello! My name is Leonid Netrebskii. I have been managing development and projects since 2013. I have experience leading development teams of up to several dozen people. I have managed development in companies ranging from complete anarchy, steeped in budget sawing, to adherents of performance metrics. I am the kind of manager who builds the process comprehensively, including CI/CD, test automation, architecture, SRE. If necessary, I can also write code to demonstrate an example or try something out.
Once, I wanted to write a blog just to say something. Now I have something to say and am very happy to share my experience and observations in the field of software development management.
For a more frequent sharing of my insights and experiences, connect with me on LinkedIn: @netleon
