Episode 20 | Leading Async Engineering Teams & Building Hardware with Andrew Conner from Levels

Eiso: [00:00:00] Welcome to Developing Leadership, the podcast where I, Eiso Kant and my co-host Jason Warner share our thoughts and lessons learned on engineering leadership through the years. 

Today, we welcome Andrew Connor, co-founder and engineering leader at Levels, the continuous glucose monitor that provides realtime metrics on how your diet and lifestyle impact your metabolic health. 

Andrew joins us to talk about what it's like to lead an engineering team at a company that has a strong hardware component. From working remotely in an asynchronous environment to the importance of continuous feedback loops, deep work and transparency. We also spoke about wearable health devices, drawing parallels between optimizing your life using metrics and how the same is true for engineering teams. 

Today's shoutout goes to Barry Frost for leaving an awesome review for us on Apple Podcasts. If you enjoy the episode, leave a review on Apple Podcast or Spotify and share it with another engineering leader. As always this episode comes with accompanying show notes, featuring our favorite moments from the chat and a deep dive into today's topics. Find them at developingleadership.co and linked to the [00:01:00] description. 

 Hi everyone. We're back again with another episode of Developing Leadership. Today, we have with us Andrew Conner, the Engineering Lead for Levels. Both Jason and I are really excited to have Andrew on the podcast because we're both fanboys of the product that he's building. And at the same time, Andrew shared with me that we have something in common, which is we were both remote before the rest of the world was remote, actually all three of us here. So we're gonna have some interesting chats on that, but Andrew, maybe I'd love for you to kind of kick it off a little bit, your story. And I think what's particularly interesting for our listeners today is the fact that you have a true hardware component. Your job is a lot harder than the rest of ours and love to hear a little bit more about that. 

Andrew: Yeah. Yeah. The reason that we were interested in Levels is you can think about the healthcare system across the world, particularly in, you know, the, the Western world is very much centered around sickness care and almost nothing [00:02:00] around wellness and preventative medicine in these kinds of things. And so people are largely DIY, they're trying to solve the problems themselves. And in many ways, things feel overwhelming, like what diets work for them. And, you know, people hear all this like conflicting information. And it's interesting because hardware has existed for a while that can tap into this. You can kind of think about this as like a gauge cluster in a car or something like that. Being able to measure internal metrics of what's happening inside of your body that's relevant. And we are, you know, in some ways it's kind of a weird way to think about it, but fortunate that the disease of diabetes exists, which created market incentives to create these continuous glucose monitors.

And so the opportunity we saw was to bring continuous glucose monitors and be able to measure things continually and create these like very short term salient feedback loops for people to the masses. And so I think like that's the thing that excites me the most and, uh, [00:03:00] you know, bringing this data to people. But I think it's more about data. It-it's also about understanding, you know, the core loops. I don't know if either of you have used like sleep trackers or things like that before. I certainly have and the funny thing was I got almost all of the value in a month because I realized all the things I'd been told to be true about sleep health were actually true and I, but I was able to like reproduce them for myself. 

And so things like alcohol late at night disrupts sleep, I think cognitively I knew it. I didn't know that like inside of me, and so we, we see the exact same opportunity with metabolic health. You know, people in many ways that they know, you know, processed food and sugar and all these things have impacts, but when you are actually able to see it and how your body uniquely responds to things is pretty powerful. 

My personal story of why I'm interested in the space is that both of my grandfathers had type two diabetes and heart disease. And so, both of these are metabolic syndromes and it was interesting because [00:04:00] in family discussion, it was very much seen as, "This is a, you know, runs in the family, genetic disease of old age." and both of them, you know, were nominally healthy. Um, neither of them were obese, and it contributed to both of their deaths. And so I, you know, here I am in my mid 20s, you know, several years ago thinking, "Oh, I wanna avoid this. Like, I wanna avoid this outcome for myself." And so of course, I talked to my primary care physician and I had, you know, just read Tim Ferriss' 4-Hour Body. He talks about glucose monitors like, "I want that." And so, you know, I tell them, "I'm interested in this, runs in the family." And they said, "You know, we, we don't prescribe hardware to people without a disease. Let's run a hemoglobin A1C blood test to see where you're at."

And of course I wasn't pre-diabetic, I wasn't diabetic so they said, "You're fine, don't worry about it. You're stressed over nothing." And it's interesting because that was the exact same roadmap my grandfathers went through, like, they're fine until they're not, and then you're diabetic. And then, you know, it it's, you know, changing your life. And, and so in many ways, like I was disappointed with that. So I tried again, I switched primary care [00:05:00] physicians [laughs], tried again. The exact same response in that time, their response was, they were concerned I wouldn't know how to interpret the data. So like the data itself is poisonous in a way, or like potentially dangerous and can cause anxiety and I won't know how to interpret this.

And it's like, and, and the interesting thing was I accepted that. I was like, "Okay, like this isn't for me, this is for biohackers that are trying to optimize every little thing. I'll just try to watch the amount of sugar consumption or something like that." And I met, um, Sam Corcos, our, our CEO a few years ago, and he was talking about this as well. And I was like, "You know, I've trying to get one of these devices, I know that you can buy them bootleg on the internet, like you, that you can get them shipped from another country. But I, I would love something like this." And so it, it basically immediately was like very clear. I was like, "Either I'm, I'm investing in this, or I'm joining, like, you know, this is something I need to work on. This is something that's really important." 

And it became clear almost instantly that our, our job is not just providing data to people. You know, like it, it's almost like you're interested in being [00:06:00] healthier, you want a personal trainer and instead like you get a heart rate monitor. Great, cool. Now you have like the context of what's going on. You, you can see you're working out, see when you're not. That doesn't really tell you much. And so it became very clear, even for technically savvy people. The role of what we actually need to do is understand what's happening inside of people and like the drivers of metabolic impact and make this really clear. 

Jason: I love the story and it kind of relates to something that I've done in the past. And interestingly relates to our podcast Developing Leadership too, because we talk about feedback loops a lot and understanding what is happening. And in fact, you know, about 12, maybe 13, 14 years ago at this point, I was working out quite a, to, uh, quite a bit, and I felt off. And I remember going to my doctor, took some blood tests, all that sort of stuff. And they said, "Hey, we think you might be pre-diabetic," all that sort of stuff. I dove in, I did all this stuff.

I wrote books on fitness, I got super into fitness. I got super into weight lifting. I under... I, I started to really understand, but what I, once I really understood all the different mechanisms, including, you know, glucose or hormone, the endocrine system, feedback loops, uh, weightlifting versus cardio versus sleep. As you said, you actually start to understand the systems. You, you can basically get the benefit of that in the month. What you also start to is that the information you're getting from your doctor is not, it's very applicable to a moment in time, but it's not applicable for you to make the lifestyle changes you need to, to understand it fully. It takes too long. The feedback loops are too long for fully-

 [00:07:00] Mm-hmm [affirmative].

 ... fully maximize and optimize your lifestyle.

Andrew: Yeah. In, in many ways they're also optimized for populations and not individuals. And if you think from a policy perspective, this makes sense. You know, you want to have the largest population average. And so for example, for people with type 2 diabetes, there are recommended diets that they'll go on and in. And, you know, I-I've seen one of these, I don't know how universal this is, but my wife's grandmother has, has type 2. And I, I saw the recommended diet from her physician and she has like a carb budget. And the [00:08:00] interesting thing is I've observed her try to hit her budget. As in, "I get this many grams of carbohydrates, I'm gonna make sure I get all those," you know, things like that versus realizing like when you have metabolic syndrome, you know, we actually can push this pretty far.

And, you know, organizations like Virta have been reversing type 2 diabetes with very strict diets and-

 Yeah.

 ... you know, basically giving, giving the entire metabolic system a rest and a reset. And in many ways, like I think people that are able to scrape together enough, either motivation or urgency are able to do this, but on a population basis, a lot of people feel, you know, powerless, defenseless. Like there's not a lot they can do, this is something that happened to them and, you know, they need to manage it. And, and I think it's like a very different way of thinking about wellness and health.

