Scaling decision-making, designing eng orgs for speed & scope as underrated leverage w/ Dhruv Parthasarathy #225

We're doing a special in episode feature on the future of AI powered incident management with our friends and sponsor, X Matter. People as a primary integration layer is really fragile. With multiple people and all of that coordination, you become slower to find the root cause. The slower you find the root cause, you then don't know what action you need to take to resolve it. Getting to that fast is the goal.

Later in the episode, Mike Bennett, who leads the engineering team at X Matters, shares why human-driven coordination creates outage risk and how AI-powered orchestration can dramatically accelerate your path from event to resolution. People who care about health, people who care about societal impacts of it, let's train them, give them the best experience possible, and let's help them execute super, super quickly.

As part of doing that, what we've had to do is essentially make our culture really, really I would call it like educational where we really, really help young people and people early in their careers develop all the information they need about what the healthcare industry is, how to execute quickly, what are the regulations, basically remove that that learning gap. And I I think that's worked out really, really well for us.

It's just a a reality that I think anyone in a non quote unquote super mainstream industry is gonna have to learn is you are gonna have to pay that cost of educating people, onboarding people. There are no ready made people in this field. Hello and welcome to the Engineering Leadership Podcast brought to you by ELC, the Engineering Leadership Community. I'm Jerry Lee, founder of ELC. And I'm Patrick Gallagher, and we're your hosts.

Our show shares the most critical perspectives, habits, and examples of great software engineering leaders to help evolve leadership in the tech industry. What does it take to move with? startup level speed and one of the most complex high stakes industries on the planet. We're talking about healthcare. In today's episode, we go inside the engineering org at Khmer with Drew Parthasarathi.

CTO at Comir and Othelis. And in our conversation, we talk about optimizing decision making and pushing decisions down to scale faster. We get into designing systems and leadership structures for velocity. Why Scoping is one of the most underappreciated leverage points in engineering and how they've turned their customers into true co-creators of the product and why that's the future of product building. Let me introduce you to Droove.

Dreov spent the last eight years focused on applying modern software and machine learning techniques in healthcare. In these roles, Dreuv has designed and developed end-to-end solutions for revenue cycle automation, ambient documentation, patient engagement, and at-home diagnostics for oncology. Before this, he was the director of machine learning programs at Udacity, where he led the development of the AI, self-driving car, deep learning, and machine learning nanodegree programs.

Dreve also worked as a product engineer at Udacity. I first met Drew when Kamir was actually hosting one of our ELC South Bay events. I walk into the room. Drew, first thing he says to me is, what can I do to make this the most impactful conversation? I can tell you his perspectives are focused on generating impact. But it's also speed and it's incredibly thoughtful. So I think you're really gonna enjoy this conversation. Enjoy this episode with Drew Parthusarathi.

Drew, just want to say welcome. Thanks so much for jumping in, joining us on the show. How are things going today? How you doing? Yeah, thank you so much for having me. We're a big fan of ELC. We've we just had an ELC meetup at our office yesterday. I think it's our second one. So things are going well. Thanks for having me on on the podcast. And yeah, morning's going really well. This was the lightning talk, wasn't it? This was the the lightning talk format?

Yeah, it was a lightning talk on rapid prototyping with AI tools. And so we had three different speakers, um a lot of participants. It was really, really cool. Some of the most valuable stuff in the ELC community is the diversity of approaches. They're like all these people trying to solve similar problems and have, you know, almost by like natural selection developed different ways of solving it. So lightning talks really expose that. And it also leaves a lot more time for like talking.

So right after the talks we you know, we had we had like twenty minutes open Q and A and that was probably the most interesting part. And I think the South Bay community is is starting to get hot.

We got connected because we we hosted an event together back in April. Like when we first connected, one of the big things that stood out to me was how fast the Commuer team moves. This event got spun up in like three weeks. And this was in the middle of like probably a pretty big portfolio of events that you also were doing. So that was incredible. But then the other thing was just like how clear it was, like the momentum and the impact behind it. And so I think there was like that context.

And then our first conversation when we were sitting down in the conference room preparing for the panel, the first thing you said to me was, I want to make this as impactful as possible. What do we need to do? And it was like, that was the first question.

So it was like all of these things to me signaled like speed, impact, making great things happen and removing the friction. And I was like, this is a ton of fun to collaborate with. Yeah, yeah, and that totally lines up with how we think about ourselves selfishly. I think we think about like Speed as this muscle that

Especially if you're a startup, it's the one thing you have that bigger companies, no matter how much money they put in, just won't have. And that sense of urgency, I think sometimes people think it it's like Oh, you're rushing. You're a bunch of kids and you're just running around in circles. No, I I actually think that's not true. Like the people who are best at their craft they move pretty quickly, I think. And so you know, we we really think that speed is just

such an important attribute to have in a startup. And it also like for us, the w the way we also think about it is it values our time more. If if you're in an environment where it's molasses,

you know, most likely your time is not being valid. You could have been doing ten times more things than you were doing. So it's it's a way of showing respect to everyone around us that y yeah, we're we're gonna move fast. You know, things that could have taken ten times as long, we're gonna do it faster so that you can get back to other things and we can do other more important things.

P G also has a really important essay about this where he says like Like a large part of the concept of a startup is compressing a lot of your life's work into a much shorter period of time while still getting the same results. It's again, his opinion was a way of respecting the value of his own life, right? So that's how we think about it. It's not just about rushing, it's about doing things quickly because there's value to our time and there's value to everyone else's time.

I was gonna save this for the end, but I think as you surface these principles, like the big question is like how do you operate and how does the community operate? And

Speed is so important as like the principles and the way that you operate as a team to be fast but thoughtful. And so I was wondering if we can dive into some of the principles around there. So one of the things that we talked about was like don't be a bottleneck and what that looks like in action. So like we're gonna jump straight to to some of those principles.

There's a few different things that that we tend to think about. This number one I always tell all all leaders, like your job is to not be the bottleneck or the of the organization. There's almost this like natural gravitational flow that happens where

Anything that can be bottlenecked to a leader will get bottlenecked to a leader unless you make like a really, really conscious decision to be like, wait, I don't need to be the one doing this. And and the reason that happens is one, people will defer to that being the safer outcome of like, oh, I asked this person for permission. And and number two

people are just used to it. If you are the one taking decisions, a lot of people will naturally just wait for you to take the decision. And so a really, really important part of speed for us is not just, oh, like type quickly or move quick. It's about like

structural design, right? And like if you look at the best swimmers and things like that, they are actively understanding what the friction of their environment is, in in that case a swimming pool, and designing their their body to move through that in as frictionless a way as possible. That's how we think about

you know, delivery of product and execution that there are these natural friction points. Our job is to remove those friction points and almost glide towards the the finish line. What are those friction points in an organization? It's bottlenecking on decision making. It's

people fearing releasing things too early and and the consequences of that. It's not having the right guardrails in place where, you know, someone can make a catastrophic mistake and then take everything down so everything slows down, right? So in terms of how we design for speed, you know, we really think about one, make sure that decisions can be made at the lowest level possible.

And make sure it's easy to make safe decisions. As in the defaults should be safe. I think this it's a standard software design principle, but you can do it for your organization also. Make it easy and and the default path to make good decisions quickly. And three, it's almost like this. house cleaning that has to happen. Decisions are gonna get stuck in your queue. Get out of those decisions and people are gonna be uncomfortable

starting to take those decisions on their own. Your job as a leader, especially as a fast growing company, is to get people who are not used to taking decisions to be used to it and be comfortable with it and make the organization comfortable with it. Being like, hey, if so and so has taken the decision, that's the equivalent of my decision.

So those are some of the things we do to to design for speed. I would say there's a few there's one last principle that's super important. Like I think the one problem you cannot solve no matter what is coordination cost, which is, you know, a decision that requires one person's input versus five people's input will always be like wildly slower and and it's exponentially slower, right?

So a big question we ask is how do we reduce the number of people who are in the critical path to delivering something? If that's one versus three versus ten, it completely changes the dynamics of delivery. And so we always try and get it to be like

Okay, we know we're making trade-offs that we're not gonna get ten people's opinion, but if we can get one person's, we can get it out, we can get review cycles much faster. And so we hire for people who are, you know, multi-talented. And if they're not multi-talented today, we tell them you are gonna be multi-talented once you join here. That means If you're a a back end engineer, you're gonna understand something about front end and start developing the front end pretty soon.

You're gonna understand how Figma works, you're gonna start looking at designs, critiquing it, you're gonna be talking to customers, you're gonna understand the sales process. Like all those things are super, super important. And I think that's actually the key to speed. It's you know, being able to play one through five with as many people as possible. One through five is a basketball analogy. And I think as organizations grow and specialize, they forget that, hey, actually

how we got here was there were few people making a lot of decisions that were they were probably not qualified for, but that's okay. There's a clear trade off we're making of we're getting out the market faster, we're moving quickly and reiterating faster and and long term, you know, we'll get there. So I wanna I wanna dive into a few of the different things you mentioned because I think there's there there are probably five or six Core principles that you that you'd mentioned.

The the first one is, you know, you're talking about optimizing for decisions as low as possible and making decisions as safe as possible. Can you bring us a little bit more into like what does that look like within the context of the team? And how does that maybe shift the way decisions get done within the context of Camure?

You know, I I really push my engineering managers and product managers say, if it's coming to me for a decision, like you can always bring me in, but I wanna see that you at least put in the work of thinking through the entire problem and coming up with your recommendation first. So first You know, making it really normal for them to have gone through the motions of coming up with a decision, but you know, even if if they're not making the decision. Number two, we make it such that it's

You know, I I think, you know, why does it not work that people don't make decisions at the lowest level possible? It's because people are scared of the consequences usually or or there's a need for more coordination than than we usually allow for. So

Let's break that down. Number one, how do you make it such that people can make decisions that go wrong and be okay with it? You have to be organized about what the risks are, right? Th there's some risky things like for instance for us it's Data privacy, it's taking down, you know, the the central DB that that we use to serve a lot of our requests.

two or three other things that are that are catastrophic, but that's largely it. If you isolate those risks and make those very, very hard to do, that's when people can start making decisions pretty quickly at the lowest level and not be worried about them. And so we have a platform team that's just dedicated to

Eliminate the need to even worry about this class of problems so that people can make mistakes and it's okay. They like roll it back through a feature flag and no nobody, you know, nobody panics. The things that fail are when people don't classify what these catastrophic risks are, and now everyone is thinking about these catastrophic risks on every release.

I think it's a concept called decision fatigue where if i if you make people keep on trying to make decisions throughout the day, they'll make fewer decisions. Um You know, if if you've read like Power of Habit or something, the the the reason the habits work is like you just move from one habit to the next and it's all about organizing your time appropriately.

The analogy there being if you remove the need for thinking about what's gonna happen, what if like this catastrophic thing happens, people will make decisions faster and and move faster and it'll be natural.

So that's number one, you know, make it less risky and and be organized as a leader about what the risks you're trying to get rid of are. The second is people will always worry, like, what if we build this thing twice? Like team A is building feature A and team B is also build building feature A. Should we consolidate right now? Our our general philosophy is like

No, let's not consolidate too early. Like if these both turn out to be monster businesses, one, that's a great problem to have. Like we have two gr fast growing businesses. Number two, then we've earned the budget to go and and consolidate. And yeah, it'll it'll slow us down a little bit. But the biggest risk is usually like The execution towards

the customer, right? As engineers w we've spent so much time working through technical debt that the only debt we believe exists is technical debt. That's a fallacy. There's financial debt, there's uh market debt as in your behind your competitors, there's organizational debt, you know, there's

All these other things and and the one you really want to avoid is obviously financial debt and, you know, market debt. Technical debt is a solvable problem. And so if you can turn everything into a technical debt problem, awesome. You're you're probably on on your pathway to winning.

That's how we tend to think about it. The clarity you have around these principles, like it really stands out to me. So, like, how did you learn like this lesson around optimizing for speed, clearing decision making, removing friction? Like, when did that become the paradigm for building the engineering organization? It's not something like necessarily we we learnt on the job. It's it's just something if you if you look at like historic examples of successful like

initiatives. It's it's something that I've noticed a lot of speed of execution tends to be a wildly important decision factor. You you see the same thing in in in a bunch of different areas. Like I'm a big sports fan. I love Liverpool

You know, Liverpool was in the build rooms for a while, Jorgen Klopp came in and he said the one thing no defense can account for is speed, which is we're just gonna attack faster and press harder than anyone else. And I don't care how how strategic you are, you can't do anything about that. I think that same principle applies in, you know, business. It's like No.

No company can really protect against speed, no industry can protect against speed of execution and and you see it everywhere. So you look at where are there these unexpected success stories, it's people who just moved really, really quickly when others were taking their time, right? And and so

premise, but but that's that's our general belief. And then I'll be honest, we've gone through phases where we just are like, we're gonna just work crazy hard and that's how we're gonna achieve speed. And then you realize actually the way to achieve speed is is much more about design. It's like

Like leveraging good organizational design, process design, you know, the same things that auto manufacturers have done in their plants, you have to figure out how to do within your company. And and that actually makes a big, big difference. And that's really how we try and think about it. This whole topic of building the muscle for speed gets me excited because it to me it's like it's learnable, it's designable.

We're taking a quick break for a special feature on the future of AI powered incident management with our friends and sponsor, X Matter. Mike Bennett, who leads the engineering team at X-Matters, shares why human-driven coordination creates outage risk and how AI-powered orchestration can dramatically accelerate your path from event to resolution. We're the ones that are correlating the alerts across the platform.

We're the ones that have to remember that a similar issue happened six months ago and this is what we did about it. We're the ones that have to figure out this is a symptom in service A, but it has a dependency in service B that we need to know what that dependency is and how that could impact this thing. We decide on who is going to be page based on some informal knowledge.

It's it's not scalable. I mean it all of that works in a in a very small scale environment. But as as systems grow, as teams grow, people as a primary integration layer is really fragile. So the outage risk is with with multiple people and all of that coordination, it you become slower to find the root cause. The slower you find the root cause, you then don't know what action you need to take.

