Meetings seem harmless and can leave many managers feeling like they’ve accomplished something - getting their team on the same page and updating everyone on the status of current projects in the office. However, requiring your developers to come to meetings throughout the day is counterproductive if your goal is to produce great software. Meetings kill developer productivity and morale. They’re an ineffective use of a good developer’s time. In my experience, the fewer meetings you require your developers to attend, the better software you produce and the higher the morale of your development team. This article will explore why.
Time Spent in Meetings is Time Not Spent on Software
The first reason is obvious. If you require a developer to attend a meeting then that developer isn’t working on building software. While this diversion from the developer’s job description might be acceptable occasionally, the reality is that many developers get roped into meetings that they don’t really need to attend. Over the course of a given week you could be losing many hours of productivity out of your development team due to meetings.
The temptation, of course, for executives or management is to think that it would be valuable to have a technical person in the room while the company is making an important policy decision or discussing a project. In most cases, however, the result is the developer has to sit through a meeting that largely has nothing to do with the projects he/she is currently working on. If you need someone to offer a technical opinion on projects, create a role for that person at your company and have that person take all meetings where technical expertise is required. Allow your developers to do the job you hired them for.
The Importance of Deep Work in Software Development
The reason why it’s so critical that you leave your developer undisturbed is because software development is hard. Much of software development is the difficult brain-stretching work of solving logic puzzles, creating organizational architectures, and understanding complex relationships. This kind of work requires a distraction-free environment with no interruptions- even scheduled interruptions like a meeting.
Ask the best developers and they’ll tell you that getting deep into a problem takes time. Each time their attention is distracted from the problem at hand, it takes a similar amount of time to get back into the thought process. In order to get the maximum value out of your developers they should not be interrupted. Keep distractions to a minimum. Managers who schedule frequent meetings and are constantly multitasking may not appreciate the type of intense focus required to solve a difficult software challenge. Managers should realize that uninterrupted time is a prerequisite for good software development. It is non-negotiable.
Morale Suffers from Pointless Meetings
If the deep work argument isn’t enough to convince you to shield your developers from meetings, consider that meetings sap developer morale. Every developer’s personality is different but you’ll find that they’re generally introverted and highly autonomous people. While many extroverted managers see meetings as a productive and energizing time, most developers feel the opposite. Asking developers to attend frequent meetings will almost certainly lower the morale and energy of your development team- especially when those meetings involve topics that aren’t related to the developer’s projects.
The Standup: The Only Meeting a Developer Needs
My opinion is that the only meeting a developer should attend is a standup meeting with the rest of the agile development team. The standup meeting is meant to be short and to the point. It clarifies the objectives and priorities for the week and makes sure each member of the development team is on track to complete his/her assignments. It’s a highly focused meeting that provides the developer with all the information needed to do their job that week.
Understanding the impact of meetings on morale, deep work, and developer productivity could mean the difference between a happy, productive development team and a frustrated, underperforming one. My advice: be ruthless in your efforts to shield developers from meetings and insist that your developers be able to work without distraction. That’s how you’ll generate the best results.