Eiso: I think it's interesting. And because, I mean, you're preaching a little to the choir here because you're speaking to someone who for over seven years has cut lots of things out of their diet. I bought one of those glucose monitors where like the display is this terrible LCD. And like- I measure everything from Vo2 [00:09:00] to, to heart rate and it's led to like, and I think this is the point where we're talking about the same in engineering or any system is like the moment you start getting continuous feedback loops. It, isn't just the fact of knowing what works and doesn't work for you. It also acts as a motivator for change for a lot of people, at least particularly does for my personality. 

While I know that we can spend probably two hours talking about this, I'd love to kind of take that and transition like what you've learned about the metabolic system and what you've learned from continuous glucose monitoring and everything related. Has any of that seeped into the way that you are running engineering, which is just another complex system with feedback loops?

Andrew: Yeah. I, I like your point a lot about like, "We need feedback loops and like, this is incredibly important." You know, one parallel that was really interesting to me is that extremes are not typically sustainable. And, you know, we see this with diets- where people go on an extreme cleanse or something like that, and it's never intended to be long term, or if it is that, you know, they [00:10:00] break. And we've seen some of the most successes through Levels of people that figure out the right way that they can be a moderate when it comes to diet in life style interventions and these kinds of things and what are the small things they can do that are actually really sustainable? 

So parallels to engineering, you know, in many ways, systems can have these very small changes that create, you know, very large impacts because you're not trying to be extreme, like you're not trying to necessarily stick to agile, scrum, you know, whatever, whatever process, you know, very, very strictly it's finding, you know, for the team, "What is sustainable and what are the, what are the things that people are interested in and, you know, resonates with them?" And then building on top of those own resonances and like reinforcing the things that are, that are working and, you know, yeah.

Jason: I love that. We talk about this a lot, or I do at least when we talk about agile scrum, as an example in engineering, which is, you probably have to take a prescriptive approach to it if you've never [00:11:00] seen it or never done it, because then you really need to dive in and understand why they would make recommendations or these prescriptions in the first place. And once you understand your organization, your goals, and then maybe some of that methodology, you start throwing away stuff that doesn't work for you ' it doesn't work. 

And in some ways, like what you just said with the diets are true too. So a good example might be that you're rice sensitive. Maybe I'm not rice sensitive, but if we both just clash and said, "Hey, is a low carb," well, you're low carb, my low carb don't look the same. Yeah. Because maybe I'm more sensitive to the, to the potatoes of the world and you and rice, but so that I can do something slightly different. But if we didn't have understanding of the individual, as well as the overall system- we're, we're gonna be talking past each other for hours.

Andrew: Yeah. Yeah. And, and in many ways like we, you know, as you mentioned, we started remote first and a little bit was by accident. We, you know, the co-founders all lived in different cities. And so we, you know, decided, "This is how we're gonna start." And maybe [00:12:00] there's a parallel universe where we all ended up in New York or something like that. But, you know, early on my fear was in early stage startup in, based on prior experience that we'd miss this a bunch of people in a room working really, really hard and being able to like churn out something. And it turns out that like deep work is really, really important. And being able to actually create these boundaries around, "Here's something that I'm responsible for, and I'm gonna have a immediate impact, you know, on," turned out to be incredibly powerful. And so we kept on building on top of that and rethought a lot of systems. So we have almost no meetings like, on most engineers have maybe two hours a week of synchronous meeting time. And half of that is our company all hands, which is recorded and optional.

And so in many ways, like we, we found that we can opt out of the systems that power a lot of these like larger organizations where, you know, maybe they have more coordination overhead, or maybe there's momentum behind a [00:13:00] meeting culture, but when we're fully remote, we can kind of like rethink this sort of stuff. And so it was funny early on when we were fundraising, we had just, you know, for ourselves written these very long memos and, and I think Levels has become semi-famous for some of our memos that are just, you know, very long, that really outlined the context in our thinking and these kind of things and they're very asynchronous feedback goes inside of them.