to resolve it. The risk there is not knowing immediately what the problem is, so you don't know what the route for that mitigation is. With all of the information that is out there, getting to that fast is the key goal and is the key problem when you've when you're relying on people to do it. When a signal comes into X Matters, the first thing that you can do is based off of that signal, you can then make a call out to the right people.

for our incident process internally, a signal comes in that says we've got a system problem, the first thing it does it pages out an incident commander and an ops person because those are the two people that are most likely to be on uh you know required in any call. From there, the incident commander can then use automations that are set up in the incident because it it automatically creates an incident for us.

It's linked to the ticket that generated the incident. And from there we can determine, okay, well I've seen I've seen this before because my incident suggestions is saying this looks similar to this incident you had last week. We've got built-in automations that can do stuff. So within an instant, you might have an automation that says automatically restart pods or automatically rollback services. Like I mentioned before, we can also do that as part of a response.

to the signal that comes out to say, okay, this has happened, do a rollback and I can just Touch my phone and go back to bed without even getting out of bed. all of the automation, the flexibility of the tool and all the the things that you can build in along with the data that you've got with the service catalogue, with your on call, with your who's on duties and gets you to get the right people at the right time on the call if you need to get to a point where you're in a conference.

X Matters automates the entire incident lifecycle, taking you from initial event to final resolution. To see how their purpose-built AI slashes your resolution times and gives your team the context to stop disruptions before they start, head to xmatters.com. That's x-ma-t-t-e-r-s.

dot com. One other element of this, and then there's a couple other parts we want to get into, is you're talking about like decisions get stuck and how do you get out of decisions being stuck. And so I I wanted to dive into like what does that look like within the context of the team? How do you help people get out of being stuck around decision making? You have to like

organize the team such that there aren't too many decision makers in any route. Right. If you put together an org or let's say a group working on something and there are five decision makers or people who are used to making decisions

then you're gonna have five people who are everyone's waiting for implicitly to get approval. If you try and separate out the decision makers, and I think that's that's a really valuable thing, there'll be one person and it's very clear. And this is like the Amazon principle of like who owns the decision.

There's an explicit way of doing it, being like this person owns the decision. There's an implicit and I think like design way of doing it, which is separate out decision makers and make sure that each group working on something has it so clear you shouldn't even need to ask ideally. So that's number one. Um, we really set set ourselves up into these really small pods. And at a high level that sounds straightforward, but actually what you have to do is change how you hire, change how you set up

you know, your company culture such that teams can move independently and make decisions independently. And you don't need, for instance, everything to go through the VP of product. You don't need everything to go through the head of design. And these small teams can just make decisions on their own.

And then as long as there's good written communication of like everyone can keep track of what decisions are being made, you know, it's fine. And then I'll pair that with we also have choke points where Let's imagine this is like a giant pipe of water flying, right? And there's certain areas where you do want decisions to get constrained on purpose, such that you have control. Otherwise, you know, you're you're kind of just swimming in the water a bit.

And so we design those choke points. So for every product, there will be a a design review phase. And that's something I'll be involved in. That's something key leaders will be involved in. For every hire, like especially senior hires, I will put myself and and make myself the bottleneck in those cases.

There are ways of essentially designing the decision process such that you put certain um bottlenecks that you free up the rest of the decision making throughout the org and everyone knows that, okay, it's gonna be it's gonna come to design review and if they have something to say, they'll say it then.

until then we can run, you know, pretty aggressively and and keep moving. Hopefully that that answers the question. But I think the T L D R is like one, you know, set up your team such that there's not too many decision makers. If there's this idea of let's put a bunch of superstars in one room, usually that kind of like

You know, especially if people aren't clear on who the decision maker is, that usually doesn't work quite as well in our experience. Number two, make sure people know when the points where you will be involved are so that they don't have to keep thinking like, Do I need to ask you? Do I need to ask you? And it's very, very clear, like explicit. transparency around when the decisions happen that you will be involved in, help everyone move faster.

So I want to start to shift to a couple other different ways that you operate. But I think at this point it might be helpful to dive in a little bit more into like understanding of the context in which you're operating. And so like you're operating within the healthcare space.

And so I was wondering if you could share a little bit about what it's like to build a high-performing engineering team in the context of healthcare and what's been the hardest part of building out a strong engineering team in that space. Yeah, yeah, great question. There there's a few things that are that are difficult about healthcare. Number one, it has such a bad rep that most like smart people getting out of college are like

I would much rather work on any other problem. I've just heard healthcare is slow. I heard it's painful. I heard I'm not gonna do anything and I'm just gonna sit around and wait for some kind of certification or something, right? So you you are counteracting that

