12 Tactical Healthcare Ops Tips

Sandy Varatharajah and Danielle share 12 tactical gifts (aka 12 gifs of Ops Christmas) they’ve learned through growing and scaling operations teams at digital health start-ups.
Hosted By:
Danielle Poreh
Sandy Varatharajah Malkan

Show Notes

This episode is sponsored by Out of Pocket, because no one is prouder of us than us: https://www.outofpocket.health/

You should also check out our courses, including ones taught by yours truly (How to Build A Healthcare Call Center and Healthcare 101): https://www.outofpocket.health/course-library



Danielle Poreh (LinkedIn: https://www.linkedin.com/in/danielleporeh/ twitter: https://twitter.com/danielleporeh )



Sandy Varatharajah (twitter: https://twitter.com/sanvrajah?lang=en)



(00:00) Introduction to the 12 Gifts of Ops Christmas

(01:30) Gift #1: Think like a product person

(02:49) Gift #2: Run a drip campaign

(04:12) Gift #3: Give people sight into the problems

(06:01) Gift #4: Face your hidden factories, make swim lane maps

(08:50) Gift #5: Start an offboarding doc

(10:42) Gift #6: Prove something can be done before hiring a team

(12:58) Gift #7: When in doubt, fly out

(15:20) Gift #8: Build an ops roadmap

(18:05) Gift #9: Before effort comes focus

(22:43) Gift #10: Upgrade your software to AI features

(26:33) Gift #11: Contracts create choke points

(30:53) Gift #12: The power of schedule sending

Podcast Transcript

[00:00:00] Episode Intro

[00:00:05] Danielle: Today's episode is a little different. It's our, it's our holiday edition. We thought it would be fun to, to take a spin on the 12 gifts of Christmas and do a 12 gifts of Ops Christmas. It is designed to be highly tactical, like everything else we're trying to do on this pod. And what we did was brought on an amazing operator alongside me and Nikhil sitting on the sidelines.

This, this was too deep into the ops for him, As a little caveat, mine tend to be a bit more early stage. Uh, so this is like zero to one building of your Ops, things I don't ever want you to mess up on and things I learned the hard way.

Sandy, uh, is coming in a little bit later stage. So she's going to share a little bit. before we jump in.

[00:00:49] Sandy: Yeah. So, hey everyone. My name is Sandy Varatharajah. I work at Firsthand and I lead our Activation Business Unit, which is focused on the first 90 days of engagement with our very low income, seriously mentally ill [00:01:00] Medicaid population.

Um, as Danielle mentioned, I focus more on like the 1 to 100 phase. So, once you have proof of concept of something, how do you go build the thing? Whether that's product, teams, etc. So, excited to share some nuggets and battle scars with y'all.

[00:01:16] Danielle: So basically between us, Sandy, we've covered like, uh, you just started a company to like IPO.

Yes. Yeah. We've conquered healthcare.

We've conquered healthcare in 30 minutes. Yeah. All right.

Sandy, do you feel like starting us off?

[00:01:32] Sandy: Sure. Hell yeah. Actually, can you start?

[00:01:36] Danielle: Gift number one for me is to not think like an Ops person when you're in an Ops role and rather to think like a product person when you're in an Ops role. When you're a product person and you look at things like product, you think about how they scale. You look at how tech can be a solution. You look at user needs and basically the entire product development lifecycle is just a shoe in for solving the same [00:02:00] kinds of ops challenges.

In fact, I'd argue that most of the challenges that you're trying to solve right now are not ops challenges, but they are. product challenges. And so leveling up your ability to answer those questions is a really great way for you to kind of solve bigger business problems

that's my first one.

[00:02:16] Sandy: I love this one. I feel like we could end the episode right there because so many of my gifts are related to this topic. I feel like I've grown so much as an operator because I've worked with talented product managers.

So like the rituals, the muscle, just even like your mindset of approaching problems is very different. And. Um, it's at least one structured way to learn about how to think about a problem. Uh, so I, I love this piece of advice.

[00:02:40] Danielle: So we're done, right? Yeah.

[00:02:43] Sandy: Well, gift number two, run a drip campaign to incept ideas.

It helps you warm up to big decisions.

Everybody who works with you is running at 110%. They're really far from context on what you're thinking about. But you really need their buy in to get stuff done. So when I [00:03:00] say like big decisions, I mean centralizing a team or investing like 1, 000, 000 to hire up a team, um, investing an engineer's chunk of time for an entire quarter just to build out this one.

You know, product, whatever it is, and I think the most strategic way to get that done is not like a really crisply written document once a quarter that you present to your executive team. It is that slow drip campaign that happens over time, which I think is highly strategic. So what that looks like for me, I write a monthly is report.

I write regular slack updates. We do kind of standups on our ops teams just to read out what's happening. We do. Okay. Our readouts with our executives. That might sound really meeting heavy, but the point is that you're building this regular writing and thinking muscle of what you're learning and you're communicating that out to the rest of the business.

The other thing I think that helps with is something I like to call taking the covert to the overt. So I think people might be scared to share what they're learning, either because it's not going as [00:04:00] well as it needs to be. Or they're worried about a reaction. And I think this is the best way to just put all the facts out there and give people a surface to react, because if they are not reacting with the slow drip over time, they're definitely going to react in that big arena moment when you're like walking into the room and pitching an idea to them.

So drip campaign, that's my gift. Number two.

[00:04:19] Danielle: I can see drip campaigns being really effective at kind of, uh, some, giving some perspective at what's coming ahead. So from like a solution standpoint, like, oh, next quarter, we're going to be, you know, we're thinking engineering time to be used on XYZ resource, like you said.

Um, but then when I heard you explaining it, it sounded a bit more like you're almost trying to prime people to the magnitude of the problem that you're trying to solve and getting more buy in around the problem being something requiring the business attention versus the solution being the right answer to it.

So I'm at, I just want to distinguish which one is it. And if folks listening, what would you suggest them to do with that?

[00:04:54] Sandy: Yeah, for me, at least at the pace we're running at, it's been about 70 percent the right [00:05:00] problem and 30%. What your solutions are. And obviously your solutions are going to change flavors over time.

Maybe at the start, it's going to be very people focused, brute forcing with people. And then it becomes infusing that into your product roadmap, but no one is going to listen to you if they don't even agree with the right problem.

[00:05:16] Danielle: I think I've got the best, uh, gift three to To piggyback off that one.

And it's actually maybe the seed towards building that muscle of like trying to explain context, trying to get people to understand problems the way that you're seeing them. And it comes from my fave book, the artist way, my girl, Julia Cameron, she has this lovely quote called sight is insight.

Sandy, your point of, like, giving insight into the problems, one of the best ways I've seen to do that is give people sight into the problems. So, rather than trying to extrapolate a really difficult interaction with a health advocate or whoever is your stakeholder, bring that person along with you, right?

Like, [00:06:00] let them see that problem firsthand. Maybe like I've suggested many times before, like get them on the phone with customers as well, right? Like folks in your organization need to see problems and experience problems for them to also get that same level of buy in to understand that they are problems.

So when you are finding yourself using a lot of words, one of the ways you can counter that is have them actually see it for themselves and live it first person.

[00:06:26] Sandy: I love this one Depot. I think this is especially important when a lot of fellow operators in health care belong to something I call the knowledge class and a lot of our frontline workers, especially in services business may not.

And I, I don't mean that demeaningly like our frontline workers are doing really heavy services work day in and day out. And We don't speak the same language often. We're not working under the same tooling. We don't use the same rituals and there is nothing that can replace lived experience full stop.

Like you cannot learn from afar in an ivory tower. So I really, really love this one. Gift number [00:07:00] four, face your hidden factories, make swim lane maps. This one is so process heavy. It like elicits this image of working underground in a basement, like nudging shapes around in PowerPoint. But for me, this is paid a lot of dividends this year.

So how often have you told your PM or whoever your counterpart is as an operator? You've said, I know exactly what's happening in this process, and turns out, you actually don't. Like, this has happened to me many times this year. Um, I think, especially when we're running so quickly at problems. We end up carrying a lot of, you know, extra baggage, extra processes, band aids.

It's that, you know, meme of lots of blocks being held up by a single op associate who knows everything that's going on. So, for me, it's been really helpful to sit down with product and map out our swimlane diagrams. And ideally, those diagrams are answering who is doing what and when for some complex workflow.

And it [00:08:00] outlines Tools and people as different swim lanes that can own or have something, uh, have some action taken. So, you know, one example from my year, we actually completely messed up one of our major data models that informed business reporting and a lot of other Ops workflows because we didn't map out this process in the right way in the first place, and so this led to a lot of building in features into our front end user experience in our platform that didn't make any sense, and it set us back by a few months in terms of reporting and a bunch of other things.

So. If I could rewind time, I would have just sat down for two hours and mapped everything out in a swim lane diagram. I don't know. Have you, have you tried doing this?

[00:08:44] Danielle: I think I, I don't know what a swim lane diagram is because I wasn't in management consulting. It reminds me of like MISI or like one of those other frameworks.

Could you, could you explain, like I'm five, what a swim lane diagram is?

[00:08:58] Sandy: So [00:09:00] very simply, it's a diagram that has a bunch of rows. And each row represents, in this case, a person or a tool that touches a process. And within each swim lane, you're listing out different steps that are taken. So for example, you might have a top lane that represents You're a customer service agent, a second lane that represents, you know, the CRM that they're working out of, the third lane represents a fax system that they also are sending materials out from.

And so you're just like constantly pinballing different processes around. And sometimes the most alarming thing about doing that is you realize how inefficient your process is because you're just like going like this zigzagging and that itself is really useful learning. I think we assume. In ops that things will just work out because we have a team that's like really dedicated to this knowledge, but sometimes doubles in the details Um, love this.

[00:09:54] Danielle: I have made a swim lane diagram. Did not know I did that. I made an Olympic size level of swim, [00:10:00] swim lane diagram. Let me tell you a few use cases that this is especially helpful. Number one, if you are gonna be transitioning out of your role, which happens a lot in early stage. A swim lane diagram is like the best.

You know, uh, tool to share with somebody as they're coming in, but even better is that if you co design with the person coming in so early on when we were hiring like a director level into our call center and they came in and they were like, what is going on here? We built that together and that was their onboarding process.

And later on, that was actually version controlled and locked. So any changes had to be reflected on this diagram. And then we would get like push notifications of changes made there. So nobody could touch it. There were like two people allowed to edit this diagram. And it was the source of truth for the entire member journey end to end.

Massively helpful. One of the ways I've seen to be, like, kind of a fun add on activity on top of it is, like, to use one [00:11:00] of those whiteboarding, uh, softwares or whatnot and, like, use emojis to identify areas of opportunity. So, I always, like, use, like, lightning rods. On an area that I think could be automated and you could kind of like dot vote that where like everybody gets like five lightning rods and throughout it they get to put like an area that they think should be automated and it's an interesting way to kind of, um, run product or ideas around like, uh, areas of opportunity on top of this, like one centralized, now I know swim lane diagram. Great.

Sandy I wonder what you were calling it before, but I do love the emoji ideas.

Danielle Member journey.

Sandy Uh... okay. I like that. But especially when there are so many internal sausage making processes, it may not even discreetly touch the member, right? I love the emoji idea. That's awesome.

Danielle So my gift number five is to start an offboarding doc. Um, I think this framing is a really, if Interesting and different framing towards trying to share information.

So Sandy, if you were leaving first hand tomorrow, you'd [00:12:00] have to make an offboarding doc, sad face. And if you were to think about building that offboarding doc, it would be much more in the context of somebody else has to come in here and literally do this job blind versus like, Oh yeah, I'm going to be here and I can shepherd you through this process.

Like, no, you're out of the equation and someone else has to come in. Um, I've heard someone do this for every single job that they come into, they start an off boarding doc on their first day.

[00:12:25] Sandy: Whoa, that, that's a lot. Hardcore. Yeah, that's dedication.

[00:12:30] Danielle: I love running docs, like that's definitely something of mine that is like forever going to be instilled in my DNA.

And I think if I ever did rejoin a company, I would make an offboarding doc, day one.

[00:12:42] Sandy: Yeah, I think the, well, first of all, I agree. I don't know about day one. That seems demeaning. Like you're trying to figure out, not demeaning, but intense. The goal, ultimately for all of us, we will all leave our companies at some point, whether that's after an exit or [00:13:00] it's right in the thick of shit.

And ultimately we want. At least for the sake of the patients that we serve for the company to far outlast us as individuals, as people that drive a lot of process and knowledge sharing. So I think it's important. I think when you say offboarding doc, what does that actually look like? Are you mapping out like the internal politics of the org?

Are you mapping out key decisions? Like what goes on an offboarding doc?

[00:13:27] Danielle: I think there's some just like. Uh, areas of obvious things where you didn't even realize you have so much ownership of. So for example, one of them for me was software ownership. I think I was responsible for like 30 pieces of software leaving the company.

And that was such an obvious and like silly bottleneck to be responsible for. So I think small things that when you're like literally are untethered from your org, like a software or like a software diagram where it's like. One, software, two, who owns it, [00:14:00] three, is it active, four, what's the business case?

You know, five, like payment structure, renewal, six, link to contract, done. Like you, you're going to have to make something like that because especially if you're first person, you're standing up like every function from the ground up, which includes a lot of just like the mechanical parts of standing it up.

And so codifying that would be like one easy place to start on an offboarding document. I think you're right. Like there is the point in time things of an offboarding doc that don't work like projects that are in flight right now, but there's more like just things that you're repeating every single day that the next person will have to do or yeah, like structural components to the way, you know, software is architected, um, even locations of documents is super, super helpful for yourself as well.

Um, how to guides on software, just like basically like one on one things that every employee or people walking into your role. Might benefit from knowing, um, that obviously can then be recycled into like the training documentation or whatever, as your [00:15:00] company keeps growing. But I agree, like continuity of care, uh, also extends towards the internal side of things.

Uh, so it is super important. I think just generally when you are designing documentation, thinking about if you were completely out of the equation, it's just a helpful way to think about somebody else coming in with fresh eyes, uh, versus you needing to shepherd them through that.

[00:15:21] Sandy: SO gift number six, prove something can be done before you hire a team around it. This has been huge for us this year at first hand, we're post series B, there's a lot of scaling from, you know, single thousands of individuals to many, many more order of magnitude.

It's really easy when you're in that hyperscale mode to jump from. This is inefficient, and I don't really know what we need to hiring somebody. Just fill the gap with hiring. It's a cheaper way to do things. It's a faster way to do things than like investing in product, frankly. But this is important because if you raise costs, you're raising overhead, you raise the burden of proof of [00:16:00] value.

So you better really understand your problems well before you're hiring around them, because you're going to have to demonstrate value from that hire on day one. So for me this year, we had a lot of big problems we were running at and. We were frankly creating roles that don't exist at other traditional healthcare companies.

So there was a lot of new green sky, blue sky mapping we had to do with just people and profiles and JDs. So we approached new roles and teams with the rigor of grooming a new tech initiative. So I would extend myself or an existing team member into like a new adjacent role for three months. And they'd probably be working at.

I don't want to say over 100%, but they'd be at full capacity exploring a totally different problem just so we could get eyes and ears on something and just start testing out, like, what is it that we actually need here? And this did stretch myself and a lot of my direct reports a lot, but it was really worth it in the end.

Why? Because we understood our problem. Better and you started to build multiple use cases for that role instead of just [00:17:00] hiring to fill a gap. So several examples of this fractional consultants for, you know, um, tactical ops rules that you need. If you're thinking about promoting really high performing, ICs first put them in sort of a player coach role with other team members and have them mentor before you hire them in.

Um, run quarter long pilots around a problem for us. I actually did several of these this year and ended up figuring out that the problem I thought we were setting out to solve was not the problem that I needed to hire around at all. So, anyway, I think this whole principle is waiting out discomfort so you can learn something meaningful and actually solve the real problem instead of just flailing at problems.

[00:17:44] Danielle: I love that one. Um, all right, let's go. Gift seven. Getting towards the end of our 12 GIFs. This one is, When in Doubt, Fly Out. Um, too many decisions are made from, as you've said, Sandy the Ivory Tower.

And [00:18:00] also, just As we grow and as more and more folks come into the mix, it's very, very hard to connect oftentimes to the why, um, and in health care, the why is often at the most basic level, the patient, um, and any which way you can gain insight into the patient experience from a firsthand point of view is always, always, always valuable.

I see this a lot too, as folks are shifting business models. Right? Like, let's say you're going from like a D to C to B to B route, an entirely new way of unlocking the same care has like evolved at your company. Go out into those hospitals where you're piloting, meet the people on the ground, build relationships.

The end of the day, like that connection to the, to the human, um, kind of like what makes care care is not only good for the business, it's good for the patients and it's much more fun that way too, I think. So when in doubt, fly out. Um, that's my gift. Number [00:19:00] 7.

[00:19:00] Sandy: I love this and I love, I love that it rhymes too.

It's so zingy, but I couldn't agree more. I actually, you know, this is something product is really excellent on getting in front of your users, understanding their pinpoints. I don't hear operators doing it as much, but. As an operator myself, I probably spent the last year traveling every Other week, so 50 percent of the year was spent on the road in front of people.

And it was because we were standing up an entirely new business line, trying to figure out how different roles plug in. How are we going to hire a team around this? What products do we need to build, et cetera, et cetera. And there was no way I could have done that without just being with people. I think one thing you didn't mention for this to be valuable is also as a change management tool, right?

Like you going onsite is bi directional. You're not just learning from them. They get to learn from you. You get to run a drip campaign with them and set ideas with them. You can ask the question of like, what if we did something this way? That has made all the difference for [00:20:00] me and like getting things stood up zero to one quickly because the team members on the other side feel like very bought into it and trust my judgment.

[00:20:07] Danielle: I love that. Yeah, I love that. There's also, let's go one more layer of then sharing that. Uh, things that you picked up on the ground back internally is its own kind of form of art. Any tips around that to help people, you know, be in the room where it happened? Kind of, yeah.

[00:20:24] Sandy: Yeah. I think this is all part of the, the very meta drip campaigns that you should be running.

This is part of helping people understand the problem. You know, I've seen lots of forms of this. I've seen, you know, five pages, single spaced of raw notes to grouped by themes, which is. Insightful, but I find that people read those and walk away, not really taking much away from it. Like you as a product manager, an operator might be writing tickets or running sprint initiatives off of what you learned off of that level of detail, but no one else really is going to take away much.

So I always, after [00:21:00] I travel will include at the top of my monthly business readouts, like two or three things I learned while I market and why this gave me conviction in the problem that I'm trying to solve, because not everybody is going to get to travel as much as you are. Or see the same things.

[00:21:12] Danielle: The things that you're seeing, trying to document them.

Of course, like, you know, being mindful of PHI and so on, but, uh, photos are actually the tool that you gain when you're in person. So don't, don't forget about photos. Um, I remember when, when Nikhil did the, his post about firsthand, he like took a selfie with one of your team members, one of your peers. And there was some, something just so humanizing about that.

Single photo that really connected me to firsthand and it was such a small small thing, but big one.

[00:21:46] Sandy: I love that I don't underestimate photos We actually share photos a lot in slack of like how people organize their work especially if they're not using our tools like they have their own calendars that they highlight in their own different ways and we just take a picture and post and have people react [00:22:00] actually the reactions can be a lot more insightful than

What you're noticing yourself. So lots of rich teeth on this one. I love this. Yeah. Yeah. All right. All right.

[00:22:09] Sandy: Gift number eight, build an ops roadmap.

Depot. Have you ever felt like one of the first times I met you Depot? This is why I knew we were going to be really good friends.

As you told me as an operator, you're just focused on like this with your palm in front of you. Everything's on fire and you can't see around the corner and. By the way, especially if you're a services business, you're helping end and product prioritize their work. And if you're not turning the corner, neither can they.

And suddenly you're just in this big fireball, not really prioritizing work appropriately.

[00:22:40] Sandy: So, I would argue, this was your first tip. Think like a PM.

An operator needs to have a roadmap just like a tech org would. So, you know, what are I think at very big companies, I would venture to say like Series D onwards, your roadmap can just be your OKRs and like some simple initiatives you're going to run out to get them. But earlier [00:23:00] stage and operators in battle building stuff just like a PM is.

So what are you focused on? Is it running these pilots to get conviction in a problem? Is it, you know, hiring a team or figuring out what profile you need to hire around? Is it working more closely with your payer ops teams to figure out like better data feeds to inform your workflows? I don't know what it is, but the whole point is.

3D chess stay three steps ahead. Instead of focusing on the fires in front of you just build that muscle thinking ahead. So, for me, like, uh, some tactical examples.

So I have my own notion landing page for our activation business unit.

It outlines. What we're running out. What are our, you know, revenue goals? What are the business priorities? We have our own sprint board of different ops spikes or You know initiatives that we're running at tasks that need to get done They're all assigned that also creates a surface for tech to interact with us because they can assign their bugs or whatever it is To initiatives we're running at as well So the whole point is it [00:24:00] gives visibility to the entire world Org of where we're bottlenecked or what we're focused on and gives people a surface to react with us.

I also think, you know, generally in the process of writing out what initiatives you're focused on, you get a better idea of how should I be prioritizing this? Or is this actually not a problem at all? Cause I can't write anything about it. So I shouldn't focus my time on it. Just generally good muscle there.

[00:24:22] Danielle: I think, um, any kind of service level type of, uh, challenges that you kind of can't move the needle on using a roadmap as a way to anchor yourself as like, Our goal this quarter is to hit like a three minute SLA or to hit a 90 percent ticket resolution rate.

Um, I actually think a lot of quantifiable things in service businesses can be very good candidates for roadmaps because they help everybody march towards the same. Like North Star metric, which ideally is like either a growth metric or just like a better patient experience metric. Uh, but, uh, getting that momentum is so difficult a lot of times in ops and so [00:25:00] something very plain and simple, like an SLA.

Moving the dial on that hugely valuable.

[00:25:04] Sandy: Yep. And extremely tactical, you know, our head of engineering, Brennan always says, don't write an initiative if you don't know when it's actually going to be done. And for you, like moving the SLA from X to Y, you know, when it's done versus like build a higher performing platform, like that's not an initiative as such.

That's ideally a vision, but yes, I don't know. I think at first hand we organize ourselves, I think, extremely well, where a tech. Teams are focused on capabilities like things that are cut across different business units. But a business unit is going to be focused on typically very health carry dense topics like.

Building a transitions of care program that I mean, it is a product, but it is an OMS product, whereas, you know, a tech capability that might enable that are things like work lists or alerts, but building a T O C program involves potentially hiring up nurses, like exploring your data feeds, et cetera, et cetera.

So if no one on the tech team is focused on [00:26:00] that, then you have to be the person thinking about it. Anyway, I'll, I'll get off my soapbox on this one.

[00:26:04] Danielle: Anything that ends in program is an ops responsibility

[00:26:07] Sandy: Yeah, yeah! And programs are products. Like, I don't know, it's just, it's not a helpful distinction, I think.

[00:26:15] Danielle: I'm going to pivot. I had, this was gift number or gift 10. So at the finish line here, I'm going to, I had one in the backlog that I decided to take out, but I'm going to bring it back in. So gift number 10 is, uh, not to forget about the power of schedule sending. Uh, this one just. Reminded me, Sandy, of that feeling of maybe folks who are listening didn't see Sandy put her palm like inches away from her face, which is the feeling that so many of us get, especially in Ops and in the kind of constant communication, uh, culture that many of us have, Slack, Teams, whatever, there's like this, like, you know, like you're frantically on your keyboard responding to everything, I think, Schedule sent [00:27:00] is one of the simplest ways you can force yourself to pause.

Especially, I know Sandy has showed, showed me screenshots of responding at like 2 in the morning. No good things happen at 2 in the morning over Slack. Nor is anybody responding. But, uh, scheduling that out for 8am gives you the opportunity to sleep on it. And think about it just like a, a smudge different.

So if you're crafting a big message and it's late at night or you're finding yourself just kind of in a state of mind where thoughts are frazzled, obviously like there's many ways you can do it right on a Google doc, but schedule send is a nice forcing function to help you say like, I'm going to sleep on it.

And then tomorrow it'll do its own thing.

[00:27:40] Sandy: Totally love this. Um, for gaslighting me on the 2am Slack. It was actually 3am and people were responding depot cause we all had something to learn. But couldn't agree more. People don't create distance from problems and situations enough, and that's... it's,

you need to force yourself to do that. Otherwise you react too quickly and you create distractions [00:28:00] for yourself and others. that is related to.

My next gift, but I think we skipped a gift, so I'm going to go quickly on gift nine. Let's go. My bad. Uh, which is before effort comes focus, but similar vein, which is, can you work harder on a few things instead of trying to do 10 things at once? I think you can be innovative and focused at the same time.

And the goal is consistency, not intensity in my day to day. So, for example, for me, I have been better about forcing myself to sign off at 6 p. m., not because I don't have enough work to do after that, but I'm forcing prioritizations and distance from problems. Like, you might be solving every little thing if you're working until midnight every day, and that is distracting.

It just adds to the noise and chaos and takes you off your feet with your thinking. So, you know, be really principled. Trying to start with problem statements in your day to day, like why are you focused on this instead of just tackling your entire to do list and, and force just signing off to create distance.[00:29:00]

[00:29:00] Danielle: You also have a lot of rituals around your day to day. Like, can you give us like that top to bottom just explanation of how you manage your day to day?

[00:29:07] Sandy: My calendar template. Yeah, for me, I'm a morning thinker. So I always start my day with two to three hours of focus time. I, my day is entirely shot if I don't have it.

I've learned that about myself. So that might mean waking up earlier in the day just to get that done. Uh, I don't have recurring one on ones with people. I love to catch up with folks. I'm hugely extroverted, but I cannot have standing time in my day to day unless like I really need something from you, which is often like a direct team member or probably a product counterpart.

Um, the other standing things on my calendar are like our shared rituals with product. So grooming, sprint planning. quarterly readouts and sometimes quarterly one on ones with mentors within the business like our CEO or CFO. But other than that, I really try to carve out more focus time, less meeting time.

[00:29:56] Danielle: I love that. I think you can kind of take an audit on [00:30:00] yourself too. Uh, the way I've approached this one is Like, where, where have I been asked to think and where have I been asked to do, um, and just doing a gut check around your day to day environment on like, oh, I'm in do mode, which you can tell by your elevated heart rate and just like proximity to screen versus I'm in think mode.

And you can tell by your heart rate coming down and your ideas flowing out. And so, um, you can kind of be in touch, I think, a bit on the physiological level around which states you're in. Um, it's actually just like healthy, I think, to have a bit of that calibration just for our own beings. Yeah. Totally.

Are we on 10 now then, or 11?

[00:30:40] Sandy: We're on 11 now.

[00:30:41] Danielle: This was hard to keep track of. Yeah. Number 11, and Matthew Boo, I'm borrowing this one from you because I have taken your advice on this one and it's made the world of difference. So now I'm re sharing it back out into the world, which is to upgrade Your software [00:31:00] whenever possible to the AI features said it, it's necessary on every podcast to drop the word AI and we've done it three for three for real.

Though, I think one of the biggest challenges in op stuff is not just like the summarization and GPT and all that world, but it is just recollection of objective information that can find itself nested in so many different places. I particularly love. The Notion AI, which is a chat, basically functionality over your entire Notion database where you can ask it information the same way you'd ask GPT, but over your entire data set.

I've been playing around with building a GPT 4 bot for very niche information that like just your agents, for example, will need to know over and you can feed it a ton of different PDFs, catalogs of information, um, and then turn that into a sidekick towards your service line businesses and so on and so forth.

Um, when you are sharing [00:32:00] processes, you can do so for Loom and the Loom AI summarization is masterful and so great. Um, I just, I think we're in an age where like. Yes, it's table stakes, all that stuff, but there are some immediate wins you can use it for, and I don't see the harm, obviously, being mindful of PHI and so on, that's always my caveat, in just trying it out and seeing what you can get out of it.

You'd be surprised. Maybe you can kind of productize your own business, uh, with just like a drop of hat.

[00:32:29] Sandy: So how would you advise an operator who's in the thick of it? They're in the weeds. The fires are raging to create space, to think about this stuff. It's related to our road mapping, thinking ahead.

[00:32:42] Danielle: So somebody's like, all right, Depot sounds good, but like, I'm too busy for this.

[00:32:45] Sandy: Yeah, like me. I'm like, yeah, we're hiring team members like crazy. I don't have time to onboard them as much as they deserve. And there's a lot of like colloquial knowledge that is, that is documented somewhere, but I don't know how to onboard someone to it and like, have them accountable to it over time.

[00:33:00] What would you tell me to do?

[00:33:01] Danielle: Oh my God, that's a big question. Uh, yeah.

[00:33:03] Sandy: Yeah. Top two things. Tell, gimme advice. Top two things. Yeah.

[00:33:06] Danielle: I mean, just first of all, just switch it on and try it for yourself, right? Yeah. Like, um, I, I think having a new hire be part of a pilot program that you're thinking is interesting, is a great way to like co-design this thing together and just be like, yo, we store a lot of information on notion.

I just upgraded our Notion AI. I'm curious, like, what you can gather and, like, what you can learn just by using Notion. Um, I'm gonna switch this on. Would you mind trying it out and see what comes out of it?

[00:33:32] Sandy: Very cool.

[00:33:33] Danielle: Anytime you're doing information retrieval is a good opportunity to test it out on yourself, too.

Uh, so I would do that and then, uh, this is Matthew Wu's tip. Find somebody who's already really engaged in the AI dialogue and bring them in too, and they can be kind of like that supercharger Internal team player for you who can level you up in parallel.

[00:33:53] Sandy: Yeah. A Sherpa, if you will, an AI Sherpa, I need an AI Sherpa in my day [00:34:00] to day. You can be my AI Sherpa. You got this. I mean, come on, just like nerd out, you know, like you just need like a solid nerd out sesh where you're like, yeah, let me see what I can learn here.

Yeah. All right, does this, does this bring us to our last gift? This brings us to our last gift. Drumroll, please. It's going to sound dull, but it is so important, especially in value based care where I sit, but contracts create choke points. So ask them questions about them.

Um, I know contracts is a very vague term, like you can, you obviously have contracts with your external vendors, data vendors, whatever it is. I specifically mean our customer contracts, like what are the value metrics that we are being held accountable to?

Um, in healthcare, I think it's easy to distill problems. To very simple slogans, and sometimes that can be dangerous because tiny, tiny nuances and how these contracts are worded can create really large Ops choke points. So, one example is, and keep in mind that figure of [00:35:00] a thousand building blocks, they're all teetering against each other and the one Ops associate is holding it all up.

Imagine that like one or, you know, one line of a contract can impact. That entire setup, right? So for us, for example, um, certain states contract differently with their managed care vendors on certain benefits that are carved in versus carved out. And if something is carved out in a given state, that could have a lot of downstream implications.

Like, you're not going to receive claims for that particular line of business and your claims might be the thing that drives a lot of your. Right? Let's talk about how you might take an important task and benchmark it or see how your mining

Um, and just have time with your BD and actuarial teams and just ask them dumb[00:36:00] questions.

[00:36:00] Danielle: Do you have like a list of questions you ask for every contract now?

[00:36:04] Sandy: The major one is like, especially because we're a Medicaid focused company, everything varies by state. So start there and then a lot of follow on questions happen.

Um, but it's going to look different for, I'm curious for you, especially not focused on value based care per se, but you are building ops businesses. Did you ever ask questions about what these contracts look like from your customers?

[00:36:24] Danielle: I actually think that's a great use case for AI to, to upload a contract. I don't think it has any PHI and ask it questions like, uh, against that. And, uh, I think, sorry, we're now you had my brain going on the AI use cases. I think that's an easy way to do it. By giving it context around the problems you've seen before on contracts. So short answer is like, no, it's not super relatable, uh, for me personally, obviously contract and reading them thoroughly is important, but I, I didn't understand really the dependencies that go into value based contracting, um, that impact workflow [00:37:00] downstream. Yeah, good one.

[00:37:02] Sandy: I love that, like, your knowledge doesn't have to be person or team dependent though, like, you can do this as an exploratory exercise on your own.

Um, if I can get my hands on the contract and upload it to an AI tool.

[00:37:13] Danielle: Yeah. That's what I'm saying. It's like the table, like the, the stakes for just like updating, like paying the 20 more a month. Yeah. Try and get out for a bit. Like what do you lose by that? You know what I mean? Yeah. Yeah. Interesting. So that's kind of the thinking there.

[00:37:27] Sandy: Yeah. Love it. All right. Any parting thoughts Depot? Any feels with the 12 gifts?

[00:37:34] Danielle: It was hard to, hard to, to come up with, it's hard to keep track of 12. I think we needed a timer or like a tracking board. What about you?

[00:37:43] Sandy: I think for me, the two that stood out were your very first gift and mine were, many of mine were flavors of that.

Think like a product. Person would as an operator, it can take you really far, whether it's rituals, frameworks for thinking about problems, tools you're working out of, you mentioned [00:38:00] loom, notion, et cetera. Like those have really been levels up for both of us. Um, the second is that, you know, creating reflection can force some prioritization.

Um, that looks different across a lot of different problems. But for me, I think I've learned that startups. don't starve, they drown. And it's because you might tend to focus on too many things instead of the core thing that is actually value driving. So how do you make sure you're thinking about that one thing instead of the 10 things?

How do you structure your time that way? How do you surround yourself with people and ask the right questions? So you're thinking that way. I think operators need to be. Angling themselves more in that domain than they do today.

[00:38:42] Danielle: Yeah, I love that. Sandy, uh, coming here, dropping some wisdom at some objective sources of truth always come from Sandy.

And, uh, I think there's like a plaque somewhere out there that just has like etchings of, of wise things that you've dropped in our time together. So now many more people will get [00:39:00] that. Very grateful, Sandy, for you being here. Uh, thank you for sharing your gifts.

[00:39:05] Sandy: Thank you, Depo and thank you for creating a platform for all of us operators that are stuck in palm mode to look around the corner.

We'll get there together, and it's thanks to your leadership here. Thanks,

Happy holidays!. Happy holidays!

Let's Keep In Touch

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
search icon