At OmbuLabs we have many values that have been key to our success. This is an article about values that differentiate our company from the rest.
Every team member is expected to follow these values, especially when things get tough. This is a living document: It's open source and open to enhancements by design. We have been tweaking these values ever since I started the company.
We can't run a successful consultancy if we don’t value and respect every team member. We don't want people who "live to work". Workaholism is toxic and it leads to burnout. We strive to maintain a healthy work/life balance, to "work to live" a great life, and to grow as professionals within the company.
In terms of our communication, we adhere to the contributor covenant v2.0, not just for our open source projects, but also for any interaction we have with team members: CODEOFCONDUCT.md
Challenging Projects over Profitable Projects
We value interesting challenges more than high-paying contracts. We are in the problem-solving business for real companies. We won't work on cool-sounding solutions looking for a problem that doesn't exist. We will only work with businesses and entrepreneurs who have real problems. The only way to be great problem solvers is to understand and believe in our clients' businesses.
Talent is Everywhere
The value of our team will always be higher than the sum of the value of each team member. There is value in team synergy and our interactions. In sports, team work beats raw talent every time. This applies equally in our work environment.
We won't let geographical boundaries stop us from hiring the best person for the job. As long as our team members can communicate properly, distance won't be an issue.
There is great value in diversity and we must strive to foster a diverse workforce.
Open by Default
Everything we do should be open by default. We want to have open communications, contribute to open source projects, give back to our communities, and become thought leaders in our industry. Openness is key to our leadership. When starting a project, we should ask ourselves: "Is there any reason to make this a closed source project?"
There must be a solid reason to start a new closed source project. Otherwise, our projects should be open by default.
We are here to pay off technical debt and invest in our clients' assets. We will always strive to leave legacy systems in better shape than when we started working on them.
This does not simply apply to code. It also applies to our clients' culture, processes, dependencies, code coverage, documentation, best practices, and anything that will make our client's life easier in the long term.
We are here to learn from our mistakes. The only unforgivable mistake is to not learn from our mistakes.
We find value in other ideas, practices, and techniques. To name a few:
We want to apply agile methodologies in every project we work on. Some projects might require us to implement SCRUM, others might be better suited for XP. As an agile team we must always keep this in mind:
We don't commit to pair program 100% of the time. We commit to do pair programming when it's the best course of action. We find a lot of value in this technique as a way to share knowledge, find the best solution, and produce high-quality code.
This technique is key to humanizing our co-workers: When we pair with our teammate we connect on a deeper level with another human being. When onboarding new team members to our company and our projects we should rely heavily on pair programming.
We believe that diverse teams are smarter teams. There is value in all kinds of diversity. Making sure that we assemble our team with talented and diverse people from all over the world is the best way to stay competitive in an industry with major problems in diversity.
We value diversity in our team's skillset and experience. A team member with less experience gives us the opportunity to coach and mentor them into becoming better professionals by following our values. Teaching shall always be considered a great way to become better professionals.
We don't do TDD 100% of the time, but we see value in doing this when the time is right. It's a technique that we should consider everytime we set out to solve a difficult problem, fix a bug, or face increasing uncertainty.
We will strive to address problems head on. Every time there is a system failure in the company, we will schedule a 5 Whys call to figure out what went wrong and what could be improved moving forward.
These meetings are not a witch hunt, they are a safe space for us to share our experience, thoughts, and feelings. By following the takeaways discovered in these meetings, we will avoid making the same mistakes over and over again.
If our Slack conversations are all about work, there is something we are doing wrong. We will always try to have fun and think of some our channels as the "watercooler" for our remote team (For example: https://github.com/ombulabs/blog/pull/404#pullrequestreview-371545098)
We will strive to do a one-week team retreat every year. This will give us the opportunity to connect on a different level. Team retreats will combine a bunch of activities: leadership talks; fun activities; games; lunches; dinners; group discussions; meme studies; and time off to have fun!
These values are not written in stone. They are part of an open source project which will continue to evolve as our culture, people, and leadership evolves.
If you think a topic should be added or revisited in our core values, please submit an issue or pull request over here: https://github.com/ombulabs/blog
When in doubt, come back to this page to understand why we do things the way we do.