#112 – Agility & velocity when it comes to product development (Dan Summers & Ben Grynol)

Levels Head of Growth, Ben Grynol, chatted with one of our newest Levels team members, Dan Summers, to hear about Dan’s previous experience as an aerospace engineer at SpaceX, what brought him to Levels and why our mission is important to him.

When it comes to space exploration, even the smallest oversights can have major consequences. You have to find a delicate balance between risk mitigation and pushing forward to the next big discovery. In this episode, Levels Head of Growth Ben Grynol chatted with one of our newest Levels team members, Dan Summers, to hear about Dan’s previous experience as an aerospace engineer at SpaceX, what brought him to Levels, and why our mission is important to him.

14:05 – The power of alignment

If people are aligned with one another and everyone is invested in the same mission, your company can get a lot more done.

What actually was most apparent to me when I first started was just everybody was invested in the mission. It was like everybody believed that what we were doing was not only good for them as individuals, but good for society. Like we were taking society and moving it forward. And that drove this just massive alignment across the organization where everybody felt connected to the mission and felt connected as a team. And it was a very empowering type culture where if you had an idea, there was nothing really standing in your way of going out and executing it. And so this was quite different from GE, which was much more structured, much more mature from a organization standpoint. Their product development life cycles are 25 to 30 years typically, where SpaceX, we were designing and building new vehicles in month timeframes and seeing the fruits of that iterative cycle very quickly. And so it was just like a shackles-off environment at SpaceX.

15:20 – The value of structure

It’s important to have boundaries for teams to work within, but it’s also important to give people the freedom to explore new possibilities.

My time at GE taught me what the value of structure is and the importance of having boundaries that teams can work within. And that paid dividends for me at SpaceX. It prepared me to be able to be really effective in an environment where the shackles were off. Because I could help provide that structure and paint a future state picture where we could put more controls in place without necessarily driving bureaucracy into the system. So I leaned into that heavily in my first few years and just segued that into a few different jobs that I took within the company. And eventually that helped me get into the Raptor development program.

21:29 – You can’t replace time

The most important metric is time. No matter how much money you have, if you’re moving slowly, you probably aren’t going to win.

I think the most important metric is time, and the value of time you can’t replace it. No matter how much money you have, if you’re moving really slowly and you’re not learning quickly, then you’re probably not winning. And winning can mean many different things, but at the end of the day, specifically in the environment like at SpaceX where you’re developing a physical product, it’s really important to push the boundaries of your requirements early on and just try to continuously flush out what is a real requirement from a fuzzy requirement and make those learnings and that iteration process as fast as possible. And that is actually significantly cheaper. It yields a better design faster, and ultimately can be the difference between success and failure, where you can get in the alternative environment where you have a very kind of structured, rigid process for development. You can get stuck in these analysis paralysis situations where you think you know what your constraints are. And so you’re continuously bouncing between those constraints when in reality, maybe that’s not the case. And until you test it, you can’t figure that out.

24:19 – Assess from the bottom up

Have a good understanding of the basics of your product’s development. That way, you’ll be better able to complete the end product.

I think what it boils down to is, you have to take a first principal’s approach to product development and really assess from a bottom up standpoint. What is this thing going to take to design? What are the steps involved? What is going to be involved in prototyping and building? What is going to be involved in testing? What are all of the distinct criteria that you need to capture in order to feel good about getting to that first prototype? Whether or not it’s an engine on a test stand or a small subscale portion of the vehicle doing vibrational structures testing or whatever. And just making sure that you have a good understanding of that, such that you can then go and one, talk about it and make sure that whoever you need approval from to move forward understands what is going into all of your assumptions. And then, more importantly, challenging your own assumptions to delete those steps where possible, and making sure that you’re not just getting comfortable with the idea of being able to test something, but that you’re thinking through what are the fundamental constraints that maybe would mean that you don’t have to test something as rigorously early on. You can maybe take a risk on testing it farther downstream.

28:25 – There’s always room for improvement

You will never reach a place of perfection with any process. There’s always room to make things better, smoother, and faster.

I think it’s counterintuitive to think, “Well, my job is to optimize processes, to make them go faster.” But I’m actually not doing my job well, if I’m optimizing things that shouldn’t exist. And so if I’m not challenging my own requirements that are being handed down, either to me or developed by me, then I’m wasting my time and time is the most valuable resource. So that’s the roadmap, is run that algorithm and then run it again every single day. And you may get to a point where it’s like, “Okay, cool. I feel really good. I’m comfortable with this process or this product.” And then run it again, because you can never get to a point where you’ve reached a place where something is going to be perfect. There’s always going to be ways to improve it. And it may not be as dramatic, like order of magnitude improvement, but then maybe you need to take one layer or one step back and think about, “Okay, well, for all of these processes that I’ve hit the wall with, or these parts that I’ve hit the wall with, how can I just combine these parts or delete some of these parts?” And that at the end of the day is definitely a big factor in how quickly SpaceX is able to move.

30:54 – Delete unnecessary steps

Don’t spend all your time trying to improve steps that will eventually become unnecessary. Try to remove them first so you don’t waste valuable man hours.

Most companies, whether or not they’re developing hardware or software or something in between, run that process backwards. It’s like, “Well, we need to automate this process because it’s slow and it exists.” And so they do that and then they try to make it faster. If it’s robotic automation, they try to make the robots move faster. So they do the acceleration step and then they’re like, “All right, well maybe we can optimize portions of the quality requirements to do fewer of the steps.” Then they do that. And then they’re like, “Well, maybe we just don’t need this step at all.” Then they end up deleting it, and they’ve spent cash on all of the capital involved in moving from point a to point B, when in reality they moved from point Z to point Q in the process.

32:36 – There’s always risk

No matter how much risk mitigation you attempt, exploring something new will always come with some risk.

Space flight is a risky business. You start from that acknowledgment. And just understanding that what you are doing does not come at low risk or for free. And there’s always going to be variables that you don’t think of that could bite you, which is essentially what he’s referring to, where no matter how much risk mitigation you try to build into your operation, there’s just no way to eliminate all risk. Especially when you have a product that is built by humans. There’s the human factor, and trying to control human factor is just very difficult. So I think in general, when I first joined SpaceX in 2015, we had those two anomalies, it was a wake up call for the company that we did need to implement more of that risk management and risk mitigation structure.

34:23 – Find a balance

You have to find a balance between being cautious and breaking into new territory. You don’t want to be reckless, but you also don’t want to get left behind.

There was an acknowledgment, I think, coming out of 2015’s anomaly and into 2016 that everybody knew we needed to mature our quality system, we needed to mature our overall operational rigor around reliability. But we also didn’t want to lose what made SpaceX so great, which was the ability to make changes quickly to feed those changes back into our design and to make the product better. And so it was a fine balancing act. And I think we moved on either side of the line many times over those subsequent few years, where we implemented probably too many controls at too many levels of the process. And then we had to move back and this was pre algorithm days, or at least before the algorithm really existed in any organized fashion. But then I had to move back and reassess, because we had a few years where it was like, “Okay, it’s taking us longer to recover than we wanted, and longer to ramp up production than we wanted.” And I think the key was letting people work together and trust each other to come up with creative solutions to those problems, and reprioritize at the top level that reliability was something that we couldn’t ever trade, and that it needed to be the first lens that the company took with regards to Falcon-9 and Merlin and Dragon.

42:04 – Chart the path forward

Dan is eager to help people understand on an individual level how different biomarkers respond to the choices people make every day.

I think the whole concept of biological observability and really understanding on an individual level how different biomarkers in your body are responding to the choices that you make every day, putting more definition and color to that is something I’m really excited about doing and just helping to chart the path forward for what that means. And in a regulated industry, how we can help support research and development of that next generation of healthcare technology that will help people live better and just more happy lives. I think that’s the long term goal and what I’m most excited about supporting.

Dan Summers (00:06):

It’s counterintuitive to think of like, “Well, my job is to optimize processes, to make them go faster, but I’m actually not doing my job well, if I’m optimizing things that shouldn’t exist. And so if I’m not challenging my own requirements that are being handed down, either to me or developed by me, then I’m wasting my time and time is the most valuable resource.” So that’s the roadmap, is run that algorithm and then run it again every single day.

Ben Grynol (00:45):

I’m Ben Grynol part of the early startup team here at Levels. We’re building tech that helps people to understand their metabolic health. And this is your front row seat to everything we do. This is a whole new level.

Ben Grynol (01:11):

We often do these team member episodes, sometimes they’re thought leader pieces and other times they’re really just spotlights, people’s past experience, where they came from, what they’re interested in and why they join levels. We’ve done these time and time again. Well, this episode falls into the ladder. It was very much about Dan summers and his experience at SpaceX, all of his fascination, all of the learnings that he had as an aerospace engineer, some of the takeaways in working in an environment focused on speed, agility, and execution.

Ben Grynol (01:42):

