Engineering teams that prioritize risk-taking over stability

At NexHealth, we value breaking rules and taking risks above everything else.

We’re disrupting and modernizing an old, slow, and closed industry. In order to move fast, we have to take risks and break rules both in our strategy and day-to-day operations. We will often push unfinished features in order to get user feedback, knowing that it is better to validate our direction before completing the work. We are comfortable with reverting and/or shelving features, too, should we need to course correct. We’re comfortable working out safe, reliable, but backdoor engineering solutions as long as it solves a customer problem.

In order to understand our philosophy and logic, you have to first understand our industry. Around the same time as the Affordable Care Act, the HITECH Act was passed. The HITECH Act incentivized (forced) doctors to go from paper patient records to digital paper records. In theory, this was great: digitizing records should open up more innovation. However, it had the opposite effect.

After the Act passed, hundreds to thousands of vendors developed Electronic Health Record Systems (EHRs) to help doctors digitize their records. Eighty percent of the EHRs were developed to be on-prem locally-hosted software. In addition, the systems were designed to be closed, meaning you cannot easily read or write data into the EHRs. While this helped vendors retain customers, it created a horrible experience for doctors, patients, and third-party developers that need access to those records.

Ten years later with a more mature EHR market, the problem is worse than ever. The industry is fragmented (no one owns more than 10% market share), data is siloed into closed on-prem databases, and healthcare innovation is slower than ever. NexHealth is one of the few companies in the space today disrupting this status quo. And we are not asking for permission. We’re opening up EHR systems and patient records to patients, doctors, and developers. If you’re curious “How?”, “Is this safe?”, or “Is this legal?” we’d love to talk! :) Today, we integrate with 35+ EHRs, 100+ developers, have 8M patients, and over 3K+ doctors on our platform.

Informed risk-taking is our way of life.

We work in the dating app market, which is both constantly changing and competitive. There are a ton of different products out there and in order to differentiate ourselves, we have to take risks to stand out. Our data science engineers are always tweaking and experimenting with our algorithm, and building custom algorithms to test in individual cities. As an engineer, you’re never expected to work outside of your role, but you absolutely have free range to work as cross-functionally as you want. If you have an idea for new features, marketing strategies, or recruiting, we hope you’ll pull data to substantiate it, make the pitch, and then run with it. The only limits on your career at CMB are the ones you set yourself.

We’re not a company of optimization or incrementalism; we consistently support each other in making big bets and finding out how to make the biggest impact we can.

This often means that we fail, so we choose to fail forward. Fail, learn, move on to the next. If you’re a perfectionist or risk-averse, you won’t be very happy at LDT at our current stage. We are currently in a run-around-and-break-shit phase and believe that done is better than perfect. All engineers are on the front lines, operate very close to production, and have complete autonomy to build, release, and revert.

Our technology moves very quickly, too. We don’t mean that in terms of using bleeding edge technology, but that we (probably because of our stage and ongoing search for product market fit) regularly add new tech into the stack, rip out experiments that didn't work, and replace early iterations of ideas as the product evolves.

What might be seen as “cutting corners” (be it some part of QA or rigor in test coverage), we see as necessary in order to meet deadlines. We always try to maximize how much we can fit into a sprint and go as close to committing as much as possible. We also don't worry about overcommitting. If we've estimated poorly and added too much to a sprint or phase, we reassess in the next planning stage and ask ourselves if projects are still a priority or have the goalposts moved (again)? The team members who have come from big and slow movers like Facebook and Google have thrived at how fast we work and get shit done here (after the initial shock that is 😉).