Most of the meetings come from the desire to have a decision made.
The problem is in most cases is that these are not decisions to be made now.
Software prototyping is cheap. We should just try to build a working solution and iterate around.

Let’s prototype. Get someone most annoyed by the problem and leave them to build it.
Of course, the clearer communication of what they are actually doing the better.
It should be something like ‘hey I’m gonna build this – okay’ or even ‘hey, I”ve build that, let’s see how it behaves’
Not like “we should now spend multiple meetings on discussing how this should be done’. Just make it work, instead of talking about it.


There are people that like those meetings around decision making.
And those decisions, that should not be made now, of course, need proper documentation around to prove the point. And document the decision-making process.
Oh, and office software and document versions of course. That’s what everyone uses. What, you developers have text files and this git stuff ?!

The thing is if the need for some documentation for something comes from the team then the team will make it when needed. If not then probably not.

Sharing the knowledge

Other possible reasoning behind having a meeting can be that of some knowledge needs to be shared.
And that’s a noble cause. Just don’t make a meeting out of it. Make a lecture. A presentation.
No audience members interacting with each other.
Speaker talking and maybe sometimes allowing questions.

The knowledge sharing sessions are oftentimes a prelude to the decisionmaking meetings. See above.

Confirming your ideas

Sometimes however somebody just wants some confirmation on their idea, maybe before building a prototype.
Then, there is a good chance that they already know who they should ask.
No meeting then. Just ask the people you know you should ask.
1-on-1 interaction. Maybe somebody will overhear and start listening.
Notice that the social dynamic is very different from the meeting then, two people having a conversation and another one politely listening, maybe being invited to the conversation after some while.
Just look how it works in between talks on conferences. Very different from “everybody says everything” meetings.

The meetings that are left

Also, if for some cosmic reason you really need to have a meeting – make it opt-in.
Just the people who are interested coming. Set the timer. There is one I particularly like – a clock showing amount of money wasted so far by this meeting.

Post scriptum

37 signals on meetings:

These guys have the idea of every communication should be async and read when convenient, hence their emphasis on email.
That gets you to really think of your proposal and really describe it and stuff, which is sometimes good. To stop and think, RFC-style.
However, as mentioned above, imho most of the times it’s quicker to just write the software.

Possibly, also, I just like ‘hey, got a second?’ approach better.

CC BY-SA 4.0
Meetings by Adventurous Computing is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

Flattr this!

WordPress and nonstandard ports and protocols
Compiling tarsnap on RaspberryPi
  • mdudek

    All is well if all people involved in product development are software developers or technical people. That is not the case in 90% cases (and shouldn’t be).

    Also, what do you do if you have a startup-like culture where all people on the product are highly engaged and you want them to have input as well as updates on the current state of development?

    1-on-1’s are not best way for team-wide communication. Overheard conversations are neither. And presentations are 1-way channel where the issue presented is not to be discussed (unless you have a panel and then it turns into a meeting).

    I’m all for asynch communications using email, but email ends up not being read and human interaction > computer screen. 😉

    • cyplo

      Hey, thanks for stepping by !
      Always a pleasure to hear your thoughts ^^

      “human interaction > computer screen” – totally agree.

      Most meetings, that scheduled ones and crowded, however, are not about human interaction. I like the non-official, casual interactions much better. The overheard ones, the “hey, what do you think” ones. For the very reason that they are more humane, more close to the conversation.

      To the first point, the people involved in product development should be, imho, people that care for the product. The developers and a client’s representative. They form a team that works closely together and hence does not need formalized meetings, they just talk sometimes.