MayaData’s values are People First, Listen to Learn, Openness, Ownership and Winning together spelled as PLOW. Our values are interlinked and work together to protect our culture. This document gives some examples that make our PLOW actionable.
- PLOW
- About our Values
- People First
- Make someone’s day today
- Kindness
- Say thanks
- Negative is 1-1
- Speakup
- Get to know each other
- Give feedback effectively
- Don't pull rank
- Don’t label other teams
- Assume positive intent
- Address behavior, but don't label people
- Say sorry
- No ego
- People are not their work
- Blameless problem solving
- Dogfooding
- Diversity and inclusion are fundamental to the success of MayaData.
- Shift working hours for a cause
- Be a mentor
- Family and friends first, work second
- Celebrate accomplishments with offsite events
- Listen to learn
- Openness
- Ownership
- Winning
We take inspiration from other companies, and we always go for solutions that are easy to implement. Just like the rest of our work, we continually adjust our values and strive always to make them better. Everyone is welcome to suggest improvements.
All business - and arguably life itself - comes down to people. Whether working with our team, or the community, or customers, or partners or others - we strive to remember and to reinforce our common humanity.
Helping others is a priority, even when it is not immediately related to the goals that you are trying to achieve. Similarly, you can rely on others for help and advice - in fact; you're expected to do so. Anyone can chime in on any subject, just like in good families. As companies grow their speed of decision making goes down since there are more people involved. When you are the person who’s responsible for the work, you decide how to do it, but you should always take the suggestions seriously and try to respond and explain why it may or may not have been implemented.
It is a long journey. Over time happy team members are healthier, productive and bring positivity to others. Remember, we all want to be in a group where we are happy. Be thoughtful and kind just because you can. Catch people doing things right. Help a team member who's having a difficult time or need mentors. Be a good listener. Share your joy.
We value caring for others. Give as much positive feedback as you can and do it in a public way.
Recognize the people that helped you publicly, for example in our #say-thanks chat channel or via LinkedIn Give Kudos.
Give negative feedback in the smallest setting possible, one-on-one video calls are preferred. Remember, we are all on the same boat. And the purpose of negative feedback is not to hurt a person, it is go get MayaData better and better and win together and to help that person learn and progress.
If you are unhappy with anything (your duties, your colleague, your boss, your salary, your location, your computer, the sloppiness of a colleague, or anything else) please let your boss, or the CEO, know as soon as you realize it. We want to solve problems while they are small.
We use a lot of Slack communication and if you know the person behind the text it will be easier to prevent conflicts. Please help encourage people to get to know each other on a personal level through our team calls, virtual coffee breaks, events and during company gatherings.
Giving feedback is challenging, but it's important to deliver it effectively. When providing feedback, always make it about the work itself; focus on the business impact and not the person. Make sure to provide at least one clear and recent example. If a person is going through a hard time in their personal life, then take that into account. An example of giving positive feedback is our #say-thanks chat channel. For managers, it's important to realize that employees react to a negative incident with their managers six times more strongly than they do to a positive one. Keeping that in mind, if an error is so inconsequential that the value gained from providing criticism is low, it might make sense to keep that feedback to yourself. In the situations where negative feedback must be given, focus on the purpose for that feedback: to improve the employee’s performance going forward. Give recognition generously, in the open, and often to generate more engagement from your team
If you have to remind someone of the position you have in the company you're doing something wrong, people already know we have a hierarchical decision making process. Explain why you're making the decision and respect everyone irrespective of their function.
An anti pattern that counters being people first is being “group first”. Beware the rise of capitalized words to identify groups of unclearly defined “others.” For example, avoid phrases like “Support just does not understand our code” or “Engineering does not care about us.” Similarly, remember there is one team (and yes one system…) and that this MayaData team is comprised of all of us plus the community of users, customers and partners. So avoid prioritizing the needs of ones own immediate coworkers over what is best for the user, company, community and other stakeholders. When in doubt prioritize the needs of the user and especially customers above all else.
We naturally have a double standard when it comes to the actions of others. We blame circumstances for our own mistakes, but individuals for theirs. This double standard is called the Fundamental Attribution Error. In order to mitigate this bias you should always assume positive intent in your interactions with others, respecting their expertise and giving them grace in the face of what you might perceive as mistakes.
There is a lot of good in this article about not wanting jerks on our team, but we believe that jerk is a label for behavior rather than an inherent classification of a person. We avoid classifications.
If you made a mistake, apologize. Saying sorry is not a sign of weakness but one of strength. The people that do the most work will likely make the most mistakes. Additionally, when we share our mistakes and bring attention to them, others can learn from us, and the same mistake is less likely to be repeated by someone else.
Don't defend a point to win an argument or double-down on a mistake. You are not your work; you don't have to defend your point. You do have to search for the right answer with help from others.
Always make suggestions about examples of work, not the person. Say, "you didn't respond to my feedback about the design" instead of "you never listen". And, when receiving feedback, keep in mind that feedback is the best way to improve and that others want to see you succeed.
Investigate mistakes in a way that focuses on the situational aspects of a failure’s mechanism and the decision-making process that led to the failure rather than cast blame on a person or team. We hold blameless root cause analyses and retrospectives for stakeholders to speak up without fear of punishment or retribution.
We use our own product. Our SaaS service uses data management and tools that we deliver to our customers. We upgrade to the latest version before publishing it for general consumption.
We aim to make a significant impact in our efforts to foster an environment where everyone can thrive. We actively chose to build and institutionalize a culture that is inclusive and supports all employees equally in the process of achieving their professional goals. We hire globally and encourage hiring in a diverse set of countries. We work to make everyone feel welcome and to increase the participation of underrepresented minorities and nationalities in our community and company.
Do not make jokes or unfriendly remarks about race, ethnic origin, skin color, gender, or sexual orientation. Everyone has the right to feel safe when working for MayaData. We do not tolerate abuse, harassment, exclusion, discrimination or retaliation by/of any community members, including our employees. You can always refuse to deal with people who treat you badly and get out of situations that make you feel uncomfortable.
Caregiving, outreach programs, and community service do not conveniently wait for regular business hours to conclude. If there's a cause or community effort taking place, feel welcome to work with your manager and shift your working hours to be available during a period where you'll have the greatest impact for good. For colleagues supporting others during these causes, document everything and strive to post recordings so it's easy for them to catch up.
People feel more included when they're supported.
Long lasting relationships are the rocks of life and come before work.
While being frugal about spending, we also make opportunities for celebrating our accomplishments and bonding with other team members over offsite events. Our ambition is to have an all-company annual offsite meeting in the coming years. Until that happens, we will make sure the people in closer geographic circles will have quarterly events. For instance, an offsite lunch in the first and third quarters, an offsite weekend outing in the second quarter, and half-day fun activities in the fourth quarter.
Listen to users in the openebs-users, sig-storage, kubernetes / litmus channels and various other social channels online and offline, ask clarifying questions and even just ask them whether your understanding is correct by using phrases like “can you confirm that I got it right? You are experiencing X and would like to understand Y?”. Learn and document the use cases that users are trying to solve.
Listen to peers and their fears about the solution. The fears may be founded on the research and experience they bring. Validate possible solutions by talking to users.
We know we must rely on others for the expertise they have that we don't. It's ok to admit you don't know something and to ask for help, even if doing so makes you feel vulnerable. It is never too late to ask a question, and by doing so you can get the information you need to produce results and to strengthen your own skills as well as Mayadata as a whole. After your question is answered, please document the answer so that it can be shared. Don't display surprise when people say they don't know something, as it is important that everyone feels comfortable saying "I don't know" and "I don't understand." (As inspired by Recurse.)
People joining the company frequently are hesitant to provide feedback. At MayaData we should be more accepting of people taking initiative in trying to improve things. You must make them feel comfortable and allow others contribute to your domain. Actively seek feedback. Again, do not label people or teams and don’t forget your primary allegiances should be to customer success and to the company.
Use the simplest and most boring solution for a problem, and remember that “boring” should not be conflated with “bad” or “technical debt.” The speed of innovation for our organization and product is constrained by the total complexity we have added so far, so every little reduction in complexity helps. Don’t pick an interesting technology just to make your work more fun; using established, popular tech will ensure a more stable and more familiar experience for you and other contributors.
Make a conscious effort to recognize the constraints of others within the team. For example, sales is hard because you are dependent on another organization, and development is hard because you have to preserve the ability to quickly improve the product in the future.
Optimize solutions globally for the broader MayaData community and specifically for our customers and users. Making a process efficient for one person or a small group may not be the most efficient outcome for the whole community. As an example, it may be best to choose a process making things slightly less efficient for you while making things massively more efficient for thousands of customers. In a decision, ask yourself "for whom does this need to be most efficient?". Quite often, the answer may be your users, contributors, customers, or team members that are dependent upon your decision. When in doubt, choose to understand, support, help and delight the customer user.
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.
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.
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.
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.
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.
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.
Any past decisions and guidelines are open to questioning as long as you act in accordance with them until they are changed.
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.
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.
We want each team member to be a manager of one who doesn't need daily check-ins to achieve their goals.
We expect team members to complete tasks that they pick up or are assigned. Having a task means you are responsible for anticipating and solving problems. As an owner you are responsible for overcoming challenges and there are no excuses. Take initiative and proactively inform stakeholders when there is something you might not be able to solve.
No need to brainstorm, wait for consensus, or do with two what you can do yourself. If you think it is better than what is there now do it, no need to wait for something polished. A task done today is better than a polished result delayed indefinitely.
We care about what you achieve; the code you shipped, the user you made happy, and the team member you helped. Someone who took the afternoon off shouldn't feel like they did something wrong. You don't have to defend how you spend your day. We trust team members to do the right thing instead of having rigid rules. If you are working too many hours, talk to your manager to discuss solutions.
You should have clear objectives and the freedom to work on them as you see fit. If a meeting doesn't seem interesting and someone's active participation is not critical to the outcome of the meeting, they can always opt to not attend, or during a video call they can work on other things if they want. Staying in the call may still make sense even if you are working on other tasks, so other peers can ping you and get fast answers when needed. This is particularly useful in multi-purpose meetings where you may be involved for just a few minutes.
This name comes from the quick guide to Stripe's culture. Our definition of global optimization is that you do what is best for the organization as a whole. Don't optimize for the goals of your immediate team when it negatively impacts the goals of other teams, our customer users, and/or the company. Those goals are also your problem and your job. Keep your immediate team as lean as possible, and help other teams achieve their goals.
Consider the time investment you are asking others to make with meetings and permission process. Try to avoid meetings, and if one is necessary, try to make attendance optional for as many people as possible. Any meeting should have an agenda linked from the invite, you should document the outcome. Instead of having people ask permission, trust their judgment and offer a consultation process if they have questions.
Every dollar we spend will have to be earned back; be as frugal with company money as you are with your own. Amazon states it best: "Accomplish more with less. Constraints breed resourcefulness, self-sufficiency and invention. There are no extra points for growing headcount, budget size or fixed expense.”
When possible we give people the responsibility to make a decision and hold them accountable for that instead of imposing rules and approval processes.
Not every problem should lead to a new process to prevent them. Additional processes make all actions more inefficient, a mistake only affects one.
Use narratives, check sheets, and other tools If you are proposing a new approach, sometimes a meeting isn’t enough and neither is a chat discussion. If you believe MayaData teams or the broader community or others need to align in a certain way to achieve an outcome, please take the time to articulate your reasoning in narrative form. This approach borrows heavily on the narrative structure used by Amazon.
Another technique we embrace is the use of criteria based trade off matrices; this approach starts with outlining the problem and 2-3 alternatives, then turns to listing the criteria by which these alternatives can be judged, and then turns to creating weights for each of these criteria.
The use of Narratives and Trade Off Matricies are important aspects of our internal operating system. Workshops and onboarding training sessions help to distribute these important algorithms.
Working at MayaData will expose you to situations of various levels of difficulty and complexity. This requires focus, and the ability to defer gratification. We value the ability to maintain focus and motivation when work is tough and asking for help when needed.
We prefer making results count over perfecting the process. We assume nothing and we keep pushing ourselves until the job is done. We keep our promises and make sure our people keep their promises.
A winner knows deep down that she or he deserves to win and that confidence itself - no matter what the situation - is crucial to achieve a positive outcome. There is rarely success without commitment and rarely commitment without confidence.
We win as a single team and we take pride in contributing towards make each other succeed. If anyone is blocked by you, on a question, your approval, or a merge request review, your top priority is always to unblock them, either directly or through helping them find someone else who can, even if this takes time away from your own or your immediate team's priorities.
At an exponentially scaling startup time gained or lost has compounding effects. Try to get the results as fast as possible so the compounding of results can begin and we can focus on the next improvement.
While we iterate with small changes, we strive for large, ambitious results. You keep picking yourself up, dusting yourself off, and quickly get going again having learned a little more.
It's important that we keep our focus on action, and don't fall into the trap of analysis paralysis or sticking to a slow, quiet path without risk. Decisions should be thoughtful, but delivering fast results requires the fearless acceptance of occasionally making mistakes; our bias for action also allows us to course correct quickly.
The ability to accept that there are things that we don’t know about the work we’re trying to do, and that the best way to drive out that uncertainty is not by layering analysis and conjecture over it, but rather accepting it and moving forward, driving it out as we go along. Wrong solutions can be fixed, but non-existent ones aren’t adjustable at all. The Clever PM Blog.
We value constant improvement by iterating quickly, month after month. If a task is too big to deliver in one month, cut the scope.
We do the smallest thing possible and get it out as quickly as possible. This value is the one people most misunderstood when they join MayaData. People are trained that if you don't deliver a perfect or polished thing you get dinged for it. If you do just one piece of something you have to come back to it. Doing the whole thing seems more efficient, even though it isn't. If the complete picture is not clear your work might not be perceived as you want it to be perceived. It seems better to make a comprehensive product. They see other people in the MayaData organization being really effective with iteration but don't know how to make the transition, and it's hard to shake the fear that constant iteration can lead to shipping lower-quality work or a worse product.
However, if we take smaller steps and ship smaller simpler features, we get feedback sooner. Instead of spending time working on the wrong feature or going in the wrong direction, we can ship the smallest product, receive fast feedback, and course correct.
The way to resolve this is to write down only what you can do with the time you have for this project right now. That might be 5 minutes or 2 hours. Think of what you can complete in that time that would improve the current situation. Don't write a large plan, only write the first step. Trust that you'll know better how to proceed after something is released. You're doing it right if you're slightly embarrassed by the minimal feature set shipped in the first iteration.
People might ask why something was not perfect. In that case, mention that it was an iteration, you spent only "x" amount of time on it, and that the next iteration will contain "y" and be ready on "z".
We believe great companies sound negative because they focus on what they can improve, not on what is working. Our first question in every conversation with someone outside the company should be: what do you think we can improve? This doesn't mean we don't recognize our successes, for example see our Say Thanks value. We are positive about the future of the company; we are present day pessimists and long term optimists.
In some cases, rapid iteration can get in the way of results. For example when adjusting our marketing messaging (where consistency is key), product categories (where we've set development plans), sales methodologies (where we've trained our teams) and this values page (where we use the values to guide all MayaData team-members). In those instances we add additional review to the approval process, not to prohibit, but to be more deliberate in our iteration. The change process is documented on the page and takes place via merge request approvals.
Enable everybody involved to come to the same conclusion as you. This not only involves reasoning, but also, for example providing raw data and not just plots; scripts to automate tasks and not just the work they have done; and documenting steps while analyzing a problem. Do your best to make the line of thinking transparent to others even if they may disagree. Increases accountability when making decisions and difficult choices.
Every job has work that’s less fun than other parts. Every team has projects that succeed, and projects that fail. One of the key determinants of winning individuals is to embrace what you can learn from failure and what you can learn from the parts of the job that you don’t like. Is there a rote task that needs doing and no one wants to do? Figure out how to automate it, how to make it more efficient, or how to do without it at all. Is something wrong with your project and everything is on fire? What can you learn? It’s only a mistake if you do it twice; otherwise it’s just something that you learned from.