Effective team meetings

Question

I'm a team leader of a team of 8 programmers in a company of about 20 technical people. They're working on a range of projects, these projects also involve people from other teams that are outside of my control. My organisation is not doing proper agile development, and they're somewhat resistant to change, but I've been holding daily stand up meetings within my team and we've all been finding them useful and everyone is engaged and we're done within 10-15 minutes. I also have weekly individual catch ups with every team member where we discuss various general topics (both technical and non-technical) in more detail, as well as various ad-hoc topical meetings.

What I've been struggling with, however, is my weekly team meeting. It is losing steam and I have not been able to keep people interested.

I still want to hold a longer meeting, even if it has to be fortnightly or monthly. The purpose was to discuss various topics that cannot be done during a stand up meeting because they require more time. Updates from me include a summary on every current project that they're working on (whether it is on schedule, various delays, etc), any changes in direction, future projects, changes to development process, etc. However, it ends up being a lecture from me, and at least 2 people are obviously zoned out and the rest are at most mildly interested.

I tried getting people to be more engaged by getting them to talk about their week, but with 8 people it takes a long time and (partly because a lot of their work does not cross over all that much), most of the rest team does not care what their co-workers have been working on in more detail (they get a high level overview during stand ups).

So, during these meetings, at least some people are very bored, and it is almost embarrassing for me to keep holding these. It is a stark contrast to our energised morning stand up meetings.

Any advice on what I can do to keep people more engaged and more interested? And how can I get them to present things on their or start discussions that involve everyone instead of it being a monologue from me?

Answer 1

You said that the meetings feel like you are lecturing them. If it feels that way to you, and the team doesn't seem interested in what you have to say, then why still have the meeting? If you're just throwing information at them, and it isn't holding their attention, why not just summarize everything in a weekly email instead?

If you want to make use of that hour you have with the whole team, you may want to consider running a retrospective. You can introduce the retrospective with simple honesty on your part: tell them that you don't feel the previous meetings have been productive and that you want to try something different to help everyone to benefit from the hour they have together.

In retros where I work, we will have three columns on a whiteboard, usually putting a smiley, meh, and sad face at the top, e.g. :), :|, and :(. Then the team members get to put anything on the board that they would like to talk about with the whole group.

In the happy column, you can celebrate successes (like congratulating Alice and Bob on the release of a project they worked on together), and you can declare victory with new processes you're trying (like the new bug tracker is much better than the old one).

In the meh column, you put things that aren't exactly happy or sad for the week. Maybe you purchased licenses for the new version of your IDE, and somebody hasn't seen any advantages of the new IDE -- they could put that on the board to figure out if everyone else feels like the upgrade was worthless or if other people have found ways that it is actually superior to the previous version.

In the sad column, you put things that haven't gone well for the week. Identifying the pain points for the week is probably the biggest benefit of a retrospective in my opinion. The whole team gets to discuss solutions to a real problem. On teams that all work on a single codebase for instance, someone might say that the FooBar class is unmaintainable and has been the cause of hours of debugging. Suddenly you find out that everyone else on the team has also lost multiple hours this week to FooBar, but nobody spent any time to clean it up. In that case, the team may collectively decide it makes sense for someone to spend time refactoring that code next week.

After everyone writes their proposed topics on the board, I like to briefly go over each topic and have its author give a 10-30 second explanation of the topic. This section of the meeting is easy to derail, so you'll have to be careful to keep people on topic -- e.g. someone will say that X has been a problem, and someone else starts talking about a solution to the problem; solutions shouldn't be discussed until after voting. In introducing the topics, you may find ways to group together multiple, closely related topics.

After the introductions, everyone gets three votes that they can distribute among the topics however they see fit. Finally, the votes are tallied, and whichever topics have the greatest number of votes is what the team discusses. For each topic, determine if there is an action that needs to be taken. Celebrating a success usually doesn't have an action item, but refactoring specific code can be assigned to one person. The action items should usually be completable by one person, but sometimes they are "whole-team" action items such as being mindful of having good commit messages.

Most retros tend to focus on topics in the sad column, and virtually no retros discuss everything that's written on the board. The meeting tends to finish whenever time is up. Immediately after the meeting, see that the action items are assigned to specific people; do this in whichever way makes sense for your organization.

I've had great success with retrospectives. They are a great way to build cohesion in a team, and they're a great way to reflect on the previous week and to refine your process. I think that if you try these out with your team, they will be much more engaged for your meetings.

Answer 2

Welcome to the world of middle management!

You are going to find this type of problem happening a LOT!

You have 3 options:

Big Stick Do this or you are sacked - never works. Don't do it.

Ownership Get them to facilitate the meetings. Take a step back and nominate someone else. Have it as a rotating position where a different person hosts each time.

Speak the unspoken From what you have said, everyone is bored - then why not ask them that? Are you bored ? / Is this a waste of time etc. Why are we hear? What's the value in this?

It wasn't clear in your question why you want to do this. If you are the only one who feels these are valuable, are you willing to change? Ask them what they want. They are software people, their job is to solve problems all day - solve this one!

Answer 3

Try giving the developers more value in your meetings. A few examples might be:

• short demos showing new features developed in the recent sprint. (presented by everyone)
• a lessons-learned discussion in which they have a chance to change the way the team work and improve (discussion led your right hand in the team, and you are there to justify your management decisions. similar to a 1-on-1 venting session but bigger)
• a lecture on a new open-source project that could be relevant or a different coding language such as functional Lang or Golang or green threads in python. (perhaps presented by one of the younger developers, or in the form of an an online video)
• a discussion led by a sales engineer describing an awfully difficult engineering problem that his customer is trying to solve. (same deal with the support/services manager trying to reduce support costs by improving product usability)
• a manger that reveals the various strategic alternatives the company could have taken and how it would have affected engineering given the competitive landscape.
• an external advisor that gives consulting sessions on technologies you already use but not to the max (usually nosql, cep, RDBMS, networking, security, monitoring...)
• a code walk through in which everyone could learn new coding or debugging or testing productivity tips ( by that developer that has 10x productivity).
• a coding session where no mouse is allowed. Learn the IDE shortcuts thingy.
• talk by an accountant on money 101 related issues pension, investments
• talk about social programming and career (stack exchange, twitter, github, personal blogs, LinkedIn, meetups in your area)

Answer 4

Can the meeting or hold it much less often. Write your lectures in a regular email and send it out to everyone.

Only have meetings if the people in them actually have reason to participate in them. Otherwise, you really are wasting folks' time.

Answer 5

Don't hold long meetings and leverage project managing software. If you want to keep people interested, then condense and highlight what matters and save the rest for project logs and reports. Concentrate on milestones, deliveries, highlights and goals, and if only applies to 1/3 of the people, shelf it for a project discussion thread.

• Keep your meetings short
• Leverage Project Managing Software
• Keep it personal, purposeful and connect with emotions and goals
• Problem solve in focus groups, not in forums
• Get feedback from your peers

Also, don't let others jump into the conversation and go on about their work unless they have set points that they want to address. If you want feedback, prepare for it, or shelf it for a comment thread somewhere online where people have the time to address it. This is one of the most annoying issues with meetings; giving time to the floor to peers out of respect. Keep that stuff at the end after you have addressed everything thing you need to get across.

Take directive on the your project management approach, and encourage good development practices by leading through example.