So explicitly from day one, we're like we are a fast moving company and and a responsible one though. Like we're we're not going to be fast moving around, let's say, like data privacy and things like that. But we are going to be, once we've set those up, we are going to move fast on product execution, et cetera. There's no reason we can't do that. Um the second thing is I think you have to be realistic that

you you are fighting a little bit upstream of you know, your your standard people are know that the big places to do work are open EI, Anthropic and stuff like that. So if you're trying to compete on that same playing field of like I'm gonna try and find these these people that Anthropic and OpenEI would would hire, it's really difficult. I I think what

we are much more realistic about is that there are a lot of people who are very passionate about healthcare or who've seen it's a problem and they're super smart. Let's get those people here and let's get them to succeed versus trying to find like the standard like

smart, sharp, quote unquote cracked engineer and try and fit them into into this world. Like we want to play games we can win. The game we can win is People who care about health, people who care about societal impacts of it, let's train them, give them the best

experience possible and let's help them execute super, super quickly. So those are a few things we've thought about and then as part of doing that, what we've had to do is essentially make our culture really, really I would call it like educational where

where we really, really help young people and people early in their careers develop all the information they need about what the healthcare industry is, how to execute quickly, what are the regulations, basically remove that that learning gap. And I think that's worked out really, really well for us. It's just a a reality that I think anyone in a non quote unquote. super mainstream industry is gonna have to learn is you are gonna have to pay that cost of educating people, onboarding people.

There are no ready made people in this field and and uh especially if you want to do things differently. And so I would say that's how we've thought about building an organization in this area. But it's a challenge we like. Like we like

the process of educating, we like the process of seeing people grow. So it it's worked out well with kind of our own preferences as well. What have been like the high leverage points of of onboarding?'Cause I I think, you know, an engineering leader listening to this and

starting to identify like okay, th this is like this is how we can compete in in hiring as well. Like what what have been some of the high leverage parts of of bringing in maybe less experienced engineers and like really helping plug them in to to speed and and impacting and executing on products? From day one we tell our engineers like this is not a get tickets and do the tickets job.

This is a job where you are going to have to be a designer first and an engineer as as part of that, right? And what does it mean to be a designer? You really understand the problem space. You really, really spend time with your users. You really know the ins and out of how the product is made. And so, you know, on on onboarding, like our first week you have to work with our operations team, submit like fifty denials back to the payers.

and see how the entire insurance claims process works. And uh the next week you're gonna have to do support tickets. We make everyone do, you know, random support tickets that come their way. Uh and now you're gonna have to learn the product, use every little part of it. And then with every shipment you do, we make you get on a call with one customer who validates that, hey, this product did what I expected and I I make everyone like send me a little quote being like

Show me the quote from the customer who said this made their life better. If we if we can't do that something's a little wrong'cause I think sometimes we can hide behind like cool stats and and data and it's like we can simplify a lot of this. Just find one person and tell me what they thought of it. So th those are the things that are how we We educate as an we make you just get embedded really deeply in all these things from day one. The second thing, obviously, tons of

um investment in documentation and and onboarding of everything from guides around how these processes work, breaking everything down. With L L Ms what we've learnt is documentation just has wild returns on value now. Everything is is way more accessible, usable in in a way it wasn't before. you know, we we really, really invest there. The last thing I'll say is because people are coming in completely like unmoulded almost of like what a what a great engineering org looks like.

we can guide them towards principles that we have that are unique and and probably not what they did other places. And what that looks like is being this very full-stack person where you know we encourage you to be in design. We encourage you to be in sales. We encourage you to to do front end and back end. And that may not be normal in in other cultures, but it's very normal in ours.

So th those are kind of the the leverage points. It's like from day one, embed them in the key operations of the company, make sure they're doing support, make sure that as part of their release they're going and talking to customers.

And we will also actually like fly our engineers out to our customer sites like once every couple of months. And like there's there's just no experience like that of like actually seeing how a healthcare practice or hospital works. No amount of textbooks can really explain that to you. So Th th those are all the things we do in in our onboarding and learning process.

Well, I I think the the last point sort of opens up another area that I wanted to explore, which is sort of the dynamics around

How engineering, product, and design are evolving and some of the different ways in which like you've led the team there. Cause I think one thing that you and I were talking about earlier was the future of customization or the importance, the the rising importance of customization within workflows. And I think the other unique part is this practice where you have engineers going live on site to hospitals and working with

real doctors on on the product. And oftentimes it's live and like you're taking feedback and like they're making real design decisions right there in the live. So I was wondering if you talk a little bit about like first off your perspective on like the rise of customization and then some of the the ways that those beliefs start to then manifest within running engineering product and design.

Yeah, yeah. So may maybe I can take a step back on like how we deliver on some of these things. I think one big thing I try and really push everyone in our org is you are not boxed into just engineering and or just Design or just product. Like, you know, I think one of the big misconceptions of people coming out of college and in general is that you know I am trained in this.

