#23 - How to innovate in a highly regulated environment | Jeremy Wight, VP Engineering at CareMessage

Reading is caring 🤗

Hey friends, I’m thrilled to invite Jeremy Wight, VP of Engineering at CareMessage today, to discuss innovation in highly regulated environments like Healthcare. As usual, we’d appreciate your help making it to 3,000+ followers, by sharing it or subscribing:

Thank you and have a good read!

---

Jeremy Wight, from B2B SaaS to Healthcare

Jeremy Wight is one of Plato’s oldest mentors. He’s been around since even before we were called Plato, and still loves sharing his insights with mentees (he’s in the 100+ calls club!). Besides mentoring, his other passions are creating incredible and useful products, and building highly functioning teams. In his 15 years of experience, he’s held product and leadership roles in many companies, including DOM360, Invision App, and his own company, Base. Now the VP of Engineering at CareMessage, he supports the engineering organization to provide technology to improve health access for lower socioeconomic background populations, taking care of culture, budget, management, compliance, AI/ML, recruiting and hiring, data org, integration, and so much more!

You can follow Jeremy Wight on LinkedIn.

---

How to innovate in a highly regulated environment

Working in a regulated industry brings a unique set of challenges that can be intimidating, but innovation is still possible in these circumstances. And even if you think this doesn’t apply to you, I’ll let you in on a little secret: If you’re working in tech, you’re already working in a regulated industry… you just might not realize it! 

I’m Jeremy Wight, the VP of Engineering at CareMessage, where I’ve been overseeing engineering since January 2022. While I’ve been a product and engineering leader for the past 15 years at B2B SaaS companies like Base and InVision, this is my first foray into healthcare.

I’m excited to share how we innovate in a highly regulated environment and my goal is to inspire you to consider doing the same.

---

Getting to know CareMessage and its challenges

CareMessage is the largest patient engagement platform for underserved populations in the United States. We envision a world where everyone, regardless of income or background, achieves equitable health outcomes. Our customers are predominantly federally qualified health centers, free and charitable clinics, and safety-net organizations. The patients of the health centers we work with tend to be the lowest-served individuals in the US. They’re often living well below the poverty level and underinsured or uninsured.

A few fast facts about CareMessage:

• We were launched in 2013.

• We’re a YC-backed company.

• We’re a non-profit tech org. 

• We have about 50 people total, ~20 in engineering.

• We are a product-led organization. 

So what exactly does CareMessage do? We offer a comprehensive patient engagement platform, leveraging voice and SMS-based messaging (short messaging services, also known as text messaging) for our customers to engage with their patient populations. 

Broadband internet access is not universal in the US. Around 15% of US adults have a smartphone but don’t have at-home broadband internet service, and there are wide discrepancies in the percentage of people who have broadband access, especially based on age and geography. While the vast majority of people in the US might be able to get their health information via smartphone, this is not the case for the patients that our customers work with, which is why we leverage SMS. It’s the most broadly accessible technology for our patient populations.

Meet one of our partner organizations, NC MedAssist

To help illustrate the types of work our customers do and why it’s critically important to innovate in this space, I’d like to introduce one of our partner organizations, NC MedAssist.

NC MedAssist is North Carolina’s only free pharmacy. They offer free prescription medications to North Carolina residents who are uninsured and fall at or below 300% of the Federal Poverty Level. They have multiple programs to serve their community, including operating a mobile pharmacy, which goes out to rural communities to deliver life-saving medication to treat diseases like diabetes and hypertension. 

Prior to working with CareMessage, NC MedAssist was communicating with patients predominantly via postal mail. As you can imagine, this was slow and ineffective in situations when there were last-minute changes due to external factors such as inclement weather. 

With CareMessage, they can send real-time SMS messaging to their patients to give them up-to-date information, whether it’s a location or schedule change, enabling patients to continue to receive the life-saving medication they need. This is why technological innovation is critical in this type of industry. But that doesn’t mean it is easy.

---

Why it’s so hard to innovate in highly regulated industries

What exactly does it mean to work in a highly regulated industry? Here are a few of the considerations that restrict our work:

• We have to navigate regulatory mazes like HIPAA (the Health Insurance Portability and Accountability Act), TCPA (the Telephone Consumer Privacy Act), and state-based regulations like the CCPA (the California Consumer Privacy Act). These regulations place requirements around things like messaging consent, data segregation, audit trails, and more, which adds complexity and technical burden to the work. 

• The lack of interoperability leads to a closed ecosystem with long integration timelines.

• The BAA (Business Associates Agreement) limits the vendors we can work with and often means we can only work with more established and expensive options since newer startups don’t tend to meet the requirements. 

