Real Reason Why We Have So Many Meetings
Structured vs. Unstructured Control
A lot has been written about the fact that companies have too many meetings. And a lot has been written why companies have too many meetings.
In my opinion many of the arguments are not convincing. Like people don’t want to work or they don’t know what to do. The reason for the many meetings lies in structured and unstructured control based on the Theory of Control.
You can find an introduction to the Theory of Control here. It explains software development with control flow and work flow, control elements and work elements. Control means controlling the how, what and when of other peoples work. In Scrum a Sprint Planning meeting would be a control element and Developing code would be a work element. We can do this with any process, but lets use Scrum as an example because everyone is familiar with it.
The diagram shows the control and work elements of a two day sprint Scrum process (longer sprints work just the same with more Developing elements). We see control elements and we see work elements.
We can already see that Scrum is a control heavy process.
Scrum reality is different. In reality there are several more control elements. Control elements can be different things but are often meetings. And now we’re on topic. The reason why we have so many meetings.
This Scrum example is what might happen in reality, compared to what Scrum says by the book. We have three additional control elements, Status Meeting, Re-Prio Meeting and Architecture Meeting. They are not work, they just control what, how, and when Developing is happening. And the Roadmap Planning meeting stretches over too many levels, from product managers to the CPO to the CEO in this example - which means an additional meeting for many people.
Why does this happen? These meetings are what I call unstructured control. They are not part of a process description. They are added by people, in this case the CEO, because they have lost trust in the developers doing their best (in their mind), or finishing on time, or working on the right thing etc. Fearing the loss of control of what is being produced. Therefor, the CEO adds unstructured control to regain control.
When we have unstructured control, what would be structured control? The meetings in a Scrum process are structured control. Control in Scrum is mainly implemented with meetings (instead e.g. with documents) though, which adds to the meeting load.
Checklists, good tickets, architecture guidelines, written down engineering culture, clear business vision and strategy, tech vision and strategy, static code checkers, code reviews are all structured control elements. In general alignment creates control - structured control does not need to be a meeting.
The way for less meetings is mapping your control flow. Put in the right amount of control meetings and add control elements that are not meetings, like culture documents, architecture guidelines and checklists. Alignment through vision and strategy removes the need for control meetings - structured and unstructured.
With the right structured control in place, managing control flow and trust in that control flow, there is no need for ad-hoc unstructured meetings - and also no need for the excessive control-meeting culture of Scrum. Mapping control flow also removes duplicate meetings and meetings that do not add to control flow (or work flow).
Yes you have too many meetings. The real reason is not because people enjoy having more meetings, but because you haven’t mapped control flow and people fear they are not in control and add unstructured control elements, aka. meetings or go for a control heavy process in the beginning.