It was really cool to dig into some of the history of SpaceX and if you’re fascinated by things like aerospace, this episode is probably one you’ll enjoy. We didn’t get much into metabolic health, but we did talk about what it’s like to be part of a mission driven company and why that is analogous to what we’re working on at Levels. It’s very much the reason that Dan decided to move on from SpaceX and join what we’re doing. There’s a lot of work ahead and we’re very excited to have Dan as part of the team. Here’s where we kick things off. Let’s jump all the way back. You’ve got an interesting path to becoming an engineer because it wasn’t something that you thought you were going to get into in the first place.

Dan Summers (02:25):

Yeah, yeah. I was in high school taking physics classes and just in general, that was my first real experience thinking deeply about how stuff works and was generally very interested in airplanes and how they’re able to stay in the air. And the more I learned about it, the more I became interested in engineering as a function. But my really primary passion at that point in my life was biology and the human body. At the time I was playing ice hockey and helping one of my coaches who was a PhD student at UNC Chapel Hill run a study on concussions and youth hockey players. And so we had outfitted my youth hockey team with these helmets that had accelerometers in them that essentially enabled us to measure the force impact on players’ heads as they were playing.

Dan Summers (03:20):

So I helped him run that study and analyzed all of his data and came up with this number that was in the 35 to 45 mile per hour ballpark of a common hit in a youth hockey game, is getting hit by a 35 mile per hour car in the head. And that was with the helmet. So that led me to apply to mostly just pre med type undergrad. And one thing led to another and I ended up going to NC state for aerospace engineering.

Ben Grynol (04:00):

So you ended up working as an eng out of school before going, you recently were part of the team, one of the world’s best operational training grounds SpaceX. But before that, what did it look like when you went out of school?

Dan Summers (04:16):

Yeah, I was in school, similar to my kind of high school… I don’t want to call it maybe blindness or naiveness, but I was in school for engineering and I was just assuming that, “Okay, I’m an engineer, I’m going to design stuff. And that’s what my life and career is going to be.” And it wasn’t until I took my first co-op with GE Aviation in Durham, North Carolina, that I got to experience production environment where things were being built. And that opened a whole new world, an avenue for me, where I discovered that you can be an engineer and apply your degree in a way that you contribute to making things and working with people. That was very appealing to me, and so I did a couple co-ops with GE when I was still in school and translated that into a leadership development program.

Dan Summers (05:10):

Once I had graduated, which was really awesome, I got to move around every six months for two years and perform four different functional roles within GEs supply chain. And just for context, the GE Aviation makes commercial military jet engines. So I got to see multitude of different shops within their supply chain organization, working in electronics and avionics, to final assembly of the engines, to working with customers on quality specific functions, to leading a team on second shift in Wilmington, North Carolina. So I was on an island managing a group of hourly machinists, and that was an experience in and of itself. I did that for two years and then rolled off program into Boston, Massachusetts. They have a facility just north of Boston and Lynn, Mass., and spent the next year and a half as a manufacturing quality engineer before eventually transitioning out to California in 2015 to work at SpaceX.

Ben Grynol (06:28):

Yeah. So you were on the east coast and you hopped across the country. What did that look like? How did the whole SpaceX thing come about? You’re now our second team member with SpaceX tenure, you and Josh Clemente, and you led propulsion there.

Dan Summers (06:47):

Yeah, I eventually worked my way through different elements of the company and was responsible for a propulsion engineering team on the Raptor program. But my initial transition out west was… It was interesting. I was not necessarily looking for a new job at GE, but had been following SpaceX for a while. I watched their first flight to the ISS back in 2012, I think it was. And had been following really their first commercial launches since 2009, 2010, just through my schooling, I was studying aerospace engineering and we had a lot of interested parties at the university who were just really intrigued by the concept of commercial space flight.

Dan Summers (07:42):

And SpaceX was one of a few different companies that was really pushing the envelope on that. I’ve been following them for a while. I’d applied for an internship with them when I was in school and didn’t hear anything back and then had poked around on their job site a few times in the past, but never really aggressively went after that. But I was sitting in a conference room during one of our morning standups in GE in Lynn and got this LinkedIn notification from a recruiter who asked me if I’d be interested in learning more about SpaceX and the role. And it was a no brainer and that it happened real quick after that. Within probably a month I was moving to California and a month later, my wife joined who at the time we were just boyfriend, girlfriend.

Ben Grynol (08:33):

Very cool. And what was it like? Josh has shared a bunch of stories, anecdotal stories, and we can read about stories, but you worked in it, you lived in it. What was that environment like? You’re around a group of people that are doing something that seems impossible and it’s specific in every endeavor, you’re putting things into the air with a high probability of them not working out, like the chance of the rocket blowing up. Well, it’s not probably not going to happen, it happens all the time and the timeline to put rockets into the air, it’s not quick. It’s not like, “Well, we’ll just fix that and do it tomorrow.” Things have such a long lead time. What did the environment feel like as far as pace and energy and mission? Just all these things that from an outside perspective, people would love a fly on the wall.

Dan Summers (09:27):

Yeah.

Ben Grynol (09:28):

Yeah. Look at.

Dan Summers (09:29):

So the day after I accepted my offer was the flight of CRS-7. And so I had just accepted my offer, had told all of my friends and family to tune in to this launch. And there was a mission failure in that mission, just after the most strenuous point of stage one flight. So the vehicle exploded midair. My initial thought was, “Oh man, do I still have an offer? Is this going to significantly impact the company in a way in which maybe they’re not going to continue to give me this job?” Luckily that wasn’t the case. There was no doubt from their communication to me and things proceeded. But for the first six months that I was there, we weren’t launching anything. We were in a recovery mode from essentially trying to identify what the root cause of the failure was and make sure that we had corrective actions in place.

Dan Summers (10:35):

And my role that I was joining as a supplier quality engineer was right in the thick of the investigation because the parts that had failed were vendor purchase parts. And they didn’t fail because of the fact that they were supplied from an external source, but they failed because our quality control system did not adequately screen for this condition that we didn’t necessarily think was that important at the time. It was a pretty minuscule nonfunctional part that is usually an afterthought. And that afterthought clearly bit us. But so my first six months it’s like… We weren’t launching. And then the first launch was December 21st of that year, 2015. And it was the first time that we landed a Falcon 9 booster first stage. So this was like the culmination of a few years worth of work in trying to prove that booster re usability can be possible.

Dan Summers (11:43):

You can land an orbital class booster either back on land or on a drone ship successfully. And so that worked. And it was just this euphoria of not only are we returning to flight from an anomaly, but we had landed the booster. So that was representative of my first few years there, where it was just these massive swings of… You have this euphoric milestone where the entire company is just locked in like a laser on making sure that we’re successful to the best of our ability. And then these peaks and valleys, and the valleys being, we had another anomaly the next year. September of 2016, we blew up AMO-6 on the pad. And this was a much more significant failure from a visibility standpoint because it was on the ground. The vehicle was still on the ground, so there was cameras all over it.

Dan Summers (12:48):

It was a massive explosion, blew up our entire pad. And that’s not to say that CRS-7 wasn’t a big black eye for the company because it was a NASA mission. So NASA, obviously they don’t like to lose cargo. We don’t like to lose cargo, but it was a big deal for us being their launch services provider that we essentially failed them on that. But AMO-6, took that to another degree because it was just this visibly terrible event. And so the roller coaster ride of emotions, just in that first few years of trying to both recover from an anomaly and also just achieving great success between those two anomalies we landed on land multiple times, we landed on a drone ship for the first time, which if I had to describe that in any way, it would be like throwing a pencil off of the Eiffel tower and landing it on a Coke can standing up.

Dan Summers (13:48):

That’s, I think, the best way you can think about what it’s like to land a normal class booster, hundreds of miles down range on a boat in the middle of the ocean and actually successfully recover that booster. So what actually was most apparent to me when I first started was just everybody was invested in the mission. It was like everybody believed that what we were doing was not only good for them as individuals, but good for society. Like we were taking society and moving it forward. And that drove this just massive alignment across the organization where everybody felt connected to the mission and felt connected as a team. And it was a very empowering type culture where if you had an idea, there was nothing really standing in your way of going out and executing it. And so this was quite different from GE, which was much more structured, much more mature from a organization standpoint. Their product development life cycles are 25 to 30 years typically, where SpaceX, we were designing and building new vehicles in month timeframes and seeing the fruits of that iterative cycle very quickly.

Dan Summers (15:14):

And so it was just like a shackles off environment at SpaceX, and with that said, my time at GE taught me what the value of structure is and the importance of having boundaries that teams can work within. And that paid dividends for me at SpaceX, it prepared me to be able to be really effective in an environment where the shackles were off. Because I could help provide that structure and paint a future state picture where we could put more controls in place without necessarily driving bureaucracy into the system. So I leaned into that heavily in my first few years and just segued that into a few different jobs that I took within the company. And eventually that helped me get into the Raptor development program.

Ben Grynol (16:08):