Focus, and this is all I'm supposed to do now. And actually, we're capable of way, way more. Like I encourage people to be like, you are a super smart person who happens to be really good at this. engineering skill set, but whatever you did can also be applied towards design. There's nothing crazy about that. If you look at like the really, really great executors, like you know, if it's

Steve Jobs and things like that. He knew every detail about calligraphy. He knew every detail about how um the web worked. He knew details about packaging design. So you ha you want people to be breaking this concept of I'm a specialist. And no, you're a polymeth and you can be a specialist in multiple areas. If you think about what the customer wants, they want one person they can talk to about all their problems.

They don't want you to bring a team of ten people, each one you have to email independently. So we encourage our engineers, our product managers, et cetera, to be capable of playing again one through five in that analogy, which is they can talk Coherently about the design. They can talk about the product choices. They can talk about sales. They can talk about engineering and now you know, that one person can go and deliver a much better experience that and customer.

They can do everything from, you know, rework the design a little, rework the product a little, um, and deliver it on site with the customer versus having to coordinate with five or six people. That's how we were set up and Both culturally and and operationally. And we think that's a big part of how the future of organizations would look where people are absolutely gonna be these polymat style people given they have like LLM's helping them with every bit.

And the job of the organization is get all the craft out of the way of these people and let them go ex execute for the customer and make it such that they have the right Legos and building blocks such that they can do it easily without creating a bunch of debt, right? So tha that's how we're we're set up, like everything from our investments and, you know, standard things like people know about design system, platform, et cetera.

But also our culture, our toolkit that we provide our developers, um, how flexibly people can move between orgs, all that is designed such that in the dream state, one person can go to something like, you know, an H C A or, you know, a local healthcare practice and hear their problems and deliver something very quickly. I I totally see that polymath style approach.

It's emerging right now. I mean, half of the conversations we're having is about how engineering, product, and design are blurring into each other and how everybody's starting to shift into each other's capabilities. And so like that ability to execute across a lot of different functions is becoming a a almost like more mandatory requirement.

Yeah, yeah. I I just think it's a lack of imagination to think your your best designers can't be technically excellent on engineering or your best um engineers can have great perspectives on design. And it's the job of a leader to realize those opportunities and get people to develop in those areas because unfortunately, I think the only reason people's growth levels off once they get out of college is there's no structure on how you learn those things.

If you can structure it and you can encourage them to think like, yeah, I'm I'm also a designer and you you can totally make it happen. You know, in the past, a lot of our healthcare customers, they viewed their job as like, I'm doing this road function, whether that's calling a payer three times a day or I am like converting this

facts into a PDF and uploading into my system, think about it as like mechanical process oriented people or jobs. And now like when all this gets automated, we really believe that they are viewing their job and the and the leaders are viewing their job as much more as designers of these processes. Instead of like the mechanical labor of the process, they are the designer of the entire process. And so give them the tools to write out this process

and turn it into a software product application. And so that's where I think a lot of a lot of companies like ours are headed, which is Hopefully these people who who ear earlier couldn't build these systems, but knew knew the system that needed to be designed, now have the tools in plain English where they can say, here's the process I have in mind. I need to do X, Y, Z, uh, and then I want these kind of outputs. And then, you know, the product is there for them to try out and build.

Yeah, you you start with doing it with configuration knobs, being like, Okay, you know, instead of clicking like twenty different configs, you can just write it into your L L M that'll and we'll create the config for you. You get to the next level when you actually help them build like software applications almost that use your your underlying hooks.

to do really interesting things. And so our job is turn everyone into designers, increase the creative output of what's possible. And don't believe that you are the only one who can design systems. I think every person in these organizations as actually like really, really intelligent, knows way more than you ever will about their crazy workflows. And if you can just let them define those and and build them, you'll see a lot of cool things happen.

We've been talking a lot about building the muscle for speed. And one other area of friction or big lesson area that we talked about was scope and being able to turn scope into a leadership lever. And so I was wondering if we dive in a little bit about Some of the lessons you've learned about scope and some of the ways that you've evolved or shifted scoping and how that creates leverage in different ways for you.

Yeah, I mean it's a great question. I think scope is not an easy problem to solve, especially like in things like healthcare and things like defense. Organizations internally are a wild mess. They're not using good software. They're using stuff from the eighties, seventies. And so it's very hard to scope them into saying, Here's exactly what I want you to do. Here's the only thing we'll support because

you're throwing away a decent chunk of the market and and you're you're trying to abstract away complexity when you just can't, right? And you have to acknowledge that there's just way more complexity in these older industries and

And so scoping becomes a real challenge. Now, the next question comes into if you're willing to take on, let's call it custom development, how do you actually budget and account for it well such that you don't turn into a dev shop for all these random health systems and organizations throughout the world?

