Openness

We build our software in the open. We collaborate with users in the open. And we strive to build a radically open culture.

Be open about as many things as possible. By making information public we can reduce the threshold to contribution and make collaboration easier.

Openness creates awareness for MayaData, allows us to reach out to people that care about our culture, it gets us more and faster feedback from people outside the company, and makes it easier to collaborate with them. It is also about sharing great software, documentation, examples, lessons, and processes with the world in the spirit of open source, which we believe creates more value than it captures.

Everyone can remind anyone in the company about our values. If there is a disagreement about the interpretations, the discussion can be escalated to more people within the company without repercussions.

Public by default

Everything at MayaData is public by default unless it’s documented otherwise here. A good practice is to move DMs in chat onto a public channel, perhaps creating a thread to limit impact on that channel. This way for example anyone can search on a subject and find your conversation, thereby reducing ramp up time and limiting costs of coordination.

Examples of not public information.

Not public by default are the following items that may impact our users and employees and doesn’t benefit being public:

Security vulnerabilities are not public since it would allow attackers to compromise MayaData installations.
Financial information, including revenue and costs for the company.
Deals with external parties like contracts and approving and paying invoices.
Content that would violate confidentiality for a MayaData team-member, customer, or user.
Legal discussions are not public due to the purpose of Attorney-Client Privilege.
Some information is kept confidential by the People Group to protect the privacy, safety, and security of team members and applicants.
Partnerships with other companies are not public since the partners are frequently not comfortable with that.
Acquisition offers for us are not public since informing people of an acquisition that might not happen can be very disruptive.
Acquisition offers we give are not public since the organization being acquired frequently prefers to have them stay private.
Customer information in issues.
Competitive sales and marketing campaign planning is confidential since we want to minimize the time the competition has to respond to it.
When we discuss a customer by name that is not public unless we're sure the customer is OK with that.
Plans for reorganizations are not public and on a need-to-know basis within the organization. Reorganizations cause disruption and the plans tend to change a lot before being finalized, so being public about them prolongs the disruption. We will keep relevant team-members informed whenever possible.
R&D that has not made it to the published road map or the open source POC level is not public.
There is a huge amount that we all know about why users buy, what are the weaknesses of competitors, where Kubernetes and standards like NVMe and similar area headed that are not proprietary and yet also fit into a level of understanding that is uncommon in the broader industry and as such should be treated as valuable and discussed only when needed to help users, customers, partners and other stakeholders

Share problems you run into, ask for help, be forthcoming with information and speak up. For example, consider making private issues public wherever possible so that we can all learn from the experience.

Measure what matters and publish it publicly

Agree in writing on measurable goals. Within the company we use public OKRs for that. You don't always get results and this will result in criticism from yourself and/or others. We believe our talents can be developed through hard work, good strategies, and input from others. We try to hire people based on their trajectory, not their pedigree.

Write things down

We document everything: in the handbook, in meeting notes, in issues. We do that because "the faintest pencil is better than the sharpest memory." It is far more efficient to read a document at your convenience than to have to ask and explain. Having something in version control also lets everyone contribute suggestions to improve it.

Bias towards asynchronous communication

Take initiative to operate asynchronously whenever possible. This shows care and consideration for those who may not be in the same time zone, are traveling outside of their usual time zone, or are structuring their day around pressing commitments at home or in their community. In other words, use chat, GitHub or other issue tracker and so forth whenever possible.

Anyone and anything can be questioned.

Any past decisions and guidelines are open to questioning as long as you act in accordance with them until they are changed.

Disagree and commit.

Everything can be questioned but as long as a decision is in place we expect people to commit to executing it, which is a common principle. Sometimes you will not fully understand a decision. Feel free to bring it up later as we may need to revisit the decision. In the meantime, keep going.

Say why, not just what

Whenever possible, take the extra time to explain changes in policies or approaches - especially when you are adding additional steps that someone must take before their work has an impact; as an example, additional test and validation changes are inevitable and also should be well explained. A change with no public explanation can lead to a lot of extra rounds of questioning and can be considered a kind of “communication debt” that must be paid off at some point. Avoid using terms such as "industry standard" or "best practices" as they are vague, opaque, and don't provide enough context as a reason for a change.

MayaData Culture