So you'll have like, almost like a memo that's feedback to these memos and sort of stuff. And so when you're fundraising, we would give these two investors. And it's like the, you know, in many ways that would allow the most useful time synchronously because it's not about, "Hey, what are we doing, and like what's Levels and what do we see the problem space and who's the team?" Not answering any of these, like in like providing a very deep ability for people to like, fully understand what we're doing.

Turns out customers like that too. And so like, we've been, you know, very open or, you know, engineering candidates, you know, I tell them early on in the process, everyone who's interviewing with us that in many ways, this is a matchmaking, and we want them [00:14:00] to feel comfortable with what is the organization they're joining. And so, you know, how do we operate? Who are the people inside of it? You know, them seeing our thought process. And in many ways, hiring is, is almost like a blind date, you know, in many ways. And it's like speed dating because the interview process by and large is broken.

Like you can't get the, the depthness and the, the richness of a person in, you know, quick algorithms interview. But the other side is also true. Most people have no idea what they're actually joining. And so I think for us, it was very important to have these systems that, you know, facilitate transparency and facilitated us being able to work in like a more asynchronous remote environment.

Eiso: I love what you're saying, Andrew, and I think a lot of it resonates with me because we have a similar to who our meeting max per, per engineer culture, and have been remote for years. What I would love for you to dive a little bit deeper into is you mentioned this notion of like the value of deep work, particularly at an early stage startup. And I, I think a lot of engineers who are listening to this are like, "Yes, you know, [00:15:00] give me more deep work, less interruptions."

What are you giving in terms of context and product input and priorities so that people can actually go off and do that deep work without having to spend a ton of time in meetings and how are you doing that in the engineering org?

Andrew: Yeah. So I think there's a few ways we can think about this. Early in a company, it's easy for someone to hold the context in, in their head of like all the dependencies and that sort of thing. And so early on, it actually becomes easier in many ways, for someone to have the idea of something or the, you know, the motivation and, and run with it and be able to, you know, minimally have critiques or, you know, "Did you think of X or did you think of Y?"

So as we're growing this changes, you know, on, on one hand we have kind of a, a top down roadmap and priority, and this is something that we are very careful about and we guard, you know, because I think for most companies, early age startups focus is paramount. Like it's, it's, especially if you're working in a [00:16:00] very large space, which we are wellness and healthcare, like, you know, there's so many problems we could chase. In many ways we have to focus, we have to make sure that we have a very valuable program and, and product for people that they're willing to pay for. And, you know, like almost like scope this down, "What is the thing that people will actually care most about?"

On the other hand, everyone inside of Levels is a Levels customer. And I I've worked on B2B SaaS before, I've worked on products where the excitement comes from technical challenges, or, you know, something like this. In many ways, a lot of our excitement comes from, "Hey, this a problem I have." And like, you know, a lot of the engineers inside of Levels, either they've been on a metabolic journey themselves, they've lost a lot of weight or they've had, you know, a loved one that's been impacted by metabolic syndrome or, or something like this. And so because of that, we're able to hire around product-minded people and people that like, they care deeply about the product we're building. And so you can think of like, this comes from both sides. We have this [00:17:00] roadmap of far off, what's important to us. And then short term, we have a lot of people that are just really excited about what we're building and kind of think for themselves. And so the, how this actually plays out is a little bit project by project.

So some of them have more traditional product specs, you know, not like, you know, highlights this button and it turns this color, something like that. But like, you know, more detail, this is, you know, what we're observing from customers where we think the problem space might look like, but in many ways, engineers are the best equipped to be able to propose possible solutions. So like, I've seen it many times where someone recognizes, "Hey, we can potentially address this, or at least explore this product landscape 80% cheaper than you think we can, because we can do X, Y, Z," or, you know, something like that. And so getting engineers involved really early on is important. And then I think once something is, is set out and we've basically agreed on phasing it and that sort of thing, it's, it's largely up to the engineers to, to, to go off and, and execute. 

And [00:18:00] so some projects it's, it's multiple people. And so they'll come up with their own way of coordinating whether it's, you know, they like synchronous check-ins or, or something like that. We have one project now that they have a, like a daily asynchronous message. That's pretty heavy for us. So like, we don't do daily standups or, or anything like that. So that that's pretty heavy. And it's because like tight coordination is needed. Other ones, like someone's holding the context and they're like, "Cool, I'm gonna go implement this and we're, we're gonna like do the phases that we're gonna launch. We're gonna iterate," and that sort of thing.