We think about it as phases. There's phase one, which is, okay, we are gonna just let people go and build what they want, because we don't actually know the full range of configurations that exist. And Everyone on sales, everyone understands like this is a this is a small period of time where we are going to be open ended on scope. Then immediately we then clamp down scope like the next quarter. We'll be like, Okay.

Here's all the things, here's the commonalities of what we defined, and here's the configurations and abstractions we're gonna build now that define you know what scoping will look like. And we're gonna aim for compounding wins in this area. If we're not able to hit it,

We'll revisit next quarter and expand the scope of what we do. How we think about it is one, knowledge that we don't know the full complexity from day one and it's very hard to, so keep some scope open-ended, but have a budget for it. Being like we are gonna put these, let's say, ten people who are gonna work on open-ended tasks.

And that's all you get, sales team. You're not gonna get anything more. If anything goes beyond, you have to go tell the customer, sorry, and you get to decide how to utilize this pool. This is your resource. The next quarter, then look at what those ten people did that was custom, turn it into product and say, okay, we're going from ten people being open-ended to now it's three people being open-ended and now it's one person being open-ended and now there's nothing, right?

So to almost like while you're discovering the market, reducing that labor pool such that you've pushed those constraints onto the sales team, uh, I think that's how we try and think about it.

The pattern of that seems really effective. How do you assess like which area is going to help create a compound win? It's'cause I'm thinking of like healthcare is complex. And like I think you and I were talking about how all of these systems are kind of built independently on top of each other that are sort of random. So it's like one of the most complex places. Like, so how do you identify compound wins in that context?

There are some parts of the healthcare stack that are common business problems. that y you can be like, Yeah, it's pretty obvious that a business that utilizes XYC would would be better off and and those things look like Can you give them much easier to use reporting so that they can understand how their financial health looks like? That's compounding win. Like I I don't think you have to really do a bunch of like user discovery to be like, Well reporting that's

That's simpler, help you run your business like, no, okay. This is kind of standard stuff and and and that's kind of the great thing about being in healthcare is you can look at what's worked in other industries over the last twenty years and be like Those modern practices are going to come here. We we we can play it pretty simple. So when we say compounding wins, we look for okay, here are like key things that are the core parts of running a good business in other industries.

That's gonna be consistent in healthcare. And and so you're gonna need great reporting. You're gonna need, you know, low friction onboarding. You're gonna need high speed. high reliability, et cetera. So so that's how we we think about it. And then the other thing we look at is like

For compounding we look at okay, what are markets we want to win? And so we really care about playing games we win. We think in in general the world is moving towards less prices for second place. So we then ask like what are areas we're doing well right now where a few different investments would put us

So clearly in first place that it would be stupid to look elsewhere. And so that's the second area we look for in compounding because there's just insane returns from being number one versus being number two. And if those are big enough market sizes, you should absolutely go for it versus trying to be second place in six different areas, right? Those are the things we think about.

One, like what are the obvious things that great businesses are doing in other industries? And and the tech industry is a great one. And there's some principles where you're like, this won't change. People are always gonna wanna wanna run a great business with less overhead, more visibility in how to grow my revenue.

And basically less work, right? That's anything anytime you're in one of those areas, just just go. Don't ask too many questions. You don't need to do user studies. And the second thing is are these things that are getting you into first place in a market? Great. That's totally something that compounds and let's go after it. If it's just changing you from fourth place to third place, it's like, is this really the best use of our time right now is immediately the next question we'd ask.

Amazing. I love it. Truve, I know we're we're coming to the end of our time. Are you ready for some rapid fire questions? I am. All right. First question. What are you reading or listening to right now? Um, the thing I just read was Tarantino has a book called Cinema Speculation. And that was really, really cool. It's about

this dude who's just nerding out about every single movie he saw since he was like three years old. And um I think it really communicates like, you know, greatness in any industry requires some amount of passion and and love for the for the medium and the art form. Um and there's so much you can learn. And and the other thing you learn is like Tarantino started as a Um He was actually like a D like a D V D store guy, but he would give reviews for all the things he saw and

He just like it again shows you that polymath. People who are interested can learn every little detail and and spend way too much time on things that others don't care about and become really good at their craft. So you see a great Tanatino movie, it recounts like twenty other movies that

few people realize, but he knows because he's seen so many movies. And so th that was a really cool book. I I think it really applies to any kind of creative work of like how do how to be that passionate, how to be that detailed, how to notice so many things and and you know, I think you look at great software designers, they'll know who any time they use a new piece of software, they're like, Whoa, whoa was that? Let me oh, that's kinda cool. How why aren't we doing that?

Ama amazing recommendations. N Noah, our producer, is a huge film geek. He like has a membership to a vintage theater, goes all the time. And so I'm like, that's great. Next question. What is a tool or methodology that has had a big impact on you? a tool or methodology that has had a big impact on me. I think I um I I read this like a long time ago on some blog, but

