Sanjeev Banerji is Head of Engineering and IT at Waymark. He has a PhD in computer engineering and more than 20 years’ engineering and IT experience, including prior leadership roles at Zus Health, BitSight, Delphi, and Endeca.
In our conversation, Sanjeev talked about aspects of technology that are more prevalent in healthcare and shared an initiative that helped him realize the importance of relationship building. He also reflected on early leadership challenges and strategies he’s found useful for mentoring.
Waymark’s mission is about expanding access to healthcare — for Medicaid patients in particular, which is a group that is chronically underserved and kind of undervalued by society. Our approach incorporates having community health workers, referred to as CHWs, working directly with patients.
We also believe there’s a large swath of patients for whom we can increase healthcare access with less “high-touch” attention. These patients may not need a CHW on a day-to-day or weekly basis.
Our premise is that we can actually improve access and healthcare outcomes — those two go hand in hand — for a large group of Medicaid patients with automated outreach and follow-up techniques coupled with the smarts of the proprietary AI language models that we’re building.
Also, to be clear, Waymark has been an AI company from the start; that was part of its founding premise several years ago, so we’re not new to the party. I think it’s really interesting because it’s new ground. It has actually not been tried before. Will it work? Who knows? That’s kind of the excitement of it.
In my opinion, the biggest one is that data in healthcare is messy. I had heard that everywhere, and I was pretty skeptical — I’ve been in software for a long time. But it really is true.
US healthcare is monolithic yet very fragmented, meaning there aren’t broadly adopted data standards or data interchange standards. There are some, and they’re growing in popularity, but they’re really quite nascent.
As an example, at an individual level, you may get a CSV file from an insurer’s health system that contains claims information for medicine or hospital visits. You might expect to find all characters in the name field, but that may not be the case. This happens frequently. It’s really not the exception, it’s almost the rule.
At a higher level, you may receive and need to reconcile “packages” of information (such as a set of data files) from a health system and an insurer. Those packets of information may have lots of inconsistencies. You may have a list of patients and a list of doctors that are supposed to have some kind of mapping, but the mapping is actually quite incomplete. You’re always chasing things down.
Another piece I see more in healthcare is that, because there’s such great empathy around users and patients, engineers, designers, and product people work together more closely. This results in engineers being able to see through the eyes of product and design and better understand how the technical work impacts the patient. That’s been a wonderful revelation for me, particularly at Waymark.
It is, and because of that, we work with counsel much more in healthcare than in many other verticals. That’s been a meaningful difference for me. I’ve had counsel before for employment agreements, but here we’re signing BAAs (HIPAA Business Associate Agreements), things of that nature. So there is a legal piece that is more present as well.
I’ve found the legal aspect is not particularly onerous. As long as you adapt your processes, you don’t lose a ton of efficiency. At Waymark, if we know it may take counsel some time to turn something around, we try to have several other things ready to work on simultaneously. This helps sort of manage engineering frustration as well because we want to keep driving to finish things.
There’s also a lot of emphasis on security and compliance. HIPAA is just one example; there’s also SOC 2. So there’s a heightened awareness in the company around our responsibility as custodians of patient data. I think that aspect of healthcare is actually really good. It kind of reinforces our mission.
There was a project at Endeca, probably 15 years ago, that was formative for me in multiple dimensions. Endeca made a purpose-built database for ecommerce. At the time, the database had some functional and performance attributes that we weren’t fans of and our customers didn’t love, either.
Engineering was asked to take on the project of rebuilding the database internals so that the company could go after additional customers, handle more and more data in a really graceful way, and ultimately increase market share.
Two teams took on this project, and I, as engineering manager, led one of those teams. It was deep technical work that was intellectually hard and had lots of unknowns. That type of work is hard to do in a predictable manner, but the business needed predictability around this.
We spent a lot of upfront time looking at different approaches and brainstorming back and forth. Then we laid out a plan and stuck to it, although we didn’t know if it was actually going to work. Ultimately, we got it done in the timeframe we’d committed to. There were ups and downs along the way, but both teams worked really closely together and felt really galvanized by the mission.
This was the first time as an engineering manager that I led what I would call a hard project. Rebuilding something is much more complicated than just adding a new feature.
This was my favorite initiative because of the combination of technical work, achieving the goal, and really the team dynamic. The friendships and relationships that formed during that time are still strong to this day. I think that going after an ambitious goal and then reaching it with relationships not just preserved, but actually stronger, is pretty wonderful.
Well, I didn’t fully know what I was getting into, but I had enough self-awareness to realize I would be in over my head. The biggest challenges I encountered were nontechnical. First, there were unset expectations. When you’re head of something, you own the entirety of the outcome, soup to nuts, with no excuses. That was new for me.
Also, I now had some peers who were nontechnical but were still very interested in what engineering was doing, cared about the timeframes, and in some cases had deals riding on engineering’s outcomes. Those were very new dynamics for me.
So I did a few things. First, I worked to build a very close relationship with my manager, who was a founder. With his help, I learned to put myself in the shoes of others: his, the sales team, the CEO, or the board.
For example, he would prompt me to come up with answers in advance to questions that the board would probably have about different engineering initiatives, like having an offshore team. It was not on my radar at the time that they would care about that. Stakeholder management is huge, and I honestly think it took a few years to really be able to really imagine myself in the shoes of others.
He also taught me the skill of seeing around the corner. At the same time, I learned to invest in the strengths that I had. One of those is engineering leadership. To further invest in that I wanted to make sure that engineering operated in a sustainable way. In other words, it should run well, whether I’m there or not. That’s really important to me.
Lastly, I leaned on people outside the company quite a bit — peers who are either veteran VPs or CTOs and also industry people I struck up friendships with. I leaned on this group for support. Sometimes just for therapy, other times for specific problem solving.
Engineering must be able to deliver bad news. People are expecting many things, and we’re trying to be realistic, almost fact-based. Saying “no” or “not now” in a way that doesn’t deflate people is an art form. It’s one I’m still working on, but I think I’m getting better at it.
I think the heart of it is showing interest in people beyond the alignment with your own interest. For me, that’s showing that I care about them beyond our current working relationship. I try to continually nudge members of my team to imagine what they want to do a little further out.
With people who are a little more seasoned, this can be pretty quick. They may already know what they’d like to do. For people who are younger in their careers, there are often lots of unknowns.
I try to show how what they’re working on today is not only helping company goals, but also building skills and their resume, and that both matter. When we look at progress, I also like to show what might be ahead for them and, ideally, how that’s tied to goals for the team and the company. So the goals aren’t contrived or made up; they’re durable things. Then I can show how those goals can advance them.
Storytelling can also be useful here. I will sometimes talk about success or failures and what I’ve learned from them. I also try to highlight skills that the person may not be focused on. For example, I’ve noticed that engineers often devalue nontechnical skills.
I try to highlight that there’s an immense amount of problem solving outside of code and architecture, and it may be more complicated because it involves dealing with humans. By this, I don’t just mean managing people, I mean working cross-functionally.
Let’s say people have different incentives and aren’t aligned. Those are pretty neat problems, and they are also hard problems. If I’m nudging someone to take on a project like this, I might say, “Maybe I can ride along with you. You’ll still own the engineering piece of this project, but I can kind of ride along and guide you on the other pieces of it.”
Lastly, having a career ladder is pretty foundational. It demonstrates that there’s institutional support for a career path, and that it’s a permanent thing. Like, “You’re at level two. Level three looks like this. Here are the projects and work you’ll need to do to get there and here’s how long you have to do it.”
I’ve found that it varies quite a bit based on the company stage and the company dynamic. Waymark is a high-empathy, mission-driven company that really values collaboration and teamwork.
I’d say the engineering team here works much more closely with product and design than any other place I’ve been. That’s partly because Waymark is still really small, but it’s also due to its working style. Empathy is part of the DNA of the company.
In the interview process, we prioritize finding people who are good collaborators. We need team members who are self-directed and self-driven, but also know how to get help from coworkers, leverage their knowledge, and use them as a sounding board. We also look for people who genuinely care about our mission. That’s kind of nonnegotiable for us.
Would you be interested in joining LogRocket's developer community?
Join LogRocket’s Content Advisory Board. You’ll help inform the type of content we create and get access to exclusive meetups, social accreditation, and swag.
Sign up now
Learn how to implement one-way and two-way data binding in Vue.js, using v-model and advanced techniques like defineModel for better apps.
Compare Prisma and Drizzle ORMs to learn their differences, strengths, and weaknesses for data access and migrations.
It’s easy for devs to default to JavaScript to fix every problem. Let’s use the RoLP to find simpler alternatives with HTML and CSS.
Learn how to manage memory leaks in Rust, avoid unsafe behavior, and use tools like weak references to ensure efficient programs.
Learn more →
