Why wasn't I invited to the meeting?

"I'm disappointed."

These were the first words to come from Damien in a recent one-to-one conversation we had.

"I feel like the team doesn't respect my position," he told me. "I'm trying to engage with them, but they aren't reciprocating."

Damien was clearly frustrated.

"They had a meeting last week, for example, and I really should have been there. But they didn't invite me," he continued, offering several examples of ways the team was excluding him and, he felt, making it difficult for him to do his job.

When he paused, I asked him if he had any idea why they didn't invite him to the meeting in question.

"That's exactly my dilemma," he said, "I can't figure out why they wouldn't."

"Well," I said, "Why should they invite you to the meeting?"

To me, the situation seemed clear: When putting this particular meeting together, Damien's teammates probably didn't think too hard about the guest list; they just invited the people who popped into their heads.

"Should they invite you because your job title indicates you should be there, or because they think you would make contributions that help them drive the project forward?" I asked. I reminded Damien that these are difficult questions, but they're important to consider.

My last question could be even more difficult to face: "Have you done anything in the recent past that demonstrates to the team that they would benefit from working more closely with you? What are some examples of those things?"

It's important to note that Damien's job title does indicate that he should not only be at meetings like the one in question, but that he should be leading those discussions. But, in an open organization, job titles and hierarchies don't drive behavior.

The culture at Red Hat (the open organization where I work) is built on four core values: freedom, accountability, commitment and courage. Everyday dilemmas like this one represent moments when those values come to life—if we take the time to think about them, that is.

It takes courage to recognize that what you're doing is not working, or that you are not contributing in a way the team finds valuable (the reason they aren't including you in discussions). It requires accountability to say, "I am going to acknowledge this and do something about it," rather than hoping other people will change their behavior. In order to actually demonstrate progress, making a concrete commitment to the team will be essential. In this scenario, the team with which Damien is working is using the value most often cited in open source communities: they are exercising their freedom to do what they think is right, despite Damien's objections.

The hope, of course, is that both parties in a situation like this would reflect in the same way: What can I do to create a better outcome (rather than waiting for the other side to act)? In the beginning of our conversation, Damien felt like his team needed to do things differently. No doubt they felt the same way about him. My goal became working with Damien to figure out what he could do, and, at the same time, I trusted that some team members would rise to challenge the entire team on with ways they could do things differently.

Damien left our conversation with the task of thinking about what his colleagues most needed from him. What could he do that would bring them the most value? If he could identify that, and demonstrate progress towards achieving it, then the team might be more motivated to work with him.

I found out later that his colleagues were having a similar conversation; they opened a dialog to talk about team members' expectations for one another and the ways they were (and were not) currently meeting those expectations.

The situation is still unfolding, but it illustrates a great example of the open organization principles in action. When team members set expectations of each other, and hold one another to them, having open dialog and sharing continual feedback becomes much more important than job titles and organizational structure.