Somebody said like forget all the crazy task management systems out there. At the beginning of your morning, write down like here are the five things I'm gonna accomplish and then at the end of the day look at it and say, Did you do it or not? I think

That help that works surprisingly well. I've tried all these other crazy productivity hacks. I just put a sticky note on my laptop every day and that's kind of what I go after. I do the same thing on a monthly level. I say this month, these are the three things and everything else is kind of noise. And I think that's really important. These organizations are so noisy. So that's a technique that's worked well for me. And let's see. What else? The other technique that's worked well is

Honestly, like waking up a little earlier, you know, the y I I read I think Steve Jobs once said like, you know, to be a leader you have to be ahead of your organization. You know, otherwise how are you leading? And so what that means is like actually start your day earlier so that you are ahead of all the noise.

If you just wake up and you're thrown into the vortex of noise, like I I don't know if you can be that effective. So I really value having time before everyone else gets here so I I can work in peace for a little bit. Don't get thrown into the vortex of noise. I love that. Second to last question, what's a trend you're seeing or following that's interesting or hasn't hit the mainstream yet?

a trend I'm seeing or following. I think the trend I'm seeing or following is like a a lot more I think the a little bit of oversaturation of of AI and convenience and I think people are purposely taking on less convenient choices almost as a way of being like

Being like, Yeah, I don't want everything perfect. I don't like it's almost like a a cultural thing and and you see it in like people are way more interested in thrifting. They don't want this perfect thing that looks like it was assembled at at crate and barrel and ship directly to them. And and I think even in their clothing, in in like usage of technology, people are are actively questioning, like, I'm gonna do the th thing that's less convenient if that's okay.

Um so I think it hasn't hit the mainstream yet. I think it'll hit I I imagine it'll become more popular over a couple years. I I don't think people just I don't think convenience is the point of life. And I think There will be a point where people say, like, yes, these things are inconvenient to do, but I get meaning out of them. And and I d I don't think all we have to do as as tic as like, you know, people in interested in technology is just like

make everything more optimal. There's some things that are okay if if people spend like you know, in uh Japanese people spend like an hour on tea ceremonies. Like you could make the same tea in like three seconds. There's something but it's not all about optimizing time necessarily. So I I think that whole like cultural and spiritual angle will start playing more

of a role in the next three years. Like any time something goes way too much to one side there'll be a s pendulum backwards and I expect that to come. I'm so all in on that. I started restoring furniture. as my sort of analog human made element. And it's messy. It's imperfect. So I'm I'm all in on that trend. Yeah, absolutely. Last question, Drew. Is there a quote or mantra that you live by or a quote that's been resonating with you right now? Yeah.

One thing that's big been resonating with me, I don't know where I picked this up, but it's this idea that life is not a competitive pursuit, it's a creative pursuit. And I think seeing it as a creative pursuit unlocks you a lot. in the sense that you're not constantly worrying about, you know, so and so company is doing that much better and they were at this valuation or I'm you know, I should be doing more. It's like, you know what? Like in school and stuff, it's a lot about like

There's this very standard pathway. Everyone's kind of funnel funneled together like minnows into these little streams and then you've tr you know, all you see is like this is the world and and there's nothing else. When you uh get into the real world, it's kind of like that scene in Finding Nemo where the fish leaves the little aquarium and it it's in the big ocean and now you get to kind of figure it out and do whatever you want. And the main thing to realize is

It's not about trying to move from point A to point B faster than anyone else necessarily. It's go explore the ocean and see all the cool stuff out there and, you know, have fun with it. I think that's an important way of of looking at your work, your life, all that kind of stuff.

Um it's very easy in competitive industries like like tech to just think like, Okay, all my job is this is a single lane highway. I am just trying to get at to the first place of the single lane highway and It's just a uh I think it's important to have a a a broader perspective than that.

I think an incredible power a credit an incredibly powerful way to provide balance to how we opened up with this, which was like building the muscle for speed and decision making, to end with go explore the ocean. Life is a creative pursuit pursuit. Life is a creative pursuit. Drew, thank you so much. for sharing your time with us and sharing your story. Really appreciate it. Yeah. Thanks, Pat. Really appreciate it. And see you guys soon at the next uh ELC meetup.

If you're listening to this and you're wondering, how can I connect with other engineering leaders in my city? Pull up your phone right now and go to elc.community. Click our chapters page. You can see that on the menu on the left. Find your local chapter and click join.

Hosting virtual and in-person events all the time. And this is the best way to help you get involved, expand your network in your city, and support your leadership and career growth. So pull up your phone, head to elc.community, join your local chapter, and get involved. A huge thank you to all of our local. leaders who make community happen and thank you for listening to the Engineering Leadership Podcast.