Hi, I’m Ken Dawson, CIO/CISO of ClearStar. Anybody who knows me will not be surprised by this, but I’m going to use a space company—SpaceX—and their recent successes to illustrate some lessons on agility. I spend a lot of my free time following the space industry, with a focus on SpaceX and other commercial companies like Blue Origin and Rocket Lab. When looking at what SpaceX has accomplished and how, a lot can be attributed to their agile approach and culture, which certainly seems to come from its founder—Elon Musk—whose other companies exhibit this trait as well.
Focus on the Main Thing
The most difficult aspect of staying agile for many of us is knowing what to focus on. The key is that we can’t be committed to a specific outcome or approach but must be able to define the properties of a successful implementation. It’s much easier and often more comfortable for us to pre-determine what we want a solution to look like, what features it should have, and what the best architecture is. If we want to be more agile in the way we deliver value to people, then we should instead be defining what the successful solution can accomplish, who will benefit from it, and what value it will provide.
An example of this is the recent Demo-2 mission where SpaceX, under a NASA contract and with their help and support, became the first commercial company to launch people into orbit and provided NASA with the first human launch to orbit from U.S. soil since 2011. This was a great accomplishment, but it’s worth noting that the Crew Dragon1 capsule that went to the International Space Station (ISS) was very different in some major ways from the original design.
The overall goal of safely delivering astronauts to the ISS and bringing them home safely (planned for some time in August) was the most important aspect of determining a successful capsule. The initial designs called for the capsule to land on land, pretty much anywhere, under the power of its on-board rockets. Well, at some point it was determined that while this was possible (concept proven out to some extent by their Falcon 9 landings), it was not going to be practical because the time, cost, and requirements of getting NASA to certify this new approach of returning astronauts safely to Earth were not worth the effort and were not required to meet the goal. So, they pivoted to parachutes and a water landing, both of which NASA had experience with, and moved forward keeping the overall goal in mind.
As it turns out, that design wasn’t wasted as SpaceX was able to make the necessary changes to use those rocket motors to power the launch escape systems. After the fact, it may be easy for all of us who are watching them to see the wisdom in this and recognize how it benefitted SpaceX and NASA, but I’m sure it wasn’t a fun decision and it made them rethink a lot of things that they had already planned on. This showed agility because they were willing to throw away their plans, approaches, and designs when needed to keep on track.
Failure is Good—If It Happens Fast
The next important aspect of being agile is to be more than just accepting of failure—but to encourage it. We want to be agile because we want to be innovative in some way, meaning we’re trying to do or build something in a way that is different than what has been tried before—all so we can be more successful in achieving our goals. A great quote from Elon Musk on this topic is, “If things are not failing, you are not innovating enough.”2 The key in this for agility is not that you fail, because you will if you’re trying to be innovative, but is how and why you fail.
If you’re not failing, it can mean that you’re either being too conservative in your approach—trying things that have already been done by others—or that you’re being careful in terms of how hard you push things. It can be frightening to think that we’re going to build things that we expect to fail, making us question the whole concept: What happens to our schedule, how much will it cost, and how do we know it will lead to a better solution? There are two keys to handling this uncertainty: speed and iteration. We don’t want to build full solutions and then push them to their limit. Our objective is to build the smallest independent unit we can, push it to the point of failure as quickly as possible, and then learn from the failure to build the next iteration. In this way, we minimize the risk and negative impact of the failure while maximizing our ability to make changes based on what we learn. This process of iterating based on what we learn doesn’t stop once a component or full product is completed but will continue for the life of the product.
The SpaceX Falcon 9 rocket is an excellent example of this approach. The entire rocket has changed in dramatic ways from v1.0 to the current Block 5 version (see a great article on this here). What I want to focus on is the landing and the changes to support it. The first two versions (depending on how you’re counting) didn’t have any hardware to support landing the rocket, even though reusability was a central goal to the Falcon 9 program. By version 1.1, SpaceX added landing legs and grid fins to allow the first attempts at landing and reuse. If you go to the article or search the web for “Falcon 9 versions images”, you’ll see various drawings and pictures that show the changes to the landing legs and grid fins across different versions. All of these came in the form of iterations based on failure—from spectacular misses (see YouTube) to landings that were shaky or off center to the double landing of two Falcon 9’s3. The one outcome that they all shared (even the successes) was that SpaceX learned from them and made improvements in the next builds and versions; they didn’t wait to redesign the whole thing from scratch.
Results
The whole point of focusing on agility is achieving results that drive our product and company forward, increasing revenue and profits, and just making the things we do better. If we focus on what defines a successful outcome, consider any and all potential changes on their merit, and use early failure to drive iteration and continuous improvement, we will be well on our way to using agility to drive the success of our organization. This is for the record.
1 https://commons.wikimedia.org/wiki/File:CCP_SpaceX_Demo-2_Dragon_(2).jpg
2 https://cleantechnica.com/2020/02/01/elon-musk-you-should-be-failing-if-things-are-not-failing-you-are-not-innovating-enough/
3 https://upload.wikimedia.org/wikipedia/commons/5/52/Falcon_Heavy_Side_Boosters_landing_on_LZ1_and_LZ2_-_2018_%2825254688767%29.jpg
For The Public Record is a monthly blog featuring thought leadership from the most seasoned experts at ClearStar, across all functions of the background screening process. Click here to subscribe.
Let's start a conversation
Ken Dawson - Chief Information Security Officer
Kenneth “Ken” Dawson is a founding member of ClearStar and currently serves as its Chief Information Security Officer. Ken is responsible for evaluating, designing, and implementing background check technology solutions that combine information from disparate information sources in varied data formats.
Before forming ClearStar, Ken developed enterprise systems for United Parcel Service (UPS) and Kaiser Permanente. Ken began his career in software development and content delivery in 1990 while working as an intern for Conatec, Inc., an aerospace engineering firm.
At ClearStar, we are committed to your success. An important part of your employment screening program involves compliance with various laws and regulations, which is why we are providing information regarding screening requirements in certain countries, region, etc. While we are happy to provide you with this information, it is your responsibility to comply with applicable laws and to understand how such information pertains to your employment screening program. The foregoing information is not offered as legal advice but is instead offered for informational purposes. ClearStar is not a law firm and does not offer legal advice and this communication does not form an attorney client relationship. The foregoing information is therefore not intended as a substitute for the legal advice of a lawyer knowledgeable of the user’s individual circumstances or to provide legal advice. ClearStar makes no assurances regarding the accuracy, completeness, or utility of the information contained in this publication. Legislative, regulatory and case law developments regularly impact on general research and this area is evolving rapidly. ClearStar expressly disclaim any warranties or responsibility or damages associated with or arising out of the information provided herein.
.jpg){kind=link}