Jason: I love the way you described it. When I talk to startups a lot that are scaling, I talk about the way that you can decision make. And I said, "Hey, if you think about an entirely hierarchical tops down, everything needs to kind of flow from on high decision making, you're going to get some sort of an organization." But then there's another side of the spectrum, which kinda emerged the last 10 years that's completely bottom up, driven decision making. And I said, "I don't believe either one of those or actually ever true inside organizations, though in reality, if you find yourself stuck into one where you're talking about a, a [00:19:00] complete tops down or a complete bottom up, you're gonna have nightmare scenarios in my opinion."

But what you're actually after is more of like this diamond structure somewhere, which is at the top, you're talking priority and focus and long term and "whys", and at the bottom, there's micro decisions about which library to pull in or like you said, "The button, color or placement," or all those sorts of things. And in the middle, there's this band of all these decisions that are being made with the right context in the moment because everyone understands the business. And it's a, once you, you feel that and you understand you've been a part of an organization, you understand why it can move so fast.

 But if you've never been in an organization like that. You say, you almost think it's this theoretical. "I, oh, if, if only their companies actually work that way." It is possible, it's just a lot harder, I think, to actually go and implement something like that, because, I mean, it's easier to be slow and say, "Go do X," or it's easier to be disorganized and say, "We don't know what's gonna happen and when it's gonna come because we haven't actually organized ourselves around these sorts of things."

Andrew: Yeah. And there's a lot of Boogeyman fears that exist in our [00:20:00] industry where it's like, "You know, what, if we ship something and it doesn't meet our design standards or, or something like that, what if this breaks, you know, what if this?" And in my experience, like sure, sometimes there's risks there, but there's also risks in not doing something, right? Like, you know, what is the, the risk of not shipping and learning from our customers and getting feedback and that sort of thing is pretty high. And like, we, we saw this, you know, back talking about transparency, there is a risk to be transparent.

So my first startup was in stealth mode and it was a consumer startup. In retrospect, it's funny that you'd ever turn away interest and excitement and these sort of things. But around 2012, 2013, there was a lot of, you know, stealth mode startups that, you know, the idea was, was like, so good that no one was going to, you know, be like it wasn't about execution, it was about, you know, the idea itself. And what we recognized is "No, like we're, we're, you know, as much as we can talk about what we're doing, both on the process side and on the product side, [00:21:00] like, this is good for us." And we, we, you know, the, "this openness has a cost," but in many ways, these costs have turned out to be like Boogeyman.

Like what happens when you email your investor update to 1500 people? We that's what we do. And, uh, it turns out that a lot of people are willing to help you. And, you know, you're like, "We're trying to hire this role that's really hard to hire for." And a lot of people are like, "Oh, I know someone that'd be perfect for that." Do our competitors copy our roadmap? Yes, like we know for a fact they do. But that, that like allows us to play at our game and like focus on execution and these kinds of things. And for us, that's incredibly powerful.

Jason: It's and almost taking this full circle back to fitness or metabolic stuff. And I use this example all the time when I'm talking to people about running startups, which is in, in a fitness world, a lot of people wanna research fitness programs or regimes or all those sorts of, and they say, "Hey, I really wanna run a marathon one day. So I'm gonna learn all about, I'm gonna research all the shoes. I'm gonna learn all about the different types of training routines, but [00:22:00] I'm not actually gonna go run today." So I always flip it around and say, "No, no, no, there's this thing called Couch to 5K. But the, the idea behind this is just do something today, just do something." And it's the mindset switch of while you're researching or while you're block X, Y, Z, if you just walk the block, or if you just ran that block and tomorrow you just ran two blocks or three blocks by the time you figured it all out from a theoretical perspective, you're already [laughs] in a much better spot. And what's worse that can happen? You realize you hate running, or, you know, the theoretical worst thing that could happen in that scenario is you get injured. But the odds are from running a couple of blocks, you're not getting injured that way.

