I'm somewhat pro-meeting, which maybe puts me at odds with the cultural norms of developers.
I think I realize some of the problem. Meetings tend to be called by managers. Managers have management goals. Process, deadlines, coordination, etc. The developer sits around in case they provide some important input on one of those topics, or to give status, or to commit to a deadline. Nothing in that kind of meeting helps the developer's work. And the developer tries their best to withhold, to protect their own work, but also to protect the project which actually needs that output.
In a developer-oriented meeting the topics would be decisions to make, architectural choices to consider, noting places of tension where a creative solution could be helpful. In a developer meeting it is reasonable to take some time to look at code. To do a bit of research – right in the meeting – to answer a question. To brainstorm ideas. If a problem is hard, it is reasonable that everyone go silent for a minute and ponder the problem.
In The New Science of Building Great Teams
) they discuss some evidence-based observations about communication patterns. In it they suggest that high levels of communication lead to more productivity. By developer sensibilities, very
high levels. But mostly peer interactions – developers interacting with developers.
I'd really extend this to all the people engaged in making the product, design, user experience, user research, development, probably support and other roles. In an ideal model there would be dozens of meetings, as different sets of these people came together to talk about what is relevant to those groups of people. These meetings would not have clear and firm agendas, the product is the agenda, finding the agenda is some of the work of the meeting.
It's easy to blame management for the unproductive meetings. We're calling these snooze-fest status meetings. But I'd turn it around: professionals shouldn't depend on management to initiate meetings. Sure management can try; I try to setup meetings I think will be productive for other people. The Standup is the quintessential example. But we know where those so often end up: as yet another management-led status meeting. And it's a form without a clear purpose. Who should be in the standup? What should we talk about? When those things are defined by management we get management-style answers. Even better than trying to fix the standup, keep it from being necessary: make the meetings that help everyone do their work, where the topic is always execution and not prediction or planning or status.
With Project Managers and other professions focused on planning there is a danger that we defer to the specialists. But everything needs to be planned. The next line of code I write has to be planned. Developers have to be planners, every one of them.