I manage a team of 10 Developers and Test Engineers. Its a new team, and team is slowly transitioning into Agile Scrum. We have meetings on team agreements, and things like definition of done, release plans etc.

I have observed that there are some individuals who always cause meetings to go into a non-decisive mode by discussing too much, or refuting someones suggestion etc. I can see sometimes that the suggestions / proposals made by other team members come from experience in the team from many years; and the people causing the conflicts are rather not that well versed with the processes etc.

I want to know some common ways to deal with this when in the middle of the meeting to

  1. Drive the discussion towards an amicable conclusion / decision
  2. manage these members to avoid getting into such conflicts and rather focus on giving proposals a chance.

Any advise?


2 Answers 2


As I told another person in regards to questions in a meeting -- facilitating a meeting is a learned skill. You need to learn to keep a leash on things, and learn how to interrupt a person and bring it back on track. Be assertive, and take control of the meeting. You (or the facilitator) is running it, so stick to the agenda. If you give them an inch, assume they'll take a mile.

Having said that, there are ways to manage it, such as set an arbitrary time to discuss something (even us an egg timer if you have to).

Use a marker or pen or something, and only the person holding that can talk, so you don't get 4 people trying to talk at once.

There are other tricks, as well, and some folks may chime in with some.


From my experience as a software engineer, when I've been in situations like this I've asked (and been asked) to write a brief summary and procedural list on how to accomplish my idea versus the experienced engineer. When my boss was able to see "on paper" my idea clearly thought out and presented he was able to get a better idea of what I was trying to convey. When my ideas are good, I will know that while writing it out. If it's not such a good idea, I will realize it and scrap it before I get too deep writing it out. This saves meeting time because my boss will just ask someone, "I would like to understand your idea better. Will you summarize it and write a procedure/pseudo code to help me see your vision better?" Boom, nipped in the bud, and the meeting moves on.

  • Even better: if the idea is good, you have the start of documentation about it.
    – Peter K.
    Commented May 31, 2019 at 8:43

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .