Omada Health is hiring a senior engineer to scale a team tackling chronic preventable disease
This portrait was produced by Job Portraits, which highlights job openings at Bay Area startups. Omada Health commissioned this portrait to highlight its senior software engineer role. For the interview below, Job Portraits spoke with Omada Health Cofounder and President Adrian James, VP of Engineering Austin Putman, and software engineers Matt Hassfurder and Sarah Branon.
What is Omada and how are you making the world a better place?
Adrian: In 2011, preventable chronic disease, like diabetes and heart disease, surpassed infectious disease as the leading cause of death in the world. To help people avoid those diseases, we’re creating a new class of products that we refer to as digital therapeutics. These diseases are best addressed through lifestyle change — but change is hard. So the challenge is: How do we inspire change that sticks?
To do that we’re building a sophisticated system that combines personal, full-time coaching, social support, smart tech, and behavioral psychology. And to have the biggest possible impact, we’re working to get it adopted into our clunky, outdated healthcare system.
Today, we offer a platform for people at risk for type 2 diabetes, high blood pressure, high cholesterol, and metabolic syndrome. Participants are guided through an immersive, 16-week program that addresses the physiological, social, and psychological components of their condition. Basically we’re helping them make a series of small but high-impact changes to daily habits. When they do that, they not only end up losing weight and lowering their risk for disease, they also save their health plan or employer a lot of money.
If someone joined Omada tomorrow, what kind of growth would they stand to be part of?
In the future we want to be the Genentech of digital health. We’re able to build digital therapeutics that are more effective than any competing pill or procedure. So it makes sense for Omada to develop new programs to help people avoid preventable diseases beyond diabetes. And even as I say that, there are 80 million people in the U.S. with pre-diabetes, so we still have a lot of work to do there.
Tell us about the Senior Software Engineer role and why you’re hiring for it now?
Austin: Right now in San Francisco everybody wants to hire senior people to build their products. So do we. But we’re also looking for senior people who understand that training junior people is part of building great products. Someone who has been down this road enough to realize that the best way to be a “10X programmer” is to help 10 other people be twice as effective.
We also want to create an environment where there is not judgement about getting stuff wrong. Being senior doesn’t mean you don’t make mistakes, it just means you’ve already made a lot of mistakes so you don’t make those particular ones too much.
Are there specific problems that this person is going to be tackling when they first come in?
Austin: We’re at a threshold where we have a large Rails app that needs to be broken up. That’s a common pattern: people get started rapidly in Rails, and then two or three years go by and you keep tacking on complexity to the thing. At some point you just end up with a big ball of mud. Now we would like to re-distribute this mud into a toy town. We need someone who can help us figure out how to break it into coherent pieces so we can scale.
We’ve heard that most programming here is paired. Tell us about that.
Austin: There’s no better way to get a team to really feel like a team. There are syndromes that come up when you have a lot of “hero coders”: people who are used to going off and doing everything between the hours of 10:00PM and 2:00AM. They come in the next morning and everyone is like, “Wow, great job. I have no idea what you just did.”
I don’t want Omada to be that way. We’re all responsible for this code base together. We know we’re going to make mistakes — in fact, we are intimately familiar with each other’s mistakes, and that’s okay. That’s part of how we do business here.
When you’re pairing and you make a mistake, you know there were two people sitting there and both of them thought it was okay, so at least it wasn’t a stupid mistake. That means the chance of making a really tragic mistake, one that’s going to take three or four weeks to unwind, is much lower.
Pairing also helps me evaluate people as a manager, which is actually really challenging. There is no good quantitative metric of performance for coding. The most useful one is reputation, but that can be susceptible to favoritism. With pairing I can just ask someone’s peers, “What do you think about this person’s code?” And every single person has an opinion because they have all coded together.
Matt and Sarah, had you worked somewhere before where you did pair programming?
Matt: I’d paired two or three times before coming here. I’d heard a lot of good things about it, and it’s since completely won me over. I actually get sad if I don’t get to pair as much with certain people. I’m like, “Oh, I want to spend some more time pairing with this person and hearing their ideas.”
Sarah: Pairing also helps in maintaining a shared language. We all work in Rails, Javascript, and SQL, but if you don’t have consistent habits and types of communication, the risk is that it all feels patched together.
Matt: Any time there are differences in how two people would code something, it prompts a conversation. Without pairing, the barrier to that conversation is very high; you have to send an email or call a meeting. When you’re already sitting beside somebody, it’s very easy to simply say, “What do you think: should I do this or that?”
Sarah: Another benefit of pairing is that you don’t have to own something from start to finish. Also, since you have to pass it along, you have to make it easy for anyone else to understand.
Matt: Yeah, and because you’re switching off there’s not one single person who has to feel responsible for everything. Anybody can jump in and help out, and give advice on whatever is going on. That’s really nice.
What is it like working on this team day-to-day?
Sarah: We start the day with a whole-team standup around 10am, and then individual team check-ins where we get a bit more into the nitty-gritty.
Matt: For lunch we like to get out of the office and then usually come back to eat and talk. Around two o’clock a gong sounds, and the whole office takes a break away from our computers to move around. Then the engineering team usually goes on a 4 o’clock block-walk just to get out of the office.
Most people leave the office before 6pm. Even the executive team makes sure to head out on time, just so everybody else is given the implicit license to do the same. That’s one of the things I really like about working here: everybody recognizes that people need to be in a good place physically and emotionally to do their best work.
“We’re given a lot of freedom to take time to take care of ourselves.” — Matt
That makes sense considering the goals of the company. Do you use the tools that you create, too?
Matt: When anyone joins the company, they go through the program first-hand so they understand the perspective of our users. I’ve actually gotten a lot out of the program.
Sarah: I like that the company is focused on health. And it’s not just, “Oh, we have a basket of apples in the kitchen.” It goes really deep. Including encouraging healthy relationships between people.
Austin: One example of that is that, every week, four people from different areas of the company go to lunch together. The idea is that everyone should be getting to know each other so that it’s easy to be like, “I have a billing question. Let’s go talk to the billing person that I now know.” Strong relationships facilitate more direct, efficient communication throughout the organization.
Sarah, was there something that sealed the deal for you about working at Omada?
Sarah: Actually, it was the interview process. I was like, “Are they going to make me dance around in circles and do hijinks on white boards?” But the interview process is that you just sit down and pair with people. It was not at all like I expected.
Matt: Yeah, a lot of times in interviews you’re asked these puzzle questions that aren’t typical of what you are going to be doing on a day-to-day basis. I’ve even been asked to write code over the phone. In contrast, we invite people to spend the day doing what we do. That gives us a really good impression of how they’re going to fit in with the team, and how they write code. Equally important, it allows them time to evaluate us.
Matt, you said you did a lot of consulting before. What made you decide to join Omada full-time?
Matt: I think part of it was wanting to have an interaction with a company that was more long term. Being an early employee meant I got to see a lot of growth, which was exciting. Two years ago I was employee number 14 — today we’re close to one hundred people, with lots more growth on the horizon.
At the same time I’ve been really amazed at how well we’ve held onto the culture of those early days. When we began growing very quickly, we came together to address it. We realized our goal had to do less with changing as we grew, and more to do with keeping important things the same.
How about you, Austin. Why did you say yes to working here?
Austin: Oh man. I did three interviews with different companies on the same day. Omada was the first one and the other ones were just so awful in comparison. Honestly, our founders are terrific: they’re fun, they’re interesting, and they’ve got the right background to change the health care system. They care about making a difference — and their hearts are really in the right place. That’s what got me to sign on. This is the real deal.
Interested in joining the Omada Health team? Apply for positions here, or contact Jes Jarvis at jessica.jarvis@omadahealth.com.
