There is a small team (5-7 people who are a part of a larger 15-person entity) of experienced software developers. They are all currently learning a lot of new stuff in a new technology we are employing.

We have hackathons, documentation, central Wikis etc. and are talking in RL a lot. They do not work in a common project though, so there is no project infrastructure like Scrum meetings or the like.

We would like to avoid the situation where people invent the wheel over and over again. Normally we would just drop them in a room, close the door, and let them tell each other what they are working on in a relaxed manner. It would be enough, for example, if one of the guys works on session management at the moment, and another guy starts working on session managament in their project as well, for both of them to know that they are working on similar stuff. Now that they know, they can talk about it in private, later, and exchange best practices etc..


We had similar phases in the past (most parts of the team know each other for many years). It often got ugly because most of them are quite headstrong, competent and "alpha". What happens is that one person tells the others what he is doing, and instantly 3 of the others start taking his solution apart, pointing out deficiencies, arguing about why their solution is better and all that. As strong as most of them are, few of them are very emotionally stable; so everyone takes criticism in a not so good way.

Note that they know/like each other well normally, i.e. when going to lunch; the problem is not general animosities, power-struggles or such.


Is there a good meeting/communication workflow or structure which is easy to explain, simple to handle (by people who naturally scoff at such things), and has the explicit goal of letting people tell each other things without the emotional backfiring of others criticizing all the time?

Bonus points if the method does not require a dedicated leader / moderator but works self-regulating.

Again: they are part of the same organizational team, but they work on different projects, so it's not just a SCRUM or something like that, and there is not a person like a project lead who can just decide stuff (there are no technical decisions to make, at these meetings). I am not looking for a project method, but for a communication method to keep their discussions on a factual level. The goal is to avoid the wasted energy of long discussions of which approach to a particular solution is best.

  • The simplest would be a blanket "any feedback on ideas is to be given after the meeting, in private". Is that the kind of answer you're looking for?
    – Erik
    Commented Feb 1, 2017 at 12:50
  • 2
    "There is a team", "we have", "we would like" and so on all means that you are in dire need of someone to actually take lead on these meetings. Managing a meeting requires someone with the authority to do so. A committee-based approach is doomed to fail in a team like the one you describe. So is there actually someone who has that role or can adopt it?
    – Lilienthal
    Commented Feb 1, 2017 at 13:03
  • As I said, frankly, I would prefer a solution without a dedicated lead, that is why I am posting the question. Using a good old moderator would be the trivial solution, and if we find none other, then that is what it will be.
    – AnoE
    Commented Feb 1, 2017 at 15:01

2 Answers 2


I work in a somewhat similar environment, where people frequently take on tasks that others may have had some overlapping experience with.

I'd recommend you utilize a tool such as Slack (It's an IM tool, but you can send messages to 'channels' or groups, and message history doesn't dissapear when you close the window like Skype does. It's a fantastic tool and the past few companies i've been in have taken it to heart).

When you're going to start something, shoot a message to the group (You can also do this via email but let's face it email is terrible. If you have an IM tool, put together a group of contacts and send them all a message at once saying "Hey, I'm about to start working on this."

The rest of it is something you'll have to handle internally - You need to have an understanding that what you're saying is not an invitation for feedback on how you're developing something, but moreso a notification that you'll be spending time on it. This could be as simple as saying "I wanted to let you guys know I'll be working on this," but if they persist in picking apart how you're doing something, you may have to be direct and say that you aren't looking for suggestions on how to do it, or that you didn't want to take up their time looking for a solution on it. They should understand.

On top of that... Don't be afraid to exit the conversation if you don't think it's constructive. If all you have to say to them is "I'm letting you know I need to work on this so that you aren't also working on this", don't feel like you need to fall into a conversation when they ask how you're planning on executing Part A of your solution so that they can criticize it. I would just shoot them the message (If you're not looking for a response, email might be better) and go back to working, not responding unless it's important.


What about having each of them maintain a "CV" where they add every (Sub-)Project they work on? Every member of the team can search / browse the CVs of the others and can seek for peers they can discuss their current project. This way the process of adding does not provoke the rest of the team to discuss the topic.

They could also advertise topics / skills / assets they especially like or are good at, so one would know who's the sorting-algorithm-ninja, who has experience with $obscure-language and who's willing to discuss details of a data-structure for a whole afternoon. That might also include non-programming topics (finding a peer with some accounting know-how when you need to understand that finance-application might be helpful). This gives them a place to brag, without provoking immediate comments by the peers.

  • That is a good alternative to having meetings at all. Good idea in principle, but in the contect of this very question, I would prefer methods for keeping the actual meetings free from "derailment". The things they need (would in theory profit from) to discuss are more fine-granular than what one would write in a CV. I.e., it's more like "I found a nice Gem to solve this small problem in my rails application in a very convenient way" or "hey, let me show you this ultra cool AJAX thingamagic I used to make this GUI just a little more sleek" or something along that.
    – AnoE
    Commented Feb 1, 2017 at 15:04

You must log in to answer this question.

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