The reality is: We all have to deal with these regulations to some extent. For example, if you have customers in California, you’ll need to follow the CCPA regulations, regardless of your industry. 

However, as you can see from what I’ve outlined above, there are many more considerations when you’re working in a highly regulated industry. Many of these are things that typical startups would not prioritize since they’re not fundamentally value-adding activities. Still, they are critical for us to avoid huge fines, network access removal, and loss of trust.

---

3 strategies for innovating in highly regulated industries

Trying to innovate in this type of environment can sometimes feel like trying to run a race in the mud. Every step is a slog.

But some strategies can help you to move faster. And more startup leaders must get into highly regulated spaces because some of the world’s biggest challenges exist in these places. 

Here are three strategies that have helped us innovate at CareMessage despite the challenges: 

• Put more “R” into the R&D process 

• Focus on fundamentals

• Break through barriers with partners

Strategy #1: Put more “R” into the R&D process

All of the complexity I described earlier means you’re going to move slower and have a lot more requirements to deliver on. As a result, you need to make sure that the bets that you’re going to place are as well vetted as possible to increase your confidence that they’re going to produce their intended value.

To achieve this, product teams need to go through the rigor of research (the “R” from R&D), not merely going from idea to development. Here’s how we approach this at CareMessage.

The before state: What R&D looked like when I joined CareMessage

When I joined, CareMessage had made the switch from Scrum to more of a Kanban workflow, and the culture was such that engineers had single-point accountability for different projects. The issue was that estimations for both projects and tickets were consistently missed, which led to a lack of trust within the team. The trust issue was dealt with partly by working with the engineers to be more explicit about expectations and trade-offs, as well as clarifying accountability. 

Additionally, a couple of engineers were exited due to consistently not being able to meet expectations. This had been an ongoing issue and once this took place, the team realized that I would hold people accountable. This made those who remained excited and more willing to trust me as the leader. They saw that my goal was to help everyone get better while releasing tight control that had been established as a way to keep the team “safe” from poorly written code, missed deadlines, and more. 

Following this, it was important to me to get everyone working better as a team versus merely individuals and that was in part what led to the movement to use the Shape Up framework (outlined by Basecamp product leader Ryan Singer, this is an approach to product development that works in six-week cycles).

Deciding to introduce the Shape Up framework at CareMessage

There were a few keys to introducing the Shape Up framework at CareMessage:

The time frame felt right

One of the values of sprints is to create specific timelines to force trade-offs, but one drawback of sprints is that the typical sprint length of two weeks is often not enough time to complete a larger feature. Yes, you can break up larger features into smaller sprints, but ultimately the bigger that gets, the less likely it is to be accurate. 

I feel like six weeks (the length that’s recommended by Shape Up and what we decided on at CareMessage) is enough time to develop a meaningful feature while still being a short enough timeline to keep other priorities from knocking it down. Fundamentally, it made sense. 

I’d heard positive things from other engineering leaders

I also have CTO/VPE/Head of Eng colleagues at other startups who have used the Shape Up framework and shared their positive feedback with me. 

We framed it as an experiment rather than a permanent change

I like to use the phrase with my organizations that we’re going to “try this,” rather than state “This is what we are going to do.” The reality is that in startups, processes will change, and start by trying something and seeing how it goes makes it easier for people to receive the change and easier when at some point in the future we feel like we need to adjust that process.  

So I decided that we’d give the Shape Up framework a try for three to six months and see how it went. If it didn’t feel like it was working for us, we could adjust. 

It was a joint decision between product and engineering

Fortunately, my VP of Product also felt like we needed a shift with how PMs were thinking about and developing their Product Requirements Documents (PRDs), so she was also aligned with wanting to make a change. This was huge because I already had her support, and she ultimately made the suggestion to move to a Shape Up-ish process, so there was no pushback there. 

I’ll also add that I had already established trust and credibility with the department by showing them that I would help us deliver better. Because they had not been consistently delivering across the team previously, and because I had established that initial credibility, it made people comfortable with trying a new process. 

We created documentation about what the process would look like, decided on our time frames—six weeks on, two weeks off—established the boundaries of what each phase was for, and then began moving forward. From decision to implementation, it only took us about three or four weeks. 

I will note that our Infrastructure/SRE team has not moved into this process due to the type of work they do being either sustainment or very long-term projects, so we have not quite cracked the code on getting that team to work fully in this model.

How product development works at CareMessage today

The R&D process at CareMessage—we make sure to place a lot of emphasis on the research phase.

These are the phases of our current PRD process: 

