What is the point of increasing the pace of meetings without increasing the pace of execution?

Companies are aware of the problem of meetings, especially since the COVID crisis which, by generalizing remote meetings, questioned their efficiency even more.

One of the avenues explored by companies and managers is to “put pace” in the meetings so that the pace of the meetings matches the pace of the field. There should not be a fast business time and a slow management and administration time.

How to bring rhythm to meetings

Let’s first agree on what it means to put rhythm into meetings. It is not a matter of running them at full speed, even if it means rushing them, but of increasing the volume of what they produce, their “output”, most often the number of executable decisions taken.

There are two main ways to achieve this.

First, intrinsically. By better organizing meetings, for example with shorter formats, with just the people involved, an established agenda or even short meetings dedicated to a single topic, sharing documents and studying them before the meeting so that it is dedicated to problem solving and decision making.

Secondly, in an extrinsic way. I often say that agility should not be limited to the field and to developers and we have an excellent example here. We see managers, whatever their field of activity, being inspired by agile principles and adopting all or part of the ceremonies such as the “daily”, the constitution of a backlog of tasks to be executed over a two-week sprint (very useful to carry out improvement projects in parallel with the daily train) with a “retro” at the end of each week.

More decisions does not mean more execution

But as is so often the case, this approach only addresses part of the problem and neglects an essential part. We solve a problem at the management level and we think that, as the saying goes, “the stewardship will follow”. But no. Stewardship does not follow.

We find ourselves in the opposite situation to the one I described here. I was starting from a common situation, namely a business that made the field work in agile without applying the same rhythms to the floors above, to conclude that “a business is never faster than the ability of its management to answer employees’ questions and solve their problems.”

Here we are facing the opposite problem, rarer (although…) but not less disabling.

A decision made in a meeting is an output of the meeting and often an input for others who need to execute the decision. But producing faster decisions does not guarantee faster execution, far from it.

  • Because the people in charge of executing them do not have the time.
  • Because there are not enough people available to execute them.
  • Because sometimes a meeting participant is expected to “produce” something and this person can, depending on his role, be present on so many cross-functional topics that he has no time to work in the sense of “producing deliverables / concrete actions”. As I was recently told, “you have to choose between leading and delivering, but it is difficult for a person to do both at the same time on a large scale”.

Think of your business as a factory, your meeting as a machine A that produces parts to be processed together by machine B. If your machine A produces 10 parts per day and your machine B can only process 8, you are only building up a work-in-progress that increases mechanically every day.

In other words, if your ability to decide is more important than your ability to execute, you produce a huge “to do list” with a quantity of tasks that only grows and whose execution time will mechanically increase with time.

Re-align decision-making and execution capabilities

At this point, the situation could not be clearer: “if you produce more decisions than your teams are capable of executing, you will reach a point where making decisions will become useless and nothing will be executed, at least in a useful timeframe.”

There is no magic method to solve this problem with a snap of the fingers, but some common sense principles and leads to explore.

1) Stop being in denial and accept that your ability to execute is limited

I come back to the famous “stewardship will follow”…when it never will. Or, rather, one can of course work miracles by increasing the workload, but this is not sustainable in the long run.

If the ability to execute does not follow we are not even producing decisions but tasks that may be executed one day. This is simple to understand but experience shows that it is very difficult to accept.

This brings us back to one of the big operational excellence issues for knowledge workers and the service industry. Let’s go back to my parallel with a factory. If you see a stockpile in front of a machine, you understand that there is a problem and that, since a stockpile costs money, if machine B cannot produce at the same rate as machine A, you have to slow down the rate of machine A, even if it means not using it to its full capacity.

As soon as we talk about immaterial flows, all this is shattered and since we don’t see things, we pretend they don’t exist. There are no files piling up on the desks until they reach the ceiling, just tasks, emails, meetings that fill agendas and email boxes. It doesn’t show so it doesn’t exist, people’s time is infinite, they just have to get it done and we don’t want to know how. All of a sudden, the culture of results that disturbs many managers in their desire to monitor employees in person or remotely, suits many people! Except those who execute.

2°) Going a little further in agile

When I say that agility can be applied everywhere in the business, I am talking about the spirit, not the rule. Not that it’s not possible to have an integralist approach to the thing, but because it can be counterproductive, at least in the short term. Everyone should make the main principles their own and adapt them to their own business, to their teams and their maturity, and to the collective’s ability to assimilate changes of varying scope.

In many cases, adopting the sprint and daily logic already helps a lot to restore the team’s rhythm and refocus on the customer’s needs, whether internal or external.

There’s just one more thing to add to go one step further. An agile development team plans its sprint knowing how many tickets to ship compared to its production capacity, knowing that the rest will stay in the backlog and be planned later.

Keeping the same spirit and without applying the principle strictly, only give tasks to be done that you are sure can be accomplished within the time limit, even if it means dividing a big task into several smaller ones, because it is better to advance incrementally within a reasonable time than not to advance at all within a short time.

3°) Resize resources or change the organization

You can always increase the workload on a one-time basis, not on a long-term basis. If your teams are systematically late or work into the middle of the evening, there is either a problem of skills, resources or organization.

  • Organizational problem at the team / global level. Too many meetings, heavy processes, multiple validations…this can be improved sometimes very quickly, sometimes in the medium term.
  • Problems of skills. If it’s a one-off lack of skills, you can admit a small delay, but if the subject is important, you can think about taking on a skill from outside the team on a one-off basis. If it is systematic, either you have recruited the wrong people or they need to improve their skills, but in both cases it will not be solved in a snap of the fingers.
  • Problem of quantity of resources. Either you decide to do less, or you decide to hire, but outside of these two solutions nothing will miraculously solve your problem.


Increasing the pace of decision making is great, but without asking how it will be executed, it just pushes the problem away. And execution capacity problems will never magically be solved, no matter how much we like to tell ourselves that “stewardship will follow”. Because it never does.

Bertrand DUPERRINhttps://www.duperrin.com/english
Head of People and Business Delivery @Emakina / Former consulting director / Crossroads of people, business and technology / Speaker / Compulsive traveler
Head of People and Business Delivery @Emakina / Former consulting director / Crossroads of people, business and technology / Speaker / Compulsive traveler

Recent posts