Guide to ChemAxon's Culture
Page owners: Csizi, Tamas Garics, Andras Bakonyi, Zsolti Torok
Stakeholder of a team, an individual or an action
The stakeholders affect or are affected by the actions directly or indirectly. It is important to identify the stakeholders before decisions because their feedback may be needed to assess the risks and outcomes.
The owner of a problem area is responsible for solving the related problems in a way that will help the company in its mission and to achieve its goals. See the Ownership section and some other sections for details.
The evolution of our culture
ChemAxon has always grown organically without the use of external financing or merging with other companies. Our culture has also matured organically as the result of continuous changes - by keeping what works and dropping what doesn't. We continuously adapt to our ever changing environment. We expect that this evolution will never cease.
Driven by happiness
Our ambition is to enchant our users to the point they truly love using our products and services. In addition, it's important that our fellow colleagues feel happy and fulfilled within their work. However, happiness isn't reached when people remain permanently in their comfort zone. Problem solving may provide to be challenging at times, but we should give new ideas and different concepts a try, by stepping out of our comfort zones.
No ranks, no bosses, no hierarchy
ChemAxon is a flat organization. However, the company has a CEO (Csizi), so one can argue that the organization is not completely flat. Nevertheless, the CEO simply advocates systemic improvements, rather than controlling people directly. There are no ranks, no reports, no job titles, or any sort of set hierarchy at ChemAxon.
The advantage of a flat structure company is that individuals are free to self-organize, and perform their optimum best without bosses hindering possible progress.
We believe that a flat organization with a collaborative culture makes us more creative, innovative and adaptive. Still the culture and office workflows are the subject of continuous improvements made by its participants.
Self-organization implies that people collaborate and decide how they work towards company, product and team goals. Scrum masters / team coaches may help by facilitating the decision making. A high level of self-organization means that people from different teams ally voluntarily to solve cross-team or company level problems as they emerge. Such alliances can be temporary or longer term.
"I have a problem and nobody cares about it"
It seems either you should solve this problem (take the ownership of the solution), or find allies and form a temporary association/team to solve it. When you are working on the solution make sure you collect enough information from other stakeholders to prevent creating a bigger issue.
In some cases the cause of your problem is that other people or teams don't meet your expectations. It means that it's time to give them your feedback and together discuss how to improve the situation.
If you need help you can ask for example the advice of the team of coaches (SMAC).
We use Agile principles and methods to solve problems in collaborative and organized manners. Agile is a huge step towards self-organization. However, Agile isn't the answer for all challenges flat companies face. For example; decision making, scaling efforts and vision creation are very important areas where agile does not provide much help. We have to fill these gaps by channeling other approaches. (We are experimenting with Sociocracy 3.0.) Read on for more details.
Challenging assumptions, rather than conforming to them, is the key to building a creative organization.
Lean product development
Product development needs a continuously updated vision. Goals and priorities must be derived from market/user needs - keeping in mind that, what the users want and what they need are usually different. We use lean approaches, like Lean Startup or Lean UX for discovering what the users need. Product Owners must collect user feedback proactively and regularly before feeding the development team with further work. It's more important to build the 'right' product - rather than building the product in the right way. We use MVPs and adopt quick Build–Measure–Learn cycles for collecting feedback at early stages and as often as possible.
“Fail early, fail fast, fail often”
Of course failing isn't the goal. We would ultimately like to improve concepts or come up with something brilliant. However, there is no innovation without experimenting. Those who are afraid of failure are reluctant to experiment, so they cannot improve things effectively. People should never be the subject of blaming if something goes wrong.
- Fail early: test if you are going in the right direction as early as possible. Consider prototyping as a tool for early testing. If the test fails then change.
- Fail fast: have the courage to admit that you failed. Don't continue with something just because you have invested a lot of time or effort into it.
- Fail often: apply a quick Build–Measure–Learn cycle. Repeat the cycle until you find the satisfactory solution.
Decision making is perhaps the most challenging area of a flat organization's culture. Ideally, people who are the most affected by the outcome should solve the problem. However, when there are many participants, decision making is difficult.
Consensus doesn't scale
Reaching consensus (unanimous agreement) would be best, but the more people are involved the more difficult it is to achieve it. If too many people take part in the decision making process, then the outcome is often - unimaginative, too large, not experimental and dull. Changing the decision when it proves wrong is also very difficult, Consensus seeking is a big contributor of meetingitis.
Consent Decision Making
"Consent Decision Making explicitly invites people affected by decisions to consider proposals (or existing agreements or activities) and to evolve them, according to reasons why doing something stands in the way of (more) effective response to any organizational driver (i.e. any organizational requirement). Such reasons are presented as arguments, called Objections.
Objections are arguments that reveal how a proposal or existing agreement or activity leads to unintended consequences, or misses viable ways to improve flow of value in the organization."
From Consent Decision Making by James Priest.
Consent Decision Making (CDM) is a quite sophisticated process that can be very effective if it is run properly and participants have an appropriate insight about the issue but it requires practice. See the details in the document or watch a video about CDM.
- If the participants don't have enough insight on the topic then the decision can be wrongly made.
- Also, changing the decision is hard if many participants are required to gather for another meeting again. CDM works best in small teams which has regular meetings.
When several teams are involved in solving a common, high-level issues, the involved teams may send representatives to form a delegate team. This team may be temporary or permanent. The decisions made in the delegate team are acted upon in the teams it serves.
To prevent the scaling issues mentioned previously, the most effective option could be to assign an owner to delegate problem solving. The owner will collaborate with the stakeholders and seek their advice when needed before concluding a decision. See the 'Ownership' and 'Autonomy' sections for more details.
The owner is a decision maker
Teams and certain people are owners of various matters. Volunteers can also take on ownership of solving particular issues or challenging areas. The owner is a "dream keeper" who should seek the advice of stakeholders, but meanwhile should have the trust of others to be able to make decisions alone. The owners are accountable but they should solve the problems rather than follow the instructions of the stakeholders. The appropriate person is usually the one who has: the vision, the trust of others, and also feels responsible for solving the problem. This entails that stakeholders are open enough to live with decisions that are not necessarily what they prefer, but something they can accept. The owner can choose to delegate some decisions to others, but retains the overall responsibility of solving the problem. The owner is not necessarily the biggest expert in all aspects.
There may be tough cases when there is disagreement between the owner of the issue and some of the stakeholders which cannot be resolved. Big changes can be uncomfortable temporarily to several people who are affected but not necessarily have the insight for the decision. The owners' job is not to do what the stakeholders want but to solve the problems and improve the situation of the organization. She should be careful but brave enough to decide.
Multiple ownership is feasible, but more owners usually feel less responsibility than a sole owner would; additionally many meetings may be needed to move things forward. It is recommended that either one owner is the main owner or the owners split the scope among each other but collaborate in ideation and implementation.
Advantages over voting and consensus
- Effective decision making (scales well)
- Not all participants need a deep understanding of all details
- Fewer meetings
- The owner can experiment and change the decision quickly
- No majority or consensus is needed - (The minority can be right)
- Innovative ideas can be tested
- People (stakeholders) know who to turn to if they have input for a solution.
Examples for ownership
- See our Wall of Worries board for high level, cross-team issues. Cards on the board are issues owned by volunteers.
- Product owners (PO) create the vision of the product in a collaboration with users, developers, fellow product owners, business people, etc. They solve user problems but they don't just do what the individual users (or other stakeholders) want.
- Scrum masters / team coaches (SM) ensure their teams become and remain high performing and collaborative. For example they can change the framework the team uses (scrum, kanban, etc.) to increase effectivity.
- Development teams (including PO and SM) are responsible for the success of their products.
- The developers of the teams own the implementation and technical details of their products.
- The People Engagement Team is the owner of office and most HR issues.
- There have been several horizontal teams formed by enthusiastic people to solve specific problems:
- ChemAxon Pass, now CAS (Central Authentication Service) team to create a common solution for authentication
- Phabricator is a solution to make software reviews mandatory (one owner: Balázs).
- Teams for improving the build and release system (Build Squad, Gluon, Nucleus)
- Documentation horizontal team (facilitator: Eszter)
- Compensation system reinventing (Kriszti, András B, Zsolti, ...)
Autonomy = courage + responsibility + trust
Autonomy (freedom) is an important ingredient of self-organization. Autonomy doesn't work without courage, trust and responsibility. People who are brave enough (or trust themselves) and take responsibility will earn trust from their stakeholders. Those individuals are generally able to solve problems the most effectively. Rather than asking for permission from others, gathering peer/stakeholder advice has to precede important decisions. The bigger the decision the more feedback needs to be collected from the relevant stakeholders. However sometimes there are time constraints, so as Grace Hopper put it, it's often "easier to ask forgiveness than it is to get permission" or advice.
We value feedback because it helps identifying what works and what doesn't. Providing feedback early and often is important input for continuous improvement. When someone performs exceptionally well in their work, it's excellent to praise them for it. Feedback improves mood and motivation while reinforcing positive patterns.
The lack of feedback may easily create negative feelings. Such conflicts could easily be prevented if expectations are discussed. If you feel that you are in such a situation, then you are expected to express them in a nonviolent manner to your colleagues. You are in charge of your own well being. Various processes, tools and workshops are available to help you to give feedback frequently and regularly.
Collaboration is much easier when people can discuss issues verbally presently, without organizing meetings. Unplanned information sharing and osmotic communication at spontaneous times/places is important for efficient collaboration. To achieve this, collecting work together is preferred over working individually. In case of collaboration between remote offices, special attention is needed to minimize miscommunication issues.
In a 'boss-less' organization it is important that teams have missions that they collaboratively create and maintain. The mission is important for both the team members and the stakeholders of the team in order to determine - what is, and what is not, in the domain of the team. These missions are available from Umbrella, our people and team directory.
Every team is responsible for having the right team composition. The Scrum Master / Team Coach owns the decisions related to team composition and can delegate them to the team if the group is mature enough.
Moving between teams
Being a member of a team does not mean being stuck within it forever. Encourage people to switch teams when they feel they could contribute more somewhere else. If the desired team agrees to have you as a member - then you can join!
What if someone is not a good fit?
If someone is not the right fit and the team decides to continue without that person, then that individual has to find another team. If all options are exhausted then the person best seek other opportunities and leave the company.
Vertical and horizontal teams
Most people at ChemAxon belong to a, so called, vertical team which is cross-functional. Cross-functionality means that people have many different skill sets. Teams with cross-functionality can generate great value without depending much on other teams or individuals, because they have all the necessary skills within the team for achieving success. However, to reach larger scale goals or to solve cross-team problems, collaboration is vital among members of different vertical teams. Horizontal teams can contribute to solving regular cross-team issues. For example, if there is dependency between products that two teams build together, then client focused developers may form a horizontal front-end team.
Neither one of us is cleverer than all of us together. It seems pretty straightforward but it remains true. So help others when you can.
The company has a collaborative atmosphere so don't be afraid to ask anyone about whatever you may wish. Asking for advice doesn't mean you're not good enough - It means you're trying to improve and that's marvelous.
Collaboration within a team
W e believe that the most important contributor of team success is collaboration. See the results of a research at Google in this topic.
Collaboration between teams
If you have an idea or issue that might affect other teams then you should collaborate with them to find an acceptable solution for all parties.
Collaboration with our customers
Our goal is to have happy customers - To achieve that we should earn their trust by transparency and understanding their specific needs. If they don't trust us they will try to micromanage us and the solution won't be right for the end-users.
Behaviors that inhibit collaboration
Our default attitude in ChemAxon is being transparent.
We build everything we do in plain sight, without walls, silos or doors. To make the right decisions, transparency of artifacts, processes and actions is necessary. The less transparent we are, the worse decisions we make, the more risk and less value we bring to the table.
So when we work together on concepts and help others; or even when we're drinking coffee, we fully expose the activities and openly share both our successes and failures.
Our peoples experience and knowledge are considered one of the most valuable assets our company has. Therefore, that's why we heavily support the "always learning" attitude. The company, the team and individuals are continuously improving in different areas. Individuals with the T-shaped skillset provide a great amount of flexibility while broadening horizons for the whole team. This way we keep our adaptability when confronting the unknown.
If there isn't a career ladder to climb and no extrinsic punishment/reward then what motivates us? Intrinsic motivation based on autonomy, mastery and purpose works better than extrinsic. You should be provided with a helpful work environment where you don’t have to do unnecessary things just because of rigid policies. Teamwork allows you to find what you are best at, but also invites you to experiment with new tasks. Volunteering is a team asset and ideas that create value are tremendously supported. Dare to enjoy your work? Don’t let obstacles kill your passion!
How do our products help the world? We create bio- and cheminformatics software that aids scientists in discovering drugs/medicine to potentially cure diseases. Our solutions contribute to decreasing the number of in-vitro and in-vivo experiments - meaning less waste and fewer experiments on animals before a drug is launched on the market. Our software tools likewise benefit research within other industries, such as: cosmetics, OLED, LCD, agro, food, etc. We proudly support nonprofit scholarly research endeavors, in parallel with both online and offline teaching at academic institutions/organizations all over the world.
Continuous improvement is a periodical activity where teams solve problems together that obstruct them from reaching their goals. Issues related to quality, speed, team collaboration, processes, etc are regularly reviewed. Teams should allocate dedicated time, at least once a month, for continuous improvement. These routine meetings typically are retrospective meetings. It is everyone's responsibility to improve the way of work within the team but also among teams.
We are the owners of our way of work, and our processes. We have to design and implement our own workflow and it is our responsibility to follow it. These practices should help our work and make us more effective. So, if a process does not help us then it is our responsibility to change it or simply remove it all together. When we change or remove a process we should make sure that those who depend on our work are not harmed significantly and are notified about the changes in time.