1. Problem definition, which is owned by product. We have a time where it’s expected that they’re doing the research, and understanding the problem, and there’s a multi-person review that includes engineering that takes place in that PRD before it gets pushed to the next phase. 

2. Solution definition, which is where it’s generally taken over by a product designer.

3. Technical Breakdown, which is where engineering defines the solution and breaks down the work into key milestones to feel confident we can deliver within the build cycle, or recommends we break it into multiple PRDs across cycles.

4. During the cooldown period, we figure out resourcing and engineers work with design and product to refine the plan, make bets, and decide what we’re going to work on.

An engineer, whether a specified lead or someone else, will be tagged in the PRD during Phase 1 to be aware and provide directional input before it gets too far down the pipeline. Additionally in Phase 2, the designer may look for early feedback, and there will be a level of review which includes engineering. Phase 3 is the official handoff to engineering, but as in other phases, there is still iterative back and forth.

Example: Expanded language support

Here’s one example of how we went through the R&D process recently. We released a large initiative at the end of last year following roughly three cycles of work across multiple teams. 

The patients that our health centers serve often speak many different languages. Those who don’t speak English or Spanish (our primary languages supported) are at risk for even greater difficulty accessing healthcare, so we endeavored to make all of our messaging features support 60+ languages. 

Our research and testing found that just inserting Google Translate was not sufficient to effectively communicate, especially in some of the very niche languages our patients speak, like Haitian Creole. 

We leveraged this process to incrementally develop and release components of languages across different parts of the platform and released different parts in phases, culminating in a large release announcement late last year. 

This process gave us good predictability of when each team and feature would be completed, while also giving those teams a level of flexibility that they weren’t committing their full roadmap to this one thing. 

The benefits of our Shape Up-ish approach

Our shift to the six-week cycles and the Shape Up-ish approach ensures that things we’re doing are pretty well understood and we have a high degree of confidence that they’re going to be valuable. 

We’ve also established a compliance work group. We include product and engineering in weekly compliance syncs where they can ask questions and we can give feedback. That means we have fewer things that ultimately get to the end and get held up at shipping because we forgot opt-out, auditability, or any of the other requirements we need to be able to deliver. 

Strategy #2: Focus on fundamentals 

The second strategy is focusing on the fundamentals. I call it “going slow so you can go fast.” If you’re familiar with American football, this concept is referred to as “blocking and tackling.” 

In engineering, these fundamental building blocks include: 

• Code coverage 

• Test-driven development (TDD) 

• Tech debt management 

• Continuous Integration (CI) thresholds

• Fix rotations

This might sound like it’s super basic fundamentals, but I’ll tell you I’ve been in plenty of places where we did not handle these things well.

Let’s take a closer look at each of the things I mentioned above.

Code coverage 

When I joined, I realized we had 99% code coverage over all our production repositories. My goal was to make us go faster without screwing it up. 

Test-driven development (TDD)

This is difficult if you don’t have product/market fit and you’re throwing things at the wall, but if you’re able to establish good practices like the 80/20 rule and do different types of tests, whether they’re unit tests, functional tests, or end-to-end tests, having really good fundamental practices and going slower in the development phase ultimately is why we’re able to exchange 6 to 7 million messages a month with an engineering staff of 20. 

Tech debt management

We don’t have tons of frequent alerts firing. We don’t have tons of incidents. And when we have noisy alerts, we have a strategy for improving and paying down tech debt. That’s how we use the cooldown cycle that I mentioned earlier. 

We groom our tech debt backlogs two weeks before the end of a cycle so we can prioritize and know what we plan to work on. We make sure it’s high value. We understand it and we have engineers roughly assigned to that going into that two-week cooldown so we know exactly what we’re going to accomplish. 

We have separate tech debt reviews/grooming sessions with the front-end and back-end focused engineers and they review, discuss, and prioritize. I initially led these directly to better grow my understanding of what was being brought up, what they considered tech debt, and why, and could share how I wanted them to think about it, including consistently pressing applying the 80/20 rule. 

Additionally, if there are things that we see that could become a scaling problem in the future, we will discuss and talk through thresholds that would trigger us to need to work on them, to prioritize more pressing things without forgetting about those indefinitely. It’s not a perfect system, but it works. 

Since the team has become more familiar with how I want them to think about it, I now empower my Staff Engineers and EMs to lead these and I review the notes of their prioritization async so I can continue to stay apprised and redirect as necessary.

There are lots of different strategies I’ve applied at different companies, but this one works well for us. It’s one of the things Shape Up has done well for us, especially given that there are engineers on my team who have had things on their tech debt backlog for two years and sometimes they get discouraged. I encourage them to look at everything we have accomplished and then review and reevaluate—is that thing as important as you thought it was? 