Yeah, it’s wild. I would imagine the energy would be infectious because A, SpaceX is a very publicly visible company, there’s just so much visibility on what’s going on. B, there’s so much oscillation in what has happened. Like early days trying to get past stage one, and just like over and over and over, it’s like it’s not happening. And then to do something that is pushing what’s possible on behalf of humankind, let’s call it that. Maybe it’s a little philosophical, but the idea of landing or putting an object up into the air and being able to land it back down and I’m speaking very colloquially about it. It’s like, nevermind, we start to go into like, well, what is that? It’s like a rocket versus a tennis ball, very different. But that is a mind boggling thing to think about, full stop.

Ben Grynol (17:02):

And so to go through all these things. And it sounds like when you first joined and you got to experience some of this energy and it’s like, “We can go” and again, you have the valley of “Oh man, we had a very public failure.” And it had to do with our mains revenue stream, which is like contracts from NASA and there’s cargo and, and, and. I would imagine that energy oscillates as a team, and you’re playing this long game of trying to get on a mission. So then it gets back to what you were saying about having enough structure versus being unstructured enough.

Ben Grynol (17:40):

It is a complete dichotomy between the two thoughts, because you need to have this environment where it’s like, “You can go do anything, no one’s stopping you.” But just enough structure so that it’s like, “We’re going to do the right things to mitigate against any potential downside risk when we’re doing these major, major things.” And from an economic standpoint, when there is an adverse event, it’s not like, “Well that costs us $10 bucks.” It is just so expensive in time and capital and all of these things. So what a cool experience to go through though.

Dan Summers (18:15):

Yeah. The ultimate mission at SpaceX is to make life multi-planetary and then the way that’s achieved is by making the cost of space flight less. So driving the cost of getting to orbit down. And then the vision for that, it’s like, “Okay, well, how do you do that?” That’s a very opaque, difficult problem to solve and our tangible method for solving that problem was re usability. And it was all founded in the idea of… And you’ve probably heard Elon say this multiple times, if you’ve ever listened to him talk about SpaceX is just, if you fly on an airplane and at the end of your airplane ride you have to throw out the airplane, it would be so expensive to fly that nobody would ever do it. And that’s the exact same concept. Up until we landed Falcon-9, these vehicles just burn up on reentry or they splash down in bits and pieces in the ocean.

Dan Summers (19:16):

So your multimillion dollar investment in this hardware just disappears six minutes after you take off from the ground, roughly. It’s like the life of the vehicle to get to orbit is roughly that. It’s just sad to think about, it’s like, “Man, there’s a lot of great engineering that goes into building launch vehicles. We should try to capitalize on that.” And with Falcon-9, we were able to recover the first stage effectively, which includes all the first stage propulsion with the Merlin engines and propulsion systems. And then eventually it got to the point where we were recovering the payload fairings and recovering and reusing Dragon, both cargo and crew vehicles. But the architecture of that vehicle is limiting in the sense that the second stage is not recoverable. So that’s where Starship and Raptor come in, where Starship is a fully reusable two stage vehicle that will dramatically change the way people view space flight. You’ll be able to go to orbit, like you can go get on a plane at LAX in the future and it will be because Starship exists.

Ben Grynol (20:31):

Yeah. It’s so funny that traditionally, before SpaceX, we just accepted that. It was like, “Oh, it’s okay. That’s just what we do. We just launch rockets and they are gone forever. There’s no need to land them.” But using the plane analogy, it’s entirely true. It would be the most absurd thing, people would think, “Hey, you drive your car and then you can’t use it again forever. It’s a one way ticket on that type of vehicle.” So you worked in these two completely opposed organizations. One that was driven by process and a little bit more red tape. And just generalizing based on GE is a legacy company, there’s a lot of history. And then this other one that’s focused on speed, experimentation, execution. What are some of the takeaways that you learned from SpaceX when it comes to things like velocity, agility, really thinking through how you approach problem solving?

Dan Summers (21:29):

Yeah. I think the most important metric is time, and the value of time you can’t replace it. No matter how much money you have, if you’re moving really slowly and you’re not learning quickly, then you’re probably not winning. And winning can mean many different things, but at the end of the day, specifically in the environment like at SpaceX where you’re developing a physical product, it’s really important to push the boundaries of your requirements early on and just try to continuously flush out what is a real requirement from a fuzzy requirement and make those learnings and that iteration process as fast as possible. And that is actually significantly cheaper. It yields a better design faster, and ultimately can be the difference between success and failure, where you can get in the alternative environment where you have a very kind of structured, rigid process for development. You can get stuck in these analysis paralysis situations where you think you know what your constraints are. And so you’re continuously bouncing between those constraints when in reality, maybe that’s not the case. And until you test it, you can’t figure that out.

Ben Grynol (22:56):

When thinking about time, how do you think about it? Because time is actually subjective. Time as a… We’re just going to use a word like time. One person’s view of what is fast can be completely different. Let’s use GE in SpaceX. GE, the sense of time might be like, “Oh, we’re moving really fast, the timeline is two years.” That is fast. And then SpaceX might be, “Time, seven minutes. You’re allowed seven minutes on this thing.” How do you think about time given that it’s subjective? We all have a different bias towards like what means fast. So what’s your subjective lens on it? Or was there a generalized lens that everyone at SpaceX had on what time meant?

Dan Summers (23:50):

There was definitely a… I would say somewhat of a disparity between a timeframe that an individual or a team would come up with for their own project. And then the timeframe that company leadership would want us to achieve those milestones within.

Ben Grynol (24:08):

Which was faster?

Dan Summers (24:10):

Always the leadership pushing the timeframe in and trying to be more aggressive. And I think what it boils down to is, you have to take a first principal’s approach to product development and really assess from a bottom up standpoint. What is this thing going to take to design? What are the steps involved? What is going to be involved in prototyping and building? What is going to be involved in testing? What are all of the distinct criteria that you need to capture in order to feel good about getting to that first prototype? Whether or not it’s an engine on a test stand or a small subscale portion of the vehicle doing vibrational structures testing or whatever. And just making sure that you have a good understanding of that, such that you can then go and one, talk about it and make sure that whoever you need approval from to move forward, understands what is going into all of your assumptions.

Dan Summers (25:18):

And then, more importantly, challenging your own assumptions to delete those steps where possible, and making sure that you’re not just getting comfortable with the idea of being able to test something, but that you’re thinking through what are the fundamental constraints that maybe would mean that you don’t have to test something as rigorously early on. You can maybe take a risk on testing it farther downstream. So I would say time while subjective is there are physics based ways to bound time. And those ways don’t necessarily always align with every other team that may be working in parallel on different systems or whatever. But it’s generally the best way that I’ve found to remove that subjectivity and make it such that somebody who doesn’t know anything about the project can understand it.

Ben Grynol (26:17):

There’s the classic adage of the worst possible thing that a team or a person could do, if you’re an engineer, is optimize something that shouldn’t be there in the first place. So it’s the idea of spending all of this time… Sam sometimes uses the term bike shedding, where it’s like talking about things that shouldn’t be there. Or I know one, I can’t remember which vehicle it was, but Elon was talking about, there was a door that was going on the ship and he was like, “Man, we need to get to orbit, why is there a door on this thing?” It’s ridiculous. That’s bike shedding. So it’s easy to reduce scope when someone says, “Cool, you are on a team.” And the team says, “We can have this project done in a month,” and another person and another team might say, “Great, do it in a week.”

Ben Grynol (27:07):

How do you start to descope? Assume that you’ve got rid of the “door.” The door isn’t there to begin with, but you’ve descoped it. What are some of the things you do to move faster when somebody challenges speed and goes… There’s sort of this heuristic scope of project divided by 10, then divided by 10 again, and maybe try one more time, but it’s probably not possible, but to get to the path of least resistance of executing. So what are some of the things that you’ve done or you experienced when someone’s like, “Great love the timeline, but let’s cut, it by 10 factor of 10?”

Dan Summers (27:43):

Yeah. Yeah. You alluded to this. I’m sure that in that same conversation that Elon was talking about removing the door, he probably referenced the algorithm, which is the lifeblood of SpaceX’s and just Elon’s general philosophy on how to develop technology. That is essentially the means with which you can challenge requirements, delete and simplify aspects of your design or your product before you ever get to the portion that most engineers think is the most important, which is optimizing, accelerating and automating. And I think it’s counterintuitive to think of like, “Well, my job is to optimize processes, to make them go faster, but I’m actually not doing my job well, if I’m optimizing things that shouldn’t exist. And so if I’m not challenging my own requirements that are being handed down, either to me or developed by me, then I’m wasting my time and time is the most valuable resource.” So that’s the roadmap, is run that algorithm and then run it again every single day.

Dan Summers (29:01):

And you may get to a point where it’s like, “Okay, cool. I feel really good. I’m comfortable with this process or this product.” And then run it again, because you can never get to a point where you’ve reached a place where something is going to be perfect. There’s always going to be ways to improve it. And it may not be as dramatic, like order of magnitude improvement, but then maybe you need to take one layer or one step back and think about, “Okay, well, for all of these processes that I’ve hit the wall with, or these parts that I’ve hit the wall with, how can I just combine these parts or delete some of these parts?” And that at the end of the day is definitely a big factor in how quickly SpaceX is able to move.

Ben Grynol (29:47):

Yeah. I love that mental model. I think Elon talked about it in Everyday Astronaut multi-part series that went up a few months ago. But it was talking about all designs are wrong, it’s just a matter of how wrong exactly. Make your requirements less dumb because they’re definitely dumb no matter who gave them to you. And if they’re your own, they’re probably pretty dumb. And so you have to always poke holes in your own assumptions, get down to delete the part, delete the process, don’t optimize things that shouldn’t be there to begin with, and then increase cycle times. You can always go faster and then automate where you can, just keep automating out because it’s back to the idea of your own time. It’s like, how do you optimize your time? Well, to scale your time, automate as many things as possible.

Ben Grynol (30:33):

Everything starts out with a human touch and that’s not super efficient. So from a part standpoint or a process, how do you keep automating that? And then, how do you break that apart, blow it up and go, how do we make this better? Assume that it was dumb to begin with. So it’s just such a interesting way of thinking.

Dan Summers (30:54):

Most companies, whether or not they’re developing hardware or software or something in between, run that process backwards. It’s like, “Well, we need to automate this process because it’s slow and it exists.” And so they do that and then they try to make it faster. If it’s robotic automation, they try to make the robots move faster. So they do the acceleration step and then they’re like, “All right, well maybe we can optimize portions of the quality requirements to do fewer of the steps.” Then they do that. And then they’re like, “Well, maybe we just don’t need this step at all.” Then they end up deleting it, and they’ve spent cash on all of the capital involved in moving from point a to point B, when in reality they moved from point Z to point Q in the process.

Ben Grynol (31:42):

Totally. Did you see any pre-mortems? The reason I ask is that pre-mortems can be great, but there’s also this anecdote of… Elon had talked about it with some of the things that had happened from a risk standpoint. So it’s like, there’s pre-mortems pre-launch right there. They’re all of this list of risks associated with what might go wrong. Because you want to mitigate that as best as possible. But then he’s notorious for saying, “No matter how much we do these pre-mortems.” He’s like, “If something happens, if there’s a part that breaks, whatever, the vehicle blows up, it wasn’t on the list to begin with.” So what was your experience with doing pre-mortems and how effective they were, the exercise of it, your thought process on that and how that can carry into other companies like what we’re doing now?

Dan Summers (32:34):

Yeah. Yeah. Space flight is a risky business. Just you start from that acknowledgement. And just understanding that what you are doing does not come at low risk or for free. And there’s always going to be variables that you don’t think of that could bite you, which is essentially what he’s referring to, where no matter how much risk mitigation you try to build into your operation, there’s just no way to eliminate all risk. Especially when you have a product that is built by humans. There’s the human factor, and trying to control human factor is just very difficult. So I think in general, when I first joined SpaceX in 2015, we had those two anomalies, it was a wake up call for the company that we did need to implement more of that risk management and risk mitigation structure. Especially because at that point we were heavy into cargo launches for NASA.

Dan Summers (33:42):

We were trying to convince the Air Force that we were a worthy launch services provider, but we hadn’t done any Air Force or national security missions at that time. And we had the crew missions on the horizon multiple years out, but we had already won that contract to basically go and build crew Dragon. And so it was like, “Okay, everything that we’re doing now is in the lens of flying people.” You bring that factor into it and the intensity increases a hundredfold, where before you were just launching supplies essentially. And now you’re talking about launching moms and dads and fathers and sons, and it just becomes way more intense. And so there was an acknowledgement, I think, coming out of 2015’s anomaly and into 2016 that everybody knew we needed to mature our quality system, we needed to mature our overall operational rigor around reliability. But we also didn’t want to lose what made SpaceX so great, which was the ability to make changes quickly to feed those changes back into our design and to make the product better.

Dan Summers (34:53):

And so it was a fine balancing act. And I think we moved on either side of the line many times over those subsequent few years, where we implemented probably too many controls at too many levels of the process. And then we had to move back and this was pre algorithm days, or at least before the algorithm really existed in any organized fashion. But then I had to move back and reassess, because we had a few years where it was like, “Okay, it’s taking us longer to recover than we wanted, and longer to ramp up production than we wanted.” And I think the key was letting people work together and trust each other to come up with creative solutions to those problems, and reprioritize at the top level that reliability was something that we couldn’t ever trade, and that it needed to be the first lens that the company took with regards to Falcon-9 and Merlin and Dragon.

Dan Summers (36:07):

It wasn’t easy. I think it also required us to work really closely with our customers. And I think NASA in particular was one of the best at helping us understand what they were looking for. And then we ended up teaching NASA quite a bit just about how to reframe risk management in a way in which you can still achieve great things in a short amount of time and push the boundaries of technology. And now, NASA and SpaceX’s relationship is like this, they’re inseparable. We are their only launch services provider for humans and probably will be for the rest of this year, at least. I don’t know if any of the competitors will be ready to go with regards to the commercial crew or when they will be ready to go. But yeah, it’s like we start out from this really rigid regulatory landscape and you work with those regulators to peel back the onion and assess what is really important and then prove it. I think that’s the biggest thing.

Ben Grynol (37:17):

Yeah. It’s such a wild trajectory that SpaceX has been on for so many years. There’s so much history and a wild ride that you got to go through and experience all these things. And then, you went through all these things and eventually you made your way here. So you joined… Gosh, when was that? April now, you joined in January? March?

Dan Summers (37:41):

March.

Ben Grynol (37:41):

I have no idea. This seems like years already. So you joined, what was it that led you to say, “Okay, I’ve seen this, I’ve been a part of this, now I want to go and work on this other mission driven company?” How did you hear about Levels? Let’s walk into this whole, how did you hear about it? And then what was the catalyst that you’re like, “I want to join another mission driven company?” But the mission is totally different and totally unrelated to what you were working on before.

Dan Summers (38:10):

Yeah, for sure. Yeah. I heard about Levels initially through a family member who was wearing the product over Thanksgiving. And I was pretty curious just in general because I like my Apple Watch and in general being able to view health metrics on what’s going on in my body. And so it was like, “Okay, that’s not something I’d heard of before.” And I was pretty interested in the limitations of it and just what the value of it was. And it became somewhat of a let’s feed these different things over the course of Thanksgiving and see how his body reacts. And that was fun. And then I got connected with Sam at some point over the next few weeks and just learn more about what Levels is up to in terms of their mission and just the future of healthcare from their perspective, and really connected with it. And not only connected with that mission, but with the way that the company is operated and run and how they think about business operations from a transparency standpoint.

Dan Summers (39:16):

And just had the chance to learn more probably about Levels in a few month period than I did about really the ins and outs of the company at SpaceX over a few year period and albeit like completely different stage. But I eventually got to the point where I was ready to take that next step and take a new adventure on. And Levels was the most obvious choice because of the underlying mission of just trying to really take a different lens on the future of healthcare and what that means for an individual to be able to understand what is going on in their body without having to necessarily wait for a doctor to give them a PDF that means really nothing to them. So yeah, that’s kind of it.

Ben Grynol (40:08):

And the remote aspect I’d imagine too. You’re in the process of moving to Cinci, so that in itself, just having the ability to be… Because you’ve got a young family, you’re going to be closer to family, and that in itself is something that’s not possible with an in-person company.

Dan Summers (40:27):

For sure. Yeah. That was and will be a huge enabler to me being able to achieve a lot of my other personal goals in life, which is to get some more help with the kids around the house and have them closer to both my wife and as family in general. And not many companies operate like Levels in a completely remote function and combined with everything else, definitely a huge appeal to me.

Ben Grynol (40:57):

That’s very cool. And so your wife still at SpaceX? Maybe a future Leveler? We don’t really have a name for internal Levels’ team members yet.

Dan Summers (41:07):

She actually moved on as well into a fully remote role with a different startup.

Ben Grynol (41:16):

There you go. Life changes. They all happen at once. So knowing what you know now you’ve got this lens on experimentation, you’re getting ramped up, which I thought was years at the company and turns out to be a month. Forgive me for getting the timeline, but what are you looking forward to now that you’ve got this lens of running fast, experimenting quick, this lens of being really rigorous with all the experience with GE as far as process and then finding the happy middle ground, knowing that we’re in a heavily regulated industry, we’re in a space that we’re making an impact on people’s lives and there’s this mission behind it, but what are you looking forward to like moving forward when you start to think about Levels and the impact that you want to make?

Dan Summers (42:03):

Yeah. I think the whole concept of biological observability and really understanding on an individual level how different biomarkers in your body are responding to the choices that you make every day, putting more definition and color to that is something I’m really excited about doing and just helping to chart the path forward for what that means. And in a regulated industry, how we can help support research and development of that next generation of healthcare technology that will help people live better and just more happy lives. I think that’s the long term goal and what I’m most excited about supporting.