At heart, debates about control and automation in aircraft are debates about the relative importance of human and machine.
I found this book while searching for more information about the Apollo Guidance Computer in preparation for a talk (see: Landing on the moon: three visions attained). Fortunately for me, the nearest St. Louis County Library branch to work had a copy.
I had assumed the book was just about the computer itself, which was why I got it, but at ~80 pages in, it really hasn't been covered except by reference. Instead, what the book has covered is something that I recognize from developing flight controls back at Mason, and to some extent in systems engineering in my current position: the tension between the human pilot and the automatic pilot (and by extension its designers). It's an inevitable tension—in simplistic ego terms, the fight between controlling and being controlled. In more sympathetic terms: it takes more than equations to design and more than human experience to fly a sufficiently complex aircraft.
So: straight ahead, learning more about X-15, etc., until I get to the parts about the AGC and flight software that I wanted to learn more about. In the meantime, the book has also been the source of some interesting citations:
[p. 73] In those days, airplanes were unreliable and I thought they might become more so. I never flew without a pair of pliers, a screwdriver, and a crescent wrench in pocket so I could fix things on the airplane. This was being a mechanic, not an engineer. I had applied for the Engineering School because I thought there should be a better rapport between the aeronautical engineer and the pilot. It seemed to me that the engineers felt pilots were all a little crazy or else they wouldn't be pilots. The pilots felt the engineers as a group were, if not incompetent, at least not thoroughly acquainted with the pilot's viewpoint—that all the engineers did was zip slide rules back and forth and come out with erroneous results and bad aircraft. I thought from a philosophical point of view that it would be good to have engineers and pilots understand one another better. It seemed desirable to marry these two capabilities in one person—and I wanted to be that person.
—General Jimmy Doolittle, I Could Never Be So Lucky Again: An Autobiography (1991)
—Dick Day, Training Considerations of the X-15 Development, NSIA Meeting (1959-11-17). In: Gene Waltman, Black Magic and Gremlins: Analog Flight Simulations at NASA's Flight Research Center, NASA SP-2000-4520 (2000).
To train the pilots for the X-15 landing phase, several methods were considered. First, an analog computer was used with an oscilloscope presentation to indicate approach attitude. This gave the pilots and engineers an understanding of the relative importance of the factors affecting the landing flare, but definitely lacked the in-flight realism afforded by the rapid approach of the ground.
Naturally, when faced with the opportunity to dig into the Apollo program, I came back to this book, which I haven't read since... sometime in college, I don't even know when. Whenever anyone asks about a good systems engineering book, this is the one that I suggest—it's just a wonderful design effort to meet a set of gnarly and shifting mission requirements in a previously untried environment. It would have been an incredible opportunity to be on that program. Just... amazing.
[p. 51] I had the aerospace engineer's dream job of the century. Not only would I design and build the first spaceship to land men on another heavenly body, but I was encouraged by NASA to let my imagination run wild and question everything we and they had done in prior studies and the LM proposal. I could start fresh, with a clean sheet of paper, using our past work as a point of departure. Such freedom!
What I remember liking about this book is that the program it covers, the development of the Lunar Module at Grumman in the 1960s, is not at all smooth. Things are late, things don't work, things break, the customer changes their mind, etc. It's all stuff we have to deal with today, sure, but the stakes were really high and public, and the mission was literally and figuratively out there.
I don't often re-read books, but I'm really looking forward to reading this one again.
Bonus: here are some papers by Tom Kelly that discuss the history of the Lunar Module.
Kelly, Thomas. "Design features of the project Apollo lunar module (LM)." 16th Annual Meeting and Technical Display. 1981. doi: 10.2514/6.1981-910.
Kelly, Thomas. "A review of the Apollo Lunar Module program and its lessons for future space missions." Space Programs and Technologies Conference. 1990. doi: 10.2514/6.1990-3617.
Kelly, Thomas. "Manned lunar lander design-The Project Apollo Lunar Module (LM)." Space Programs and Technologies Conference. 1992. doi: 10.2514/6.1992-1480.
I heard about this one in an episode of HBR IdeaCast in March 2019: #674 A Theoretical Physicist (and Entrepreneur) on Why Companies Stop Innovating.
Why did I pick it up? I've worked in big companies and small companies. They each have maddening characteristics, although they're not quite the same maddening characteristics, for the most part. I thought Safi Bahcall's explanation in the podcast of how there are structural characteristics of organizations that could be manipulated—versus the normally soft and not-often-well-explained cultural characteristics from business books—to develop new products and new ideas, especially in larger organizations that have developed in such a way that they tend to favor sure things and avoid new things.
I first heard of this book when Chip Conley gave a talk at one of the Long Now's Seminars on Long Term Thinking in March 02019: The Modern Elder and the Intergenerational Workplace. I didn't consider reading the book after listening to him then. The talk was interesting, but I didn't give the book any thought at all.
Then earlier this week, while compiling a list of things to read on the topic of managing older employees, the book popped up again. This time I had a reason to get it, so I picked it up immediately on Kindle (a rarity for me—I tend to get things at the library or used).
The reason for picking up this book is mostly tactical. I want to convince a certain target audience to pick up the mantle as an elder—an experienced person with something to give rather than something to prove. Growing up in aerospace from the mid-2000s on, there always seemed to be some sort of catastrophic warning about the coming workforce turnover, like the punchclock at the factory was going to strike midnight and all the boomers were going to turn into pumpkins. It seemed like an opportunity, honestly. How many times we were told that the average age of engineers on the Apollo program were some obscenely low age, something in their 20s. (Parenthetically: those opportunities exist and existed in this era if you know where to look for them; suffice it to say that it's a fool's errand to look for them in established places.) More than a decade later, the feeling is some uncomfortable amalgam of "please don't go I have more questions" and "why don't you leave already?" The former feeling derives from knowing that they know why things actually work the way they do; the latter feeling is a visceral frustration at the clot of upper-level staff forever occupying the upper-level positions.
So it makes sense, I think, to try to understand how things feel from the other side. And it also makes sense to plan for how to engage that experience and wisdom without casually tossing it out.
Here's a paper I just finished reading, and I recommend to you:
I found this one as a reference in The First 90 Days by Michael Watkins (notes) in the section on securing early wins. That section boils down to: you really need to understand how your organization is put together, and how the various components and functions affect each other, in order to make change work.
This paper is (I think) the source of the McKinsey 7S Framework—the seven S's being:
- Superordinate goals
I think that list of traits is mostly obvious, in a subconscious way, but people tend to focus on (1) structure and (2) strategy. I'm not sure what fallacy it is, but I understand the tendency toward thinking that if I just organize a group of people or an organization in a certain way, then a successful outcome will just fall out of it. "If you build it they will come", right? Similarly for strategy: all we ever need is a good plan and we're all set to win.
Structure is king. Strategy is king. We've all experienced how the outcome really goes when we push the lever all the way in either direction.
[p. 17] Our assertion is that productive organization change is not simply a matter of structure, although structure is important. It is not so simple as the interaction between strategy and structure, although strategy is critical too. Our claim is that effective organizational change is really the relationship between structure, strategy, systems, style, skills, staff, and something we call superordinate goals.
One of the important things that the drive for the One True Strategy or Structure completely misses is the importance of the people involved in crafting the ideas and, even more importantly, grinding and polishing them until the ideas work. To forget that is inhumane.
[p. 24] We are often told, “Get the structure ‘right’ and the people will fit” or “Don’t compromise the ‘optimum’ organization for people considerations.” At the other end of the spectrum we are earnestly advised, “The right people can make any organization work.” Neither view is correct. People do count, but staff is only one of our seven variables.
Anyway, the lasting thought I had after reading this is: for complex systems, it's not likely that there's just one factor you need to adjust to fix something that's out of balance. But that's obvious, no? Of course. Who doesn't understand that by intuition, let alone experience? But the 7 S's are a nice, simple basis for a checklist or template to consider when planning to make a change that affects a complex system. (And by "simple" I don't mean it's simple to change anything complex, but that having a short list is as simple as you can hope for.)
Richard M. Roberts and Roger J. Kreuz, Becoming Fluent: How Cognitive Science Can Help Adults Learn a Foreign Language (2017). (notes)
How did I find this book? Accidentally. I was searching for a copy of a paper, Susan Brennan, The Grounding Problem in Conversations With and Through Computers, which is collected in Social and Cognitive Approaches to Interpersonal Communication. I found that book in Google Books, and in the "related books" section I saw Becoming Fluent. "Roberts and Kreuz report evidence that adults can learn new languages even more easily than children." OK—sold. When I found out the St. Louis Public Library had a copy I jumped right into the queue for it.
The authors start out with three myths they intend to tear down:
Myth 1: Adults cannot acquire a foreign language as easily as children.
Myth 2: Adults should learn foreign languages the way children learn languages.
Myth 3: When learning a foreign language, try not to use your first language.
Sounds good—I need all the help I can get.
Every day, every week, every month, at work and at home, I spend some time planning the upcoming day, week, or month. One of these days I ought to share the templates I use—Evernote at home, OneNote at work. (One of These Days™.) I've found it to be a useful habit for getting some of the things I want to do done.
That's half of the point here. I finished reading Michael Watkins' The First 90 Days (notes) over the weekend in preparation for a shift to a new team at work. I've never treated a job transition in a systematic way before—"I'll just wing it"—and I wanted to do it right this time. In Chapter 9, "Manage Yourself", the three main points boiled down to: plan, reflect, and get advisers. The first and the last seem clear to me, even though I only practice the first. (I used to also consult with advisers, although I didn't know that's what I was doing or that it was important—I've also been putting that back together.) Reflecting is the obvious missing piece to what I do. What's the point of planning if you don't loop back around and ask yourself if the plan worked?
The suggestion in the book was to use structured reflection, a term that seemed a little fluffy. A template was given with some questions to ask yourself and think about—a decent starting point. Now I list and describe three things that worked and three things that didn't work every day before signing off at work, and then the same at home. There is some tension about feeling constrained by a process or becoming a robot, but honestly I think that's more about the chafing of starting a new habit. There is plenty of freedom and creativity within the constraint.
Then I thought: why not look for more and better questions? Why not see if there's any evidence that it works? When I threw "structured reflection" into Google—and more importantly, Google Scholar—I discovered that structured reflection wasn't an idea created by the author, but something that's been studied and developed, especially it seems in nursing and education.
Here are some interesting references on the topic that I found, though I haven't read them all yet:
- Reflective practice, Wikipedia
- Jim Steele, Structured reflection on roles and tasks improves team performance, UAH study finds, University of Alabama at Huntsville News (2013-04-18).
- Johns, Christopher. "Framing learning through reflection within Carper's fundamental ways of knowing in nursing." Journal of advanced nursing 22.2 (1995): 226-234. (pdf)
- Carroll, S., et al. "The Learning Assessment Journal as a tool for structured reflection in process education." Frontiers in Education Conference, 1996. FIE'96. 26th Annual Conference., Proceedings of. Vol. 1. IEEE, 1996. (pdf)
- Eyler, Janet. "The power of experiential education." Liberal Education 95.4 (2009): 24-31. (pdf)
- Mamede, Sílvia, et al. "Reflection as a strategy to foster medical students’ acquisition of diagnostic competence." Medical education 46.5 (2012): 464-472. (pdf)
- Cox, Elaine. "Adult learners learning from experience: Using a reflective practice model to support work‐based learning." Reflective Practice 6.4 (2005): 459-472. (pdf)
- Shumack, Kaye. "The Conversational Self: Structured Reflection Using Journal Writings." Journal of Research Practice 6.2 (2010): M17. (pdf)
- Korthagen, Fred, and Angelo Vasalos. "Levels in reflection: Core reflection as a means to enhance professional growth." Teachers and teaching 11.1 (2005): 47-71. (pdf)
- Gregory, Mark, and Irena Descubes. "Structured reflection in information systems teaching and research." Proceedings of the UK Academy for Information Systems Conference. 2011. (pdf)
- Reymen, Isabelle MMJ, and Dieter K. Hammer. "Structured reflection for improving design processes." DS 30: Proceedings of DESIGN 2002, the 7th International Design Conference, Dubrovnik. 2002. (pdf)
Here's a post I come back to every few months: Seth Godin, Let's stop calling them 'soft skills', It's Your Turn (2017-01-31).
But we give too little respect to the other skills when we call them “soft” and imply that they’re optional.
It turns out that what actually separates thriving organizations from struggling ones are the difficult-to-measure attitudes, processes and perceptions of the people who do the work.
Culture defeats strategy, every time.
Emotional intelligence. Sure. OK. I get it (in that I understand it's an important behavior) although I don't really get it (I wish my amygdala had a stickier trigger).
There was a part on this year's performance evaluation at work under behaviors: Honesty and Communication. I believe the verbal explanation for my score on this one was, roughly: "Well, you're definitely honest." Do not file under: Compliments.
I suppose I'd like to believe that I'm just carrying water for Ray Dalio and his radical transparency, but maybe it's not the best thing to do. Maybe it's a blurry line between being honest and being an asshole, but honestly it's not that blurry. And without strong performance to soothe the burn, there's no line at all—you know where you stand.
There's a book I read last year to help work on this, On Emotional Intelligence, a collection of ten Harvard Business Review articles related to emotional intelligence. I guess I could use another dose. I'm not going to pick up the book again, but rather just scrape the individual articles somewhere:
- Daniel Goleman, What Makes a Leader? (1998-11) (pdf) (notes)
- Daniel Goleman, Richard Boyatzis, and Annie McKee, Primal Leadership: The Hidden Driver of Great Performance (2001-12) (pdf) (notes)
- Joel Brockner, Why It’s So Hard to Be Fair (2006-03) (pdf?) (notes)
- Andrew Campbell, Jo Whitehead, and Sydney Finkelstein, Why Good Leaders Make Bad Decisions (2009-02) (pdf) (notes)
- Vanessa Urch Druskat and Stephen B. Wolff, Building the Emotional Intelligence of Groups (2001-03) (pdf) (notes)
- Christine Porath and Christine Pearson, The Price of Incivility: Lack of Respect Hurts Morale—and the Bottom Line (2013-01) (pdf) (notes)
- Diane L. Coutu, How Resilience Works (2002-05) (pdf) (notes)
- Susan David, and Christina Congleton, Emotional Agility: How Effective Leaders Manage Their Negative Thoughts and Feelings (2013-11) (pdf) (notes)
- Jay M. Jackman, and Myra H. Strobe, Fear of Feedback (2003-04) (pdf) (notes)
- Kerry A. Bunker, Kathy E. Kram, and Sharon Ting, The Young and the Clueless (2002-12) (pdf) (notes)
Postscript. I've had this song in my head all day. I couldn't identify it, just that I knew it was from long enough ago. Then it just hit me now: Jawbreaker, "Save Your Generation". With these lines, I guess it fit the theme even though I didn't know it:
You have to learn to learn from your mistakes.
You can afford to lose a little face.
The things you break,
Some can't be replaced.
A simple rule: every day be sure you wake.
Catherine D. Cramton, The Mutual Knowledge Problem and Its Consequences for Dispersed Collaboration, Organization Science 12 (2001-06). (pdf) (notes)
This paper was very interesting, especially since I just spent the year working on a team that was split mostly into two locations (St. Louis vs. Oklahoma City), with a few other players in other cities around the country. That's why I sought it out after seeing it as a cited paper in N. Sharon Hill and Kathryn M. Bartol, Five Ways to Improve Communication in Virtual Teams, MIT Sloan Management Review (Fall 2018) (notes). It's difficult to work on distributed teams and get it right, so I wanted some advice.
I've grabbed lots of notes, quotes, and references here.
Five problems to achieving a state of mutual knowledge were identified:
- failure to communicate and retain contextual information
- unevenly distributed information
- difficulty communicating and understanding the salience of information
- differences in speed of access to information
- difficulty interpreting the meaning of silence
(2) and (4) are obvious enough. Skip.
Point (5)—misunderstanding silence on the other end of the line—was the most surprising, and perhaps the most interesting. I made some notes about it here: Interpreting silence. It's really obvious—once you're aware of it. Think of any time you've been ghosted for any reason, deserved or not. It hurts. I've been trying to be conscious about it.
An interesting point was raised about (1), the "failure to communicate and retain contextual information". A reference was made to information sampling (Garold Stasser and William Titus, Pooling of unshared information in group decision making: Biased information sampling during discussion, Journal of Personality and Social Psychology 48:6 (1985)). The quick idea is this: when people want to talk about something, they sample from the information that they know. If more people in a group have the same piece of information, it is more likely that it will be mentioned, which leads to more people knowing the shared information. Esoteric information is less likely to be shared, and fewer people will know it. If a team is split up into separate parts, information is less likely to be sampled and shared across partitions because much of the communication happens locally, so different teams will be holding a different pool of knowledge—and that means that they'll be working in different contexts as they try to solve the group's tasks.
So you need a Single Source of Truth even more with a distributed team. Imagine what kind of abuse I get when I suggest that teams should have an internal blog. But they should. Individual knowledge and team knowledge need to be mixed together.
Finally, point (3): misunderstanding which information is important. Similar to (5), this is one I've clearly been getting wrong. An example given in the paper is how easy it is to misunderstand things written in emails. A sender might think one point given is obviously the most important thing; the receiver might think something else is the most important thing and not even see the important thing the sender wanted to communicate. The point needs to be clearly The Point, else frustration and bad decisions will soon follow. It's much worse when you're separated from the person you're trying to communicate with because all of the hand gestures and facial expressions and voice tone and so on that are also communicating information aren't there.
One more final note from the paper that raised a point that I often get wrong: attribution of blame. I get that it's not helpful to blame people directly, instead of the situation or result, but I make that slip often. There's even a field of study related to it—Attribution theory—so I guess I'm not the only offender. Anyway, from the paper:
When an error or conflict in information exchange is detected, people make attributions concerning its cause. [...] Personal attributions associate the cause of the communication conflict with some characteristic or behavior of an individual. [...] Attributions were judged to be constructive if they facilitated inquiry and change to reduce the incidence of communication conflicts in the future. Attributions were nonconstructive if they were task irrelevant or destructive to cooperation, inquiry, and adaptation. The researchers suggested that situational as opposed to personal attributions tend to produce better resolution of conflicts because they focus participants on modifying the "contracts that guide the communication process. If attributions are destructive, contracts concerning the communication process break down and people withdraw from cooperation.
If you work in distributed teams you should read the paper. It might keep your foot out of some of the traps that others have stepped in. (Now to find ways to pry my foot out of these traps that I just noticed...)
Aside. Interesting-looking rabbit hole discovered but not pursued: Several references are made to Herbert Clark, a psycholinguist at Stanford. Based on titles alone, I would check out the following if they ever line up with what I'm pursuing:
- How to make requests that overcome obstacles to compliance
- Referring as a collaborative process
- Contributing to Discourse
- References in conversation between experts and novices
- Coordinating beliefs in conversation
- Speaking while monitoring addressees for understanding
- Navigating joint projects with dialogue