Last week, I had the pleasure of doing a podcast with Randall Cronk of the MIT Enterprise Forum (my alma mater) on the practicalities and challenges of using the Internet of Things (a.k.a. IoT) to solve real-world problems.
Here in an excerpt of some of the things (no pun intended) we discussed:
IoT is not just about talking toasters (or creepy monitoring), it can be use to solve many high-cost, real-world problems. We already have some clear analogies for this:
Commercialization of the World Wide Web (Internet 1.0) radically changed how we get information. Instead of waiting to get it physically (via mail or newspapers) we could get it instantly from our desktops
The mobile Internet, smartphones, mobile web and app stores (Web 2.0 or Internet 2.0). Let us take the convenience of this instantaneous access virtually anywhere. We no longer had to go back to our desks and could now look up info on street corner at a restaurant, etc.
The Internet of Things (Internet 3.0) takes this convenience to the next level. We no longer have to go look at things to see where they are, what state they are in, etc. We can find out without manual effort. This lets us focus on things we really care about (instead of the drudgery of getting information)
Of course, this is not a simple prospect. We have many challenges to solve. The most obvious are the ones around data connectivity and protocols (these challenges, however, are pretty straightforward). The next is privacy and security (we have models for these from regulated industries like banking, healthcare, and medicine). The next is how to handle all that information. If we do not solve this problem, connected things will swarm us with so much useless data that it will make our email inboxes look simple.
I originally posted a version of this on five years ago, on 40th Anniversary of the Apollo Moon landing. At that time, social media and smartphone were just starting to explode. Today, as social sharing and mobile are giving rise to IoT, these lessons from 1969 are perhaps even more important.
Putting things in perspective
It is easy to feel really proud of our accomplishments, whether we are scaling a consumer application a 1,000-fold in one year, rolling out a huge ERP program or even creating a new technology. However these accomplishments pale in comparison to what the Apollo, Gemini, and Mercury Missions achieved 45 years ago. Imagine this scenario:
You are listening to the radio and the President announces that the country is going to put a man on the Moon by the end of the decade. Keep in mind that no one has ever even escaped low earth orbit–let alone escaped Earth’s gravity, executed Holman transfers AND navigated to another body. Now you have to implement the largest engineering project in history, while inventing not only technologies, but also whole fields of study. All under the watch of the press—and all completed within one decade.
This is inconceivable to most of us in our work today. It is inspirational.
My lucky exposure to the people of Apollo
At the time I studied aerospace engineering at MIT, we were lucky enough to have several veterans of the Apollo Program on staff as our instructors. Not only were they great instructors; they also could recount first-hand experiences of events that the rest of us could only read about in the history books.
Joe is also considered by some a founder of the Systems Engineering profession (many consider him the greatest systems engineer who ever lived). This made him the perfect person to each the capstone class of the aerospace curriculum: Systems Engineering (Fred Wilson of USV has written a great post on how fun Systems Engineering is and how important it is for engineering leadership). Every year, he would get a project from NASA and guide his students through all aspects of design, simulation, planning and even cost analysis. Our midterms and finals were real-life presentations to the Administrator of NASA.
Under Joe, I got to work on something called “Project Phoenix,” returning to the moon—but now with a re-usable capsule and landing four astronauts at the pole and keeping there for 30 days (a much harder prospect). In this project I learned about everything from active risk management to critical path costing to lifting bodies to Class-E solar flares. (How cool was that for a 20-year-old?)
Life lessons I learned from Joe
The technical things I learned from Joe got me my first job at Lockheed Martin (then GE Aerospace). It was great to be able to say that I had worked on a NASA program, helped create both a PDR (Preliminary Design Review) and CDR (Critical Design Review) and present elements of them to the Administrator of NASA in Washington.
However, I learned five muchmore important lessons — independent of aerospace or any other technology – that I have used in the eighteen twenty-three years since:
Break Big Challenges into Small Parts. Any obstacle can be achieved if you break it down to smaller items. If these are too large, break them down again. Eventually you will get to things that have clear, straightforward paths for success. Essentially this is the engineer’s version of “a journey of a thousand miles begins with a single step”
Know Your Stuff Inside and Out. You cannot be a technology leader who only manages from above. You must understand how the components work. This is the only way you will see problems before they happen. Remember, you are the leader who is the only one positioned to connect the “Big Picture” to the execution details.
S#!% Happens. Things break. Schedules are late. People leave the project. Plan for this. Ask yourself every week what can go wrong. Put contingency plans together to address the biggest or most likely of these. Today, this is done in everything from Risk Management to DevOps.
There is No Such Thing as Partial Credit. Yes, unlike a rocket, you can “back out” (essentially un-launch) software. However, the costs of this type of failure are enormous: not only does it cost 3-5x more to back-out, fix and regression test changes, it also frequently results in lost revenue and customers. Get things right in development – then certify them in testing (not the other way around). Don’t count on being able to “back-out” after a failed launch–this will be come more and more true as we push software to millions of “things” comprising IoT. Joe hammered a lesson into our heads with a chilling story: when people forgot this and rushed three astronauts died during a basic systems test on the Apollo 1.
Take Ownership. If you are the leader, you are responsible for the team’s or product’s success. If you are a line manager, you are not only responsible for your area but are being relied upon by your peers for success. If you are a hands-on analyst or engineer you are actually delivering the work that leads to success. In all cases, ensure you do your job right, ask for help when you need it and never lie or hide anything.
Five really important lessons. I am grateful I had the opportunity to learn them before I entered the full-time career work force. I try to “pay this back” by teaching these lessons and concepts everywhere I go.
Before I forget…
Thank you to the men and women of Apollo. Thank you also to the men and women of Gemini and Mercury (it is easy to forget them on this day). You achieved miracles on a daily basis and inspired whole generations of scientists and engineers.
5 points where tech balances between life and work