We are in a stabilization phase of a software project, we arrange a cross-functional meeting every week with testers developers project managers etc, to facilitate better communication of the tasks at hand.

Unfortunately I feel like people try to present the importance of their work, as if they were being judged, instead of openly and directly communicating the challenges and tasks they face.

How can I turn this importance/professionality contest into proactive team work.

(note: no ones administrative boss is present on these meetings, so everyone should be able to feel liberated to say anything)

  • 1
    Have you talked with them about why they aren't more proactive? – Erik Mar 8 '18 at 7:45

Give what you can and take what you need.

Schedule two different meetings, at two different times. One for showing their work (for them and their desire), and another is to report their status and discuss challenges or road blocks (for you and your goal). And try to LEAD the meetings, by speaking first (Be the template on how/what each member speech goals are in this current meeting).

I would alternate the meetings and do a reporting meeting every other week, and the in between is to show their work (demonstrate). But you control the timing between meetings based on the work load, team size.. etc; Does not have to be every other week, could be both in the same week.

Reporting meetings would be:

A member at a time:

  • What are they currently working on

  • What are they planning to do next

  • And if anything is stopping them or they need help

The above does not necessary (better not) include testers and direct bosses. And minimal answer possible for each question (it is not a discussion meeting - just a status reporting unless there is some road block)

Demonstration meetings would be:

  • Show what they have done in the past two weeks

The above SHOULD include direct bosses, testers, stakeholders.. etc. Anyone who is interested or have any questions. This can go up to 15 mins for each developer, they can freely and openly talk about their achievements and "powers", how they did it, how much time it took them.. etc.

Advice: Look up SCRUM and follow it. It is reporting meetings every day (stand ups), and demonstration every sprint (sprint can be from 2 to 4 weeks)

  • I really like your Idea to lead these meetings by speaking first, that could work. Also, you point out that the members wish to demonstrate their work, even though these meetings are not the best way to do it. Unfortunately I may not be able to arrange separate meetings for demonstartion, because it may be perceived as a waste of time. Inviting – Employee 1223 Mar 7 '18 at 21:02
  • @Employee1223 Bring the issue to the higher ups? Point it out for them and propose this solution. Do your research and get solid understanding of the problem and the proposal, and the benefits. Convince them with statistics on companies who use SCRUM (happier team, more productive, more transparent, cross-functional.. etc), then let the authority do it for you. – Sandra K Mar 7 '18 at 21:27
  • You are describing SCRUM daily meetings and demo meetings. None of those work to improve employee motivation or 'proactivity'. – BoboDarph Mar 8 '18 at 10:58

Since none of the answers above address the underlying problem you are trying to solve, here's my personal take on this.

First of all let's dissect your described situation:

  1. You work with a team of people that write software who in your assessment are failing at sharing knowledge among themselves.

  2. Furthermore, when they are forced in a formal manner (you set up a meeting) to do so, they behave as if being under scrutiny.

  3. You dislike this situation as you consider it a sign of lack of motivation and proactivity.

Situation 1 is extremely common in all software teams I worked with. Reasons for faulty communication range, in my experience, from people being unable to properly communicate in a formal setting to faulty management or dysfunctional teams.

While a single individual that fails to properly communicate within a team can be trained to do so, conflicts can be managed and management can be replaced or trained to better handle the team's problems, you will need a centralized process for information sharing between teams.

Stuff like Confluence, Microsoft Teams, Skype and Redmine can help you with the administrative part of handling formal inter-team communication. You will still need to create some sort of process to ensure those resources are properly understood and used by the team members and that they understand and commit to the necessity of keeping each other updated. What I mean is you will need to set up a process to teach people in charge of those teams to enforce the use of formal documentation. Even if that formal documentation is just a story in redmine and a post on how it's supposed to work in Confluence and who is responsible for maintaining the code that makes it work.

Secondly, you tried to fix the communication problem by bunching a lot of people in the same room and hoping they start talking work-related stuff to each other when no boss is present. Hate to break it to you, but most software devs are egotistical people, so your meetings will most like turn into an e-peen competition with no real benefit coming out of them other than people will soon learn who the alpha dev around is. And why to avoid him/her. The fix for this is to adjust your expectations. You want your devs to talk to each other or do you want them to effectively communicate? If the answer is the latter, your approach is clearly not working. Because we're all people, not machines.

Thirdly, you seem to draw the wrong conclusions. If all you did for your teams was to force them to rub shoulders against one another in the same room for several hours, then you went about this the wrong way. It's not a sign of lack of motivation or lack of proactivity if they refuse to do so. It just means you went about solving your teams communication issues the wrong way. By trying to solve all of them at once.

My suggestion is to attempt to understand if and why there are any communication issues inside each of the teams involved then set up a formal process that can be tracked for inter-team information sharing (see point 1). And maybe adjust your expectations a little bit. Not everyone is good at sharing knowledge in a formalized setting, so a bit of leniency towards slow learners might be beneficial at start.


Fully agree with Sandra's answer. If you don't have time for two separate meetings, try to prioritize what type of meeting is more important to be held in a "meeting" context.

From my experience, demonstration meetings can be a much better fit to have synchronously - it would allow feedback about work to be shared on the spot straight away, build ideas up and get immediate recognition for your work.

While status/reporting meetings usually end up being a waste of time, since the information shared in those meetings could have been easily shared asynchronously. There are many ways you can do it. I'm actually one of the co-founders at Teambit which can automate this process for you.


If you can't have several meetings, try prioritizing one which would be most useful in a meeting format and hold another one asynchronously.

  • This answer is a shameless self-plug to the author's website. – BoboDarph Mar 8 '18 at 13:25
  • I included that link in the context of a reply, since it can be a relevant solution to the problem experienced by the person asking the question 🤷 – Alex Potrivaev Mar 9 '18 at 13:48

You must log in to answer this question.

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