Andrew: Yeah. In many ways, like starting things like I'm a rock climber and there's these exercise called hang board exercise. We, we are hanging from your fingertips. And for some people they're fun for me there not fun. And so what I did is like I put my hang board right above my office door and when I walk in, I do some hanging. And what that turned into is I developed an entire routine without really [00:23:00] trying to, and without having like forced myself or having checklist or something like that. And so like, one of, one of our values is default to action and we'll deal with it. You know, like some are very hard to go back from, but most decisions in a company are pretty easy, especially in software. So, you know, on our, like our regulatory side and hardware, some of these decisions are very, very delicate and they're very difficult.

Cool. Like, you know, we understand the, I guess the gravitas of, of those decisions. For almost everything else, if we mess up, we're able to fix it. And, and like, we've actually by being open and, and honest with customers, they're thrilled when this happens. Like they're thrilled when like, you know, we're able to provide a great support experience because we messed up. And so like in many ways, almost providing redundancy and, and multiple layers allows us to move a lot faster and, and, and avoid a out of the like analysis paralysis and that kind of thing.

And I think this is especially important in any company, that's building a product in an entirely new space. There's a lot of companies that are [00:24:00] building products that are fairly well defined, you know, like you understand your customers needs and these kinds of things. We understand our customers needs pretty well. But in many ways, this type of product doesn't exist. And so this is something that like, we have to try a lot of things, fail, roll them back, see what happens and then iterate from there.

Jason: The, the one difference I was gonna say here, and I'm curious about your perspective on this given where you are too. I try to give all these examples and I try to illustrate how you would do these things in startups. Another thing that I really try to impress upon people is that you can only go as fast, or maybe as far as you have basically pillars of people that you can bank on to go lead and take full initiatives from you. If you've not hired for people who are default to action or that sort of scenario, you might be stuck. I'm not saying that people who don't take that initiative are not useful inside organizations, but startups in particular need people who are going to go and see something say, "That's probably not right, maybe I can go do something about that," grab it, and run with it. And [00:25:00] hiring is critical for this.

Andrew: Yeah. And, and I wouldn't understate the importance and value of creating the culture you want to have, or, you know, pretending like you have the culture you want to have and then people falling along. I-I've seen this in like social gatherings where, the room has a certain vibe, people join in and then they assimilate to that vibe. And so, you know, part of this is in our hiring process, we're very transparent. Like we give them a lot of memos. They understand that being a Levels engineer actually requires writing English. Like, you know, that that's actually a, a pretty big thing because instead of a meeting, they might start with an engineering design doc that, you know, is, is much more detailed than they're used to. And so I think the expectations are set. This is new for a lot of people.

And so we actually like when people on board, we tell them, "There will be a transition period. You're gonna get no Slack notifications. You're not going to, you know, like it is okay to entirely turn off your phone entirely, turn off your notifications, be dark for three hours, nothing will break." Like, [00:26:00] you know, and, and the asterisk here is like, we, we have it like on call rotations and we have a way of actually reaching people if indeed there's a problem or we have redundancy there. But in many ways, you know, by creating... 

And in some ways, like it was a little bit accidental where we were doing what we thought worked best for us and we were realizing that as people joined, they started doing the same things like so you know, impromptu, one of our new engineering hires joined. And one of the things I, I tell them on their first week is, you know, they're running an integration test for our process. You know, there's the product of the company, and then there's the company itself as a product. And it's very hard to test things inside the company. There's no automated task or things that. You could poke around a little bit, you can check morale, but in many ways it's hard to test. So every new engineer is a runner of the integration test for onboarding process and our culture and all these kinds of things. And so I tell them, like, my number one request of them is not necessarily to release so many lines of code or ramp up so [00:27:00] fast or something like that. But it's make a list of the things that did not make sense. So, you know, poor documentation or something was confusing or you're getting conflicting messages, or you didn't know what to do or something like that, make a list. You don't have to fix them, but we want to know what are the things that break?

