As an engineering organization, we work closely together and in collaboration with other functions (especially Product, Design and Data Science) to build and ship product that delivers value to customers. As we operate, there are certain behaviors and approaches to decision making—in addition to our Cedar values—that enable us to be more effective in the jobs we do. In order to continue and build upon this success, we have decided to identify and list the engineering values that we believe set us apart as an organization, and inform how we work day in and day out.
1. Learn, share, help
It is everyone’s responsibility to learn, share those learnings and step up to help others. Collaboration is key.
It is critical that people are able to learn and improve their skills, develop within the company and then leverage their additional knowledge and expertise to help grow others. We achieve this through a wide variety of methods such as retros, post-mortems, tech talks, maker demos, team feedback, manager feedback and mentorship. Best practices and guidelines should be formalized and shared so they can be leveraged by the rest of the team.
In addition, we highly value a culture of “how can I help?” where people are ready to step up and help others when they see problems or issues, going beyond the call of duty of their role. A key example of this is in how we work and collaborate with other teams—we're here to solve some of the most pressing problems in healthcare, which means we work cross-functionally and not draw hard lines between work we will and won't do. This has been true since Cedar was founded five years ago—we build product as a cross-functional team and implement clients as a cross-functional team.
People ensure they are active participants in conversations they are in. This does not mean they have to be vocal as part of the meetings but they should either be learning from it or contributing to it.
2. Release quality, release early, release often
We maintain velocity by releasing code that meets high-quality standards regularly and incrementally.
By holding high standards for the quality of code we release we can increase the velocity with which we release. It is tempting to see the idea of releasing quality as a potential roadblock for early and often releasing, however, if we release low-quality code this will impede us as we will be spending time dealing with bugs and release issues.
Releasing often helps us increase the velocity of product development and to identify what works and what doesn’t. Long release cycles are very hard to maintain and very risky to roll out. By releasing every day we make sure that any issues can be addressed right away and do not accumulate. This does not mean move fast and break things. We should hold a high bar for what we release to maximize the value we deliver and minimize the effort required fixing issues and bugs.
We are all responsible to do things that enable this. As a growing organization it is crucial we test what we ship to production. Without tests, we would not have confidence in the quality of what we are shipping, meaning the development velocity would decrease to the point that any change would be too risky to make.
3. Process pays rent
Process costs effort and resources so we should be thoughtful about when we introduce it, but do so when it adds meaningful net value and remove it where it doesn't.
Adding processes can be highly beneficial to improving outcomes through standardizing ways of working. When we see opportunities to add value by introducing a new process we should do so. However, adding processes comes at a cost, so we want to ensure any new processes are value-adding and be very thoughtful about introducing new ones.
4. Explicit over implicit
In both code and communication, we value being clear and explicit over clever and implicit.
Communication is critical to a successful engineering organization and it spans all levels of interactions. We value clear code over clever code where the intent is more explicitly understandable. When this is not possible to do through code alone, it is useful to add comments to explain intent. This enables us to review and build upon existing code more effectively and lowers the likelihood of bugs and other issues.
In addition, we want our communications and responsibilities to be clear both within engineering as well as with other functions. This is especially important across maker functions with whom we interact constantly. Having a clear understanding of who is responsible and accountable for what will ensure things do not get dropped and effort does not get unnecessarily replicated.
A good question to ask about code is ‘if a junior engineer works with this code, can we be confident they won't break it?’.
5. Safety first
Everyone is responsible for the safety and security of patient data, and it is not something we compromise on.
Patient data belongs to the patient and we must take care to safeguard it and use it appropriately. This is important across all Cedar employees but especially for engineers whose work is meaningfully impacted by this on a day-to-day basis. Know the limits of your knowledge, stay within guardrails, don't be afraid to ask.
Putting our values into practice
We strive to ensure all engineers know and understand these values, keep them at the forefront of their minds and make sure they and others are adhering to them. These are not an exhaustive list but are considered the most important behaviors that will empower our success.
In order for our values to enable, they should empower better decision making as individuals and an organization. That being said, the core responsibility of Engineering is to build and ship exceptional products quickly, in collaboration with other functions at Cedar. In other words, we should just build the product.