CI thresholds

CI thresholds helped us speed up. When I joined, the CI process was slow enough that they were moving on to the next ticket while waiting for builds to move to our test environment or production—that’s not a good practice. I set a CI threshold of 20 minutes. If ever it takes more than 20 minutes, we focus on it, whether that means putting more resources into the system or improving the mechanisms of our build process. Right now we’re at around 11 minutes for our deploy process. 

Fix rotations

Finally, the fix rotation has been incredibly effective. One of the things I’ve seen cause problems in other places is when you’ve got long-term projects or commitments that you’re trying to work on, these high-priority bugs come up that pull people off of the project they’re working on and can cause projects to slip or people to work crazy hours to get it done. 

To prevent this, we apply one engineer—which is about one-tenth of our engineering development budget—to a fixed rotation. During the dev cycle, one person deals with high-priority bugs that are assigned by the product or any alerts that come up after they’ve been triaged by the on-call engineer.

If you’re interested in doing something similar and wondering how many engineers to allocate to the fix rotation, I’d say the amount is highly dependent on the maturity of the product area, criticality, and more. We practice TDD and target 100% test coverage, we have fairly mature features, etc., so in calculating this I looked at our inflow of high-priority bugs, our prioritized list of tech debt, and the features we had on the roadmap and started with this and tested it. After a couple of cycles we felt like we were able to effectively respond to pressing needs, improve underlying issues triggering alerts (thus improving the ongoing inflow), and make some progress on tech debt during the cycle by this individual, so it worked for us. 

I think you just need to set clear expectations with your product peers and other stakeholders and test. Since we’ve implemented this process, we’ve continued to scale our teams and have moved from one pool of product engineers collaborating on PRDs to product pillar teams. In this move to product pillar teams, I have empowered the EMs over those teams to determine the allocation based on their product areas’ scope of needs, so I think you just continually need to evaluate and adjust.

Strategy #3: Find ways to break through barriers with partners

In a highly regulated industry where you’re limited in the partners you can work with, you will often encounter barriers like partners who move much more slowly than you’d like or don’t respond within what feels like a reasonable amount of time. Comparing my experience leading integrations at companies like InVision vs. at CareMessage is like night and day. 

With many of the electronic medical records (EMR) companies, there’s very limited interoperability. They have some open access, but it’s often not enough to accomplish the goals we have, so we have to work to get access to closed API marketplaces. They’re slow and often don’t have good documentation. Here are a few ways I’ve learned to overcome these difficulties:

• Leverage your executives and board

• Get people’s phone numbers and call them

• Schedule regularly recurring meetings

Leverage your executives and board

In some cases, it’s best to leverage your executives and your board to apply pressure if needed. I’ve witnessed firsthand that getting one of our board members to reach out to a board member at a partner company managed to get traction after we’d been stalled for many months. It might not come naturally to reach out to your executives or board members to ask for this type of favor, but remember they should be your allies and people who can help you, not just someone you report to.

Get people’s phone numbers and call them

Similarly, while this was not something I generally had to do when working with more typical SaaS partners, calling people on the phone can be an effective tactic in this setting. After weeks of non-responsiveness to emails, I called a partnerships manager, spoke with them directly, and got a response from their team within a few hours.

Schedule regularly recurring meetings

Another tactic that can be effective is to get consistent meetings on the calendar. You may not always need the time, but this can be a better approach than trying to schedule time on an as-needed basis and struggling to get any response promptly. You can decide on the cadence that works best for you, but I’d recommend not spacing these meetings out more than six weeks. If you go too long, it’s hard to maintain continuity in the relationship, and the inevitable cancellations and reschedules can set you back even more.

What you cover in these meetings depends on the nature of the work, but in general, they’re an opportunity to connect on active projects and share about recent changes to our platform. You can also ask for insights into their platform and roadmap and areas they are exploring that you might want to be thinking about going forward. 

Final thoughts and key takeaways

I’d like to end by saying that healthcare was not initially on my radar, just as it may not be on yours. But when I discovered CareMessage and what they were doing and learned more about the mission AND the amazing tech they had built, I felt like it was a rare opportunity to make a difference while also getting to build incredible products and teams. 

Now that I know, I would recommend it to others, despite some of the challenges I’ve mentioned here. Yes, sometimes it can feel like a slog through the mud, but the only way that change happens is for people to act. Be the change you want to see. There’s a tremendous opportunity to innovate and make a positive change in this space.

---

And that’s a wrap! Thanks to Jeremy for his insights.

Cheers,

Quang & the team at Plato