The interesting thing is almost everyone fixes them. And so, 'cause like they, they recognize that like, "Hey, this documentation's here." I'll give you a perfect example. When all our max moved to M1 Max, our onboarding was broken for setting up the React Native development environment, right? And so who actually caught that? Was a new hire. They fixed it, they updated the documentation. So almost always, if you create, like, I guess self-healing systems, people will follow with what they see and then, you know, the list of things that they can't fix or something like that, that goes to me, it goes to like their onboarding mentor and we commit to fixing it. And I think like as long as the organization can have that kind of commitment. So like, "Hey, we're actually going to fix things when we, when we see that they're broken," it allows the systems [00:28:00] to self heal.

So back to what you were mentioning about, you know, what happens when you have engineers that don't have that kind of initiative or, you know, don't think outside of, you know, their exact role? I would challenge people to, you know, try to change the expectations and, and change what they're rewarding and, and, and that kind of thing. You, you can get a lot further than think you can now. I mean, obviously you can't replace a good hiring process and finding people that, you know, match, I guess, the resonance of your company. And, and that's what is really important, but in many ways, like people want to do something that's valuable and they, they want to, you know, get along with, you know, the, the system that they're joining.

And so for us, that's actually been, I think one of, of the keys was, "Think about how you can create a system that's self-healing." And so, as it atrophies or as the company doubles and the thing that used to work doesn't work anymore, "How are you gonna catch that and how are you gonna fix it?" And so for us that's been really important.

Eiso: Fantastic. Andrew, since we only have a couple minutes, I'd love to actually shift to another topic and you touched upon it briefly, [00:29:00] you have to deal with hardware.

 Yeah.

 A lot of our listeners don't. Talk us through a little bit about some of the, maybe non-obvious things in engineering and engineering leadership in particular, when all of a sudden you have a hardware component as part of your product.

Andrew: Yeah. And, and I'll, I'll even broad this to any regulated environment. We're in healthcare and we butt up against, you know, like FDA and FCC regulations of health claims and these kinds of things. I think for us, what was really important is to understand like the, the confines of the arena that we're playing it. So for example, for the regulations, really early on get a expensive law firm that helps us really understand, "What are the boundaries of what currently exists and what are the places that are a little bit gray, what are the places that are fairly well established?" And, you know, kind of establishing the playground that we want to, be inside of.

Obviously with hardware there's, you know, just pragmatics of, you know, we have physical device fulfillment. And [00:30:00] so there was a time where, so we have these, patches that go over our glucose monitors, that have branding on them. And, you know, they hold the patch or the, the monitor there, more securely. We did not realize that we were out of patches and we had like seven days left of patches left. And so there's this like massive hurry, "Find a screen printer that can print these things on," like absolute startup hustle. And it's like, "Fantastic, drive these things across town and get them to our distribution center." 

And so I think there's more of that, but also, you know, many problems in software have analogies in hardware. You can have tech debt that's like spiraling outta control, and like things are duct taped together, or you can have a process to try to detect this. And so I think part of this was we found people that knew operations really well. That is not me, that is not my specialty, but it turns out like there is a very strong domain expertise around, you know, running companies with physical products and distribution, and these kinds of things effectively, you know, having boxes, having tests on, [00:31:00] "You know, what are people actually receiving?"

"We know what we're paying for, what are people actually receiving?" And so for a while, we would rotate which employee that week was getting a box. And so that we'd be like, "Okay, is this box set up exactly how we expect?" And so that-that's obviously, you know, something that you need to work around and, you know, you need to think through. In terms of the actual hardware itself, right now we were able to benefit by using off the shelf, like currently FDA approved hardware. This is in the future, like, you know, as we think about, you know, the, the future of hardware gets a lot more difficult. And so like when I was at Google, I worked closely with a, a team that had a hardware and software component.

And their hardware component, it's interesting. When you get software engineers in charge of hardware, they don't realize, "What are the hard things and what are the soft things, or what are the easy things?" I think every software engineer has had the experience of a product manager be like, "It would be great if X, Y, Z," and like waving their hands like, "This will be really easy." And it's like, everyone's freaking out because this is gonna be like the hardest thing in the world and vice versa. Sometimes like, [00:32:00] "Oh, we would love to do this, but we know this expensive," and some engineer's like, "Oh yeah, I can do this in five minutes."

And so the exact same dynamic exists between software and hardware where it's easy to forget the things or not be aware of things that are actually hard. And so in the example that I-I'm thinking of back at Google, a product manager changed the color of a device, and that changed the acoustic properties of a microphone inside of it, because, you know, in the real world color, pigments change the material, right? And so from them, they're thinking, "Oh, you know, different colorways, you know, all these different things. Of course, that's great, everyone wants this." And for like an acoustics hardware engineer is like, "Oh my goodness, everything's changed, we have to have separate models," and you know, all these kinds of things. 

So I think in many ways for software people that are butting up against hardware embracing, "You know, it is a different domain. Things break differently, speeds are very different." A well run startup will always be the fastest. And so in many ways, you know, I would recommend to people, "Never be the blocker." Like, you know, if you're working with a hardware partner or, or something like [00:33:00] that, be the easiest to work with, because they will always be massively slower than you are. Whether you're in FinTech or, you know, health-healthcare or anything like that, these systems are old, they have a lot of cruft and it's like frustrating a solid meditation practice can, can help through [laughs] some of that. But yeah, so some of the things that we've learned through like having a physical device.

Eiso: Amazing. Andrew you've given us a lot of wisdom. And, and actually, I would say you've actually spoken, and described a lot of what is the, the modern asynchronous remote first company today. What are some of the things that you're really worried about as you start going from what is still relatively, you know, small organization to one that maybe goes 10 or 100X, particularly organizationally?

Andrew: Small organizations are able to get away with things that don't scale, right? And that's like, kind of a, like Y Combinator adage, but it's also very true. You can rely on heroic engineers, you can rely on broken processes and [00:34:00] things like that. And often you don't realize what are the things you're relying on that don't actually scale. And so, like what we run through an exercise, what we'll do regularly pre-mortems. Turns out a lot of people have inclinations of what might fail, but like, they don't feel free to express them. So if you run a pre-mortem process of like, "Why did we die?" We have a document that we, recently wrote. It begins with, "Levels died today. This was avoidable, but here's what happened." And then we, we walk through all the different ways we think today Levels could die and what we're gonna do about it.

It's obviously a, a concern of thinking about like, "What systems do we have that are embedded that just don't scale?" One smaller one is we like to hire curious generalist engineers that like working in a lot of different areas. And inevitably as you start to formalize teams and have, as you have much, like separate stacks and these kinds of things, it becomes harder for for people to have the freedom, to be able to like, you know, build a feature or product [00:35:00] completely end to end, just because it touches a lot of dependencies and these kinds of things.

It's a freedom we have now that in the future we need to be very mindful of is like, "What are the trade offs? Like when we design engineering teams, what is the role of an engineering manager and what, isn't the role of an engineering manager? And like, you know, how can we facilitate and encourage, you know, free exploration across our code base?" And, you know, these kinds of things. And so I think in many ways, centralized powers can be very efficient, but inevitably they break because they're not, you know, optimized for like what's actually happening on the ground as it gets bigger and bigger. 

And so that's a concern I have, but it, it's also incredibly exciting. Like I feel that a few companies came before us and laid such a great foundation of what it looks like to have remote asynchronous companies, you know, GitLab publish their, their handbook and Basecamp did as well. And so we see ourselves as peers and participants in this process of, you know, "What is the future of engineering organizations? Like, what does [00:36:00] that look like? And what does it look like at different scales and these kinds of things?" So in many ways, to me, it's incredibly exciting. Like, "What, what are the next things?" And I think in many ways we've pushed the ball forward in terms of transparency. And, and so I feel really good about that. We'll see, like we'll, see what changes and like what, what breaks and, and that sort of thing.

Eiso: I think that's fantastic words to leave this on today, Andrew. And it also sounds like we, we need you back in a year from now for an episode on what has broken and what have you learned?" I, I really appreciate 

this. Thank you so much.

Jason: This is great. A lot of fun to have 

you on. 

Andrew: Yeah. Fantastic. I, I enjoyed chatting with both of [00:37:00] you.