“No meeting” always beats “Meeting”

I was chatting with a colleague on a feature that is loooooooong overdue and proposed to kill a meeting and use the time saved to write the damn thing.

He replied to me

Believe me, I would like to drop a meeting, not sure which one.

To which I replied

That’s easy, anyone of them :)

and gave my thoughts on meetings.

If there is a need for bi-weekly meetings to integrate XXX and XXX, we’ve got a problem that meetings can’t solve.

I have a radical take on meetings, especially regularly scheduled meetings:

  • assuming n persons in the meeting you waste most of the time n-2 people’s time (and if n>10, it’s likely n-1 people’s time)
  • people tend to not prepare meetings. They instead think about the issue at stake while in the meeting and thus wasting n-1 people’s time. Force people to write ideas in a (somewhat short) email, and that will force them to think about the issue more deeply and synthesize.
  • a need for a regular scheduled meeting is a sign of lack of trust, lack of natural communication and/or lack of proper task isolation: in any case, better treat the problem at the source than patching with a meeting.

The key to open source success is multiple but one big component is extreme resource/time stress. This constraint leads to:

  • very focused teams
  • limited need for sync-up style communication (hence the usual small core team)
  • proper separation of tasks to limit waste

I am not against communication, I am against communication wasting time (the asymptotic version being pure noise). I favor 1-1 communication personally as the most efficient brain-picking strategy.

1 comment to “No meeting” always beats “Meeting”

  • I think that meeting is a great possibility to meet other people working on the same project. For example, I was working as a Java developer on a big project with a lot of other IT guys (DB administrators, Network & Security experts). Sometimes, it was very helpful to meet them during the meetings and listening to their explanations and/or their experience. Often, we can’t see and we don’t know that the problem we are trying to solve is already solved by someone else, maybe from the different IT-field.

Leave a Reply

 

 

 

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>