9 Rules of Effective Development Team Meetings

Alex Fedorov on January 31, 2019

Let me ask you a question. Have you ever had a meeting scheduled 45 minutes after the stand-up? Have you been able to do any productive work befor... [Read Full]
markdown guide
  1. Early in the morning, right after the stand-up.

I made a totally different experience on this one. After watching our "meeting culture" a while, it turned out that most people tend to be most productive in the morning, when the brains are still fresh.

When the day starts with a stand-up and (as suggested) even other meetings after this, the precious time in the morning is wasted in reporting and discussions with others.

When the "real work" (sorry, but this is most of the time what we're thinking, aren't we?😉) starts, peoples energy and motivation is already at a lower level.

Maybe they already feel, like they "lost" a discussion with a manager on how to do something, and are now upset. Or their "super elegant mega technical solution" was not appreciated as much as anticipated. And let's face it: Lunch break is only 0.5h / 1h / 1.5h ahead, so it doesn't pay out to start something big now, does it? 😎

Because of this insight, we moved the daily scrum an hour before the end of work (still time boxed at 15 minutes). Everyone tells what he did today, what he plans for tomorrow, just as suggested. Afterwards, there are 45 minutes left for meetings, so people have to express themselves short because they want to finish work soon.

Of course, sometimes the timespan won't be enough and there might be a meeting an hour before standup or something, but in general this works out pretty well, because the productive time from morning until shortly before finishing work is available to be...well, productive.

I also made the experience, that Meeting Days are beneficial once in a while like Martin wrote.


Why do you need meetings that "are not productive?"


I think I expressed myself wrong: Of course meetings should always be productive or canceled.

What I wanted to point out is, that in my experience it is more productive to program with a "fresh" mind and have meetings later :-)

It depends on the meeting. What if you need to make some decisions before you can program even? So they are blockers?

In general, though, I agree, that if programming activity is more productive than meeting activity, then it should go first. Still, meeting at the end of the day is basically useless (if it involves any decision-making), so having it somewhere at 2-3 as a middle ground might be a better idea.

Well in our case if we have to make decisions, we make it the day before 😊

It's really the same thing, just a different time...

I'm just coming out of our daily and a short "close-up" afterwards, because we had to discuss a little something for the work of my colleague for tomorrow. Now he knows what to do, has a bit time left to prepare his task and can start right in the morning having all the information he needs.

Of course this is a bit of personal taste - but as I wrote, it's just my experience that this works better for us.

This makes sense. It seems like you have the energy at the end of the day to make these decisions. And probably these don’t take much time (we’re not talking about 2-3h meeting in the evening that forces everyone to overtime (w/o being paid for it), right?).


Some other ideas:

  1. If you feel like you don't belong in the meeting or get bored, it's OK for you to leave. Of course, make sure the whole team understand this rule before it's applied.

  2. No screens! If you need to take notes use pen and paper instead. Phones and tablets are forbidden. Maybe one laptop plugged into a big screen for everyone to see.

  3. ROTI is a nice tool for the meeting's organizers to get better at their task.

  4. If you need to write a report of what was discussed, do it right after the meeting. The more you wait, the more you'll forget. If relevant, include in the report what need to be done and by whom.


Also, your 4th point makes me think of really troublesome scenarios where people avoid their commitments (decided from the meetings) pretending that they’ve forgotten or misunderstood, etc. This fosters a lot of negativity and conflict. Oh, and especially if they are a stakeholder or something like this.

In this case, I think documenting all the decisions made is great, and sending them as an email to:

  1. Make sure both parties are on the same page and wish to commit to this.
  2. To hold everyone accountable, including your stakeholder(s) or manager(s).
  1. ROTI is a nice tool for the meeting's organizers to get better at their task.

It’s actually a nice thing for teams to even understand that there should be a meeting facilitator, and somebody needs to play this role, and be in the know-how about facilitation.


One of the most effective approach to better meetings is No Meeting without an Agenda.
A few years ago, I worked for a customer where meetings were the answer for almost everything - but no one bothered writing down the questions. After a while, it got extremely annoying and our team started to decline every meeting request with no fixed agenda. From that point on, meetings got shorter and actually had an outcome.

What I also like is to create Meeting Days - i rather have a day completely filled up with meetings than 2 meetings every day. (Yep, I know - these days suck in their own way)


No Meeting without an Agenda

Yep! This is key. The problems I describe tend to happen even to meetings with an agenda, though.

Meeting Days

I feel like it varies from team to team and their workflow. In the teams that I often work it’s better to have 0 or 1 meetings per day instead, where a meeting is 15-60 mins. This also makes sense because we are knowledge workers and we can’t really do more than 3-5h of deeply focused work in a single day sustainably. One meeting per day + coffee breaks + water cooler conversations + your 4h of focused work amount to a full working day.


Great post! We're a remote team, and we've thought a lot about our meeting frameworks as well.

We wrote a post about deciding whether decisions are worth a meeting in the first place: medium.com/monolist/to-meet-or-not...

How do you decide when a meeting is worth it, and when you should make decisions async?


I really like this list Oleksii and will refer back to it in the future for sure!

code of conduct - report abuse