Organizational Culture

Values, Assumptions, Beliefs, Expectations

💡 If you see an apple, you expect to eat an apple, not an orange, and especially not a lemon!

A lot of contributors who invest in open-source projects may be disconnected in terms of unpaired values, assumptions, beliefs, and expectations pertaining to a project, also known as VABEs¹. Culture is a set of shared VABEs.

For the most part, this lack of connection is not contributors’ fault. In order to succeed, project’s leadership must be able to properly convey their values to others right from the start. Doing so allows to complete the entire puzzle, where each piece of the puzzle is comprised of individual ideas and solutions provided by contributors who share similar values, creating a positive feedback of growth. As long as we can communicate our values to the worldwide community properly, the better and more effective our interactions become.

The following lists consequences of not conveying our values to the worldwide community.

Wasted resources

“Why waste time on these ephemeral concepts? Aren’t decisions are made on a case by case basis?”

These kind of questions imply a particular attitude. The irony is that someone who knows the “ephemeral” word will likely not ask this question in the first place!

Nevertheless, I’d like those people to pay attention to shortcomings of having such a belief system. Ask yourself whether you’d like to waste your time on any of the things below instead:

• constantly disagree without an end;
• make contributors feel disappointed by rejecting their ideas;
• ignore contributors and make them feel that their ideas are worthless.

Unless you’re someone who has no ability for empathy and/or enjoys being a contrarian for the sake of it, doing those things above will most likely make you and everyone else feel exhausted. The time spent on unnecessary conflicts could be better spent on realizing your project’s vision instead! Time is the most valuable resource that we have in our possession, don’t you think?

Note that disagreement is not a bad thing in and of itself. Disagreements (or rather, differences in opinion) are at the heart of every fruitful discussion. This challenges different viewpoints that may lead to actual consensus. Disagreements only become an issue when they hinder the progress.

Killed innovation

“Ideas are cheap. Isn’t execution far more important?”

Remember that if someone’s idea doesn’t go in alignment with your project, it doesn’t necessarily mean that an idea is worthless. It simply means that such an idea can have a potential elsewhere.

Yes, some ideas may be truly stupid and even destructive. But if you find yourself needing to kill ideas² that you identify as potentially destructive for your project, why not just prevent this phenomenon from emerging in the first place?

When contributors come to your project and write elaborate proposals, and you end up rejecting their ideas, you kill ideas in a bad way, because those kind of ideas could’ve manifested as constructive given other opportunity and/or context.

If we talk about human values specifically, it has less to do with ideas themselves, but more about the danger of killing someone else’s enthusiasm. This is a crime against creative personality which hurts your image as a consequence.

The sad reality is that most leaders may not even realize that they are constantly killing ideas left and right. Why this happens? The need for rejecting and ignoring ideas arises when our own values clash with someone else’s polarized values, which create difficult-to-resolve conflicts. But in order to identify drastically contrasting values, they have to be uncovered before all else! These kind of conflicts are usually destructive rather than constructive, so it’s sane to prevent destructive conflicts.

You may respond that you have no control over what people propose, which is a natural train of thought. But we can always influence and direct individuals. Let me assure you that there does exist ways to minimize the flood of proposals, which is to define Development Philosophy, principles, etc.

Betrayal of trust

“Wouldn’t this lead to divisiveness?”

When contributors know exactly what kind of values the project follows, they can easily see for themselves whether:

• it’s the right project that they are looking for;
• their efforts will be recognized and actualized.

Otherwise, contributors won’t gain what they initially expected from the project, which leads to disappointment and eventual betrayal of trust, and this alone is much worse than the irrational fear of community division, because betrayal of trust is a guaranteed way to divide the community. Trust is quite fragile and it may be difficult to restore it.

Therefore, it’s very crucial to ensure that this never happens. If this happened for real, show that you’re responsible by accepting the failure, sincerely apologize! Otherwise, expect contributors to write books about it! 😉

Synchronicity is key

💡 Create a lighthouse, not a bug zapper!

While it’s likely impossible to solve all problems associated with collaboration, the good news is that the most straightforward solution which can solve most of the issues mentioned so far already exists.

As developers, we can do this by means of documentation! Remember that writing documentation is an essential skill of every professional developer. So why not document our values as well? Consider this recursive statement which summarizes values, assumptions, beliefs, and expectations behind what this book is trying to achieve:

I believe that documenting our values for projects that we set up to be developed by community itself is as important as documenting software’s API, because doing so creates realistic expectations. I believe that having this belief is beneficial, because it reflects my own values and values of other contributors, the kind of values that create prosperity. I assume that contributors who come together in a project want to achieve a common goal, and I expect that contributors want to find a common language in order to do so.

To iterate, everything that you’ve read so far assumes that you manage or would like to manage an open-source community-driven project, or people who are simply curious about this topic, since it’s not only about contributors, but users of the software that provide their valuable feedback.

If your project has the “community-driven” moniker assigned to it and you receive a push-back from the community of developers frequently, you should consider dropping that label from your project and make sure that you don’t give out a false expectation of your project being “all things for all people”. Otherwise, documenting project’s values is desired. Show that you value honesty and preciseness, not just with words, but with actions as well.

Given importance of this, it’s the responsibility of every healthy organization to declare and consistently follow their values. Therefore, it makes sense to dedicate some time to find our unexposed beliefs we have in mind for our projects. Assuming that you’d like to build and manage a successful community-driven project, all hidden assumptions must be revealed and actualized to the fullest extent, there should be no secrets.

At the same time, you are free not to do this, especially when freedom is seen as an inherent value behind open-source. This won’t necessarily lead to a disaster. But the fact that contributors meet together from all around the world creates a potential gap of misunderstanding between people who might share different and even conflicting values, so we better not leave this to luck alone.

References