This blog post is triggered by a Twitter discussion. It was about the idea of installing an ad in the background of a video call. Based on the salary or the daily rate of the participants, it should show how much money the video call costs.
Eberhard Wolff works as a Fellow at INNOQ and in this capacity advises customers on architectures and technologies. His technological focus is on modern architecture approaches – cloud, continuous delivery, DevOps or microservices often play a role. He is the author of over a hundred articles and books on microservices and continuous delivery, among other things.
Presumably, the ad is not just about the costs. Video calls annoy technicians and keep them from the real work. There is really only one indicator of whether we have achieved something: executable code. Developing this requires concentration. A video call not only costs time, but also interrupts concentration. It takes a long time before you can work productively on the code again. So the negative impact of meetings on the production of executable code is even worse than this ad would suggest.
Coding is not the problem
In fact, the ad doesn’t help. Worse, the idea is based on a misperception about software development. Not producing code is our biggest problem. The biggest problem is coordinating the joint work on the software and understanding the requirements. A great optimization potential is to implement features correctly and to implement the right features. Small differences can have massive effects. A blatant example: A single additional input field can cost 90% of sales. It is therefore counterproductive to implement this input field – no matter how quickly or efficiently this happens. While the running code might make you feel like you’ve accomplished something, it was actually a step in the wrong direction. The best option would have been not to write this code at all. Writing the code as quickly and efficiently as possible is a pseudo-optimization.
So meetings after all!
In order to understand what needs to be developed, one must probably hold meetings. Written requirements cannot convey all information. Queries, the joint development of ideas, questioning – all of this requires direct communication and meetings. But the meetings are still annoying and the problem has to be addressed somehow. Making the cost of the meeting explicit makes sense because it’s relatively easy. But it is the wrong optimization size. Meetings where relevant information is exchanged or important decisions are made are useful and therefore probably not annoying. Unfortunately, usefulness is not as easily measurable as cost. This problem of focusing on costs because they are more easily measurable has also affected other areas of IT, as discussed in another blog post. Precisely because working together is the major challenge in software development, it makes a lot of sense to optimize working together.
Maximize Meetings!
So we should improve the quality of meetings. For example, after each meeting, you can ask how helpful the participants found the meeting. Or you can get keep/try feedback on improvement: What should you keep at the next meeting (Keep)? What can you try (Try)? Even simply canceling all meetings company-wide, as Shopify has done, has the advantage that only those meetings that are valuable will probably be resumed. However, it may go too far because important meetings may also be cancelled.
Either way, meeting evaluation and continuous improvement is a constructive way to maximize the value of the meeting. And so we should maximize the value of meetings – not the number or the cost.
tl;dr
The problem of software development is coordination and working on the right challenges. Meetings are necessary for this. So let’s not just abolish meetings, let’s maximize the value.
(rme)