What my Tech Startup Learned Delivering Aid in Puerto Rico

Contributor: Joel Ifill is the founder of DASH Systems. Drone enthusiast and package thrower. He resides in Los Angeles and may be reached by e-mail or twitter

After landfall of Hurricane Maria I kept myself updated about the dire situation in Puerto Rico.A terrible story was unfolding: a growing humanitarian crisis marred by logistics challenges to an island with heavily damaged infrastructure. Rather than sitting there wishing we could help, we were poised to contribute. Our startup had been working in “stealth” on Direct Air SHipping technology. Simply put, we throw packages out of cargo airplanes and they land accurately at a designated location by use of a one-way low cost delivery “drone”. This is similar technology as military air drops, but with the intention of delivering packages commercially.

As the cogs start turning in your mind, you can see the applications for this technology. We can deliver anywhere a plane can over fly, we aren’t enslaved to airportswhich allows deliveries in remote and hard to reach areas. Puerto Rico was finding itself with a growing list of areas cut off, hospitals running out of fuel for generators and towns in need of water, food and basic supplies. The military and aid communities came together but the demand was much greater than any one organization’s ability to deliver.

We asked ourselves why couldn’t we use our air to ground delivery experience to deliver humanitarian aid to Puerto Rico? We had been proactively engaged with the FAA to perform civilian air drops in a legal and safe manner an issue that is plaguing many other “Drone delivery” technologies. With that question in hand I told my team that I would spend one hour until I was given a hard no, then two hours, then four hours, and next thing I was booking flights to Puerto Rico to setup air drops into Las Marias and Utuado. Two particularly hard hit mountainous districts southwest of San Juan.

Our deliveries were performed safely and successfully; this effort would not have been possible without a mountain of volunteers, aid partners and an air cargo company willing to trust us to convert their planes and supply amazingly pilots. However, this is not a story about congratulating ourselves on a job well done. Instead this is advice to technologists like myself looking to apply high tech solutions for high impact and complex problems.

Technology is amazing; from vaccines to the internet it has fundamentally transformed society and changed our lives. However technology in the land of lean startups and crowd funding is also finicky, expensive, slow to develop and many times ends up being a cool and exciting over engineered solution for a problem that doesn’t need technology to fix. Solutionism is an accusationoften levied at Silicon Valley. Christine Emba said it best,

Their CEO’s statement is a prime example of solipsism masquerading as benevolence, and a self-regard that makes it easy for those who think they have all the answers to avoid discussing actual problems and useful solutions.

Engineers and technologists (like myself) are often prone to seeking technical solutions to all problems. An app a day keeps the doctor away if you are involved in startups, are an inventor, or in the tech ecosphere. Below are some of my thoughts and lessons learned on evaluating technical solutions beforeyou hop on a flight and fly into an active crisis zone.

Know Your Technical Limits

…there are also unknown unknowns — the ones we don’t know we don’t know. And if one looks throughout the history of our country and other free countries, it is the latter category that tend to be the difficult ones. — Donald Rumsefield

Every technology has a technical limitation or trade-off; depending on a plurality of reasons these unknown unknowns may be more or less apparent. For example, I have this great idea for commuter a transportation technology: it is 100% legal and fits on today’s roads while taking less than 1/3rd the resources to manufacture as a passenger car. It can get up to 90 MPG and hold up to two commuters. I can make it with existing factories and manufacturing techniques for a few thousand dollars total shipped cost. If this technology sounds amazing, or too good to be true, I just described a motorcycle!

“Why don’t you ride one to work?”

Now, in your head you have a list of every reason why you never would ride a motorcycle for your daily commute. We went from an exciting list of quantified benefits with unknown unknown negatives, to known unknown negatives. These are all the negative assumptions, biases and justifications we have for never riding a motorcycle. Your technology has the same biases and negative assumptions but the more cutting edge and new it is, the more unknown unknowns you have not discovered.

Some of those known unknowns are addressable with more technical solutions($$) or behavioral solutions (wear a helmet and jacket). Whatever the solution, each brings a whole new set of assumptions and blind spots. The more unknown unknowns and the more behavioral changes you have to make the slower and more expensive adoption will be. You as an inventor may be comfortable riding a motorcycle in January, and are used to wearing a jacket, you’ve had a year to develop the motorcycle and love riding it. However it’s going to be difficult to push this change onto a public expecting the conveniences and comforts of a car, no matter the quantitative benefits in cost savings.
Lesson #1:

Substitutional Technologies require more education and awareness to overcome inherent biases in how we expect things should be done.

What We learned: We knew how to throw things out of airplanes in fact 100% of items have eventually landed on the ground. What is hard is anticipating all the customer concerns, demands, expectations and biases for what civilian air drops should be. In Puerto Rico how do you perform deliveries into areas with no power, no cell phones, no internet, no air traffic control, limited weather data, high winds, and land into places that take days to reach by Jeep? How do you do this all safely, and legally? We learned to appreciate and except corner cases and address concerns technically and procedurally before we ever planned to take off. In controlled environments on a sunny day with no wind it’s easy to line up a delivery. In the real world we have to be able to perform in any and all combinations of adverse conditions to areas we couldn’t control.

It is of dire importance to pessimistically understand all your corner cases and operating parameters for your technology. Too many technologies have a limited application when taken outside of a demonstration environment. If you find yourself or your team dismissing concerns easily, or getting defensive about tech questions. Stop. Write down the concerns and appoint and advocate for the question. My co-founder and CTO often plays devils advocate and makes us thoroughly address corner cases much earlier in product development than most projects, a technique that gives us more robust final products with fewer expensive revisions to come to the same conclusion after being forced to adopt the changes.

Test Soon, Test Often

It’s one thing to have a prototype and claim at a ground breaking technology. It’s another to have fielded a ground breaking technology. The difference is often millions of dollars and multiple years full of caveats, lessons learned and expensive mistakes.

For many technologists it’s easy to get excited about a cool technology (Drone delivery) then double down on the bet (VC Funding) generate a lot of buzz (literal and figurative), high fives and “why didn’t I think of that’s” before you’ve ever done a single delivery via drone. The sooner you test, and test in real world situations you don’t control. The sooner you find out the caveats that surround any particular technology. For drone delivery, just like any automation technology you are applying rigid machine thinking and engineering to a very fluid world full of 1 in a million corner cases. If amazon patents (with perhaps the best patent art of all time) are any indication these problems while seemingly insignificant are crucial barriers to success.

What We Learned: Test often, test soon and receive buy-in from stake holders (those who use your tech) and gate keepers (decision makers and regulators). Going to Puerto Rico was a continuation of this process. This was a very real mission with very real players. Aid organizations with life saving supplies expecting time sensitive deliveries and aviators expecting their planes and operating licenses to remain unharmed. We could not baby the environment or brush off paperwork, we had to have paperwork signed and submitted to the FAA to perform drops. Paperwork that takes time. Be realistic with the demands and concerns of market space you work in, the technology development was much easier than getting permissions to fly from the FAA or social buy-in to fly over your grumpy neighbor’s house.

First Do No Harm

Medicine has a hippocratic oath, but technologists are woefully lacking a similar creed. John Tapelin and the tech industry taught us to move fast and break things. While first mover status and natural barriers to entry may be great formula for a startup, overselling and launching technology that is not ready can harm your long term perspectives, or worse be the death of you and your business. For every new technology there are real risks and real consequences of failure, from patient and customer data inadvertently being released, to customer outages or stop-work events. Perhaps the single question I find so many technologists fail to ask is “What is the failure rate and modes and what are the consequences for failure” from minor inconveniences, to catastrophic disaster. Each technology has different failure modes that are rarely discussed openly by technologists. The more expensive or high risk the failure mode, the greater the benefit needs to be. Autonomous delivery is an amazing proposal, but will go down in flames faster than the Hindenburg if the public loses trust when an autonomous drone crashes into a daycare.

What We learned: Initially our biggest concern was safety during every step of the process for all players. This safety was addressed technically and with training and procedures before any package was dropped. The next question asked is what does failure mean if we couldn’t deliver at all? It’s one thing for your UPS package to arrive a day late, it’s another to tie up precious humanitarian resources in the middle of a natural disaster. Often it’s easy to oversell a technical solution, without regard to what failure or inability to perform means. We had to make sure we could guarantee a delivery before we took off as the cost of failing would have been wasted resources and a betrayal to the people on the ground. To help map out failures we used “Process Failure Modes Effects Analysis” or PFMEA a free tool that can be performed in excel. This technique to help inform engineering design decisions and what features need more time or more robust solutions.

People Pay for Solutions Not for Technology

Perhaps the most obvious and least obvious is that technology and fancy technology very rarely drives a purchasing decision, or won’t lead to long term adoption.

We pay for solutions to pain points. Instead of building a better mouse trap, ask the question what are the solutions people are willing to pay for having no mice in the house? When questions are framed around the pain point many solutions become available that are not always technical in nature. Having spent a career in engineering working in factories I’ve seen many factory modernization efforts fail as the underlying root cause was organizational or procedural rigor; hundreds of thousands into barcode scanners or RFID scanning systems won’t help if people aren’t rigorously maintaining inventory, and hardware won’t magically solve this problem if no one is held accountable for not using the system properly.

Often times technology is a solution, better than the gold standard, but the barriers to entry, development cost, and training and education make the calculus a losing formula over process and behavioral changes. Simply put, a new dewey decimal system won’t solve for people not putting library books away. If your taking credit for solving organizational or process pain problems be careful that adoption rate will be slow and results will be muddled if customers are unwilling to commit to process changes. Also be aware that process and behavioral changes are much harder to sell and may turn key stakeholders or advocates into barriers for success.

What We Learned: While we have exciting and interesting technology for delivering items from planes we found the single biggest pain point was customers who were intimidated or unfamiliar with coordinating air logistics. Overtime our pitch and branding changed from “drone delivery startup” to “enabling air cargo deliveries anywhere in the world”. While the underlying technology never changed and we still do perform civilian air drops the key pain point was smooth and fast coordination of deliveries in remote areas, not the specifics of how we performed the delivery.

Also we learned our ask was big for those who owned the airplanes we fly on, yes we make them a lot of money, but we are asking them to change the process of how they use multi-million dollar planes. We had to provide more training and education and evidence of success before they were willing to sign onto an operation that could risk their operating licenses.

As an end we learned customers don’t care if you package is delivered by drone, bike or airplane, they just want a package fast and safe at an acceptable price. Technology needed to be seamless part of the solution not a flashy showcase of what is possible to do with cutting edge engineering.

Closing Thoughts

Technology is the cornerstone of modern society and has fundamentally solved and changed the way we live. Problems that were once thought impossible are being solved and tackled with new tools. However awesome tech does not make a viable business or necessarily save the day. As a technologist it is easy to get excited about the possibilities of what you could do with a new invention and hard to face the realities of the barriers and feasibility of using that technology in the real world.

Optimism is an amazing human trait and as an entrepreneur or inventor you must be simultaneously optimistic and skeptical of your solutions. Before you hop on your plane to your disaster zone think critically and holistically about the non technical impacts your solution brings and the risks it exposes. Air to ground delivery has been technically possible to develop, getting acceptance of throwing life saving aid out of airplanes has been harder.

Joel Ifill is the founder of DASH Systems. Drone enthusiast and package thrower. He resides in Los Angeles and may be reached by e-mail or twitter