Wednesday, March 6, 2013

Book Review: Adapt: Why Success Always Starts with Failure

“Adapt: Why Success Always Starts with Failure”, Tim Harford, Published by Farrar, Straus and Giroux, May 10, 2011, ISBN-10: 034100969

This book is listed on the 2012 Chief of Staff of the US Air Force Professional Reading Program

The book focuses on how Peter Palchinsky in Russia/USSR exemplified and codified 3 principals to successful projects and initiatives:

  • First: seek out new ideas and try new things
  • Second: when trying something new, do it on a scale where failure is survivable
  • Third: seek out feedback and learn from your mistakes as you go along

The first idea is that true innovation and transformation need to be predicated by early and often experimentation. This idea for trying new things is obvious, only doing what has been done before gets the same results. In order to truly adapt, overcome challenges, changes are necessary. However, the key is to make changes at scales where failure is survivable.

This notion of survivable failure comes to a head when addressing centralized planned projects. He notes several problems with centralized planning, an overestimated the value of centralized knowledge. From that, he addresses how a central bureau’s information is unlikely to address the specifics on the ground, and when integrated over many parts, can tend to destabilize the whole project. He uses a quote that is more direct: "Your first try will be wrong. Budget and design for it," Aza Raskin, designer of Firefox.

Some corroborating evidence was used in citing a study between highly speculative research grants by Howard Huges Medical Institute (HHMI) and the centrally directed NIH MERIT scholarships, which were judged more conservatively in the scope of the whole NIH research portfolio. IN this study, projects selected by HHMI are more likely to be breakthrough and more likely to fail - but ultimately much more skewed to the upside in terms of importance and value to society.

Now, he is also an advocate of measuring the Ultimately, this is the third Palchinsky principal, because getting the feedback, knowing if you are doing any good, is how you will be able to learn from mistakes – and likely even know if you made a mistake at all. Key in the measurement is the controlled experiment nature of how the measurements were taken.

However, not all experiments can be controlled: there do exist "Fundamentally Unidentified Questions" (FUQ'd questions- neat acronym) - questions for when we can measure, calculate and extrapolate from our existing knowledge, but cannot conduct controlled experiments (such as does carbon dioxide cause global warming) - to defeat people claiming that questions are FUQ'd, scientists and innovators must have an identification strategy for what they are going to measure and control.

In his final chapter, Mr. Hartford sums up his application of Palchinsky’s principals thusly, "the ability to adapt requires this sense of security, an inner confidence that the cost of failure is a cost we will be able to bear. Sometimes that takes real courage; at other times, all that is needed is the happy self-delusion of a lost three-year-old. Whatever the source, we need that willingness to risk failure. Without it, we will never truly succeed."

While some management theories indicate that stress is good for innovation, the key here is to create survivable stress – eustress – by which innovation is driven, but avoids overly conservative behavior that generally inhibits the bigger innovations and adaptations.

Overall, I recommend this book for the ideas and perspective on how to innovate in systemic contexts. Large, sweeping initiatives will likely not succeed, but targeted and frequent innovations will explore the space of possibilities more quickly and are more likely to take hold. A good message for upcoming systemic leaders. Read More......

Saturday, August 27, 2011

Book Review: Hubble Space Telescope SE Case Study

James J. Mattice (SES, Ret.), Hubble Space Telescope SE Case Study, Air Force Institute of Technology, Center for Systems Engineering, 10 Mar 2005
Free Download from the USAF http://www.afit.edu/cse/casedocs/files/Hubble%20SE%20Case%20Study.pdf

This soup-to-nuts look at the Hubble Space Telescope (HST) takes the reader through the programmatics and engineering from 1962 through 2005. The bulk of the reading is focused on the system development efforts from 1977 through the first on-orbit servicing mission (1993) in which corrective optics were installed. Mattice presents a combination of “just the facts, ma'am” passages interspersed with interpretations, captured as learning points for the student.

Beyond the learning points identified by Mattice, several systemic leadership observations can be easily identified. The HST program was plagued with multiple examples of transactional and management-by-exception approaches that are incongruous for such a novel system development. Ultimately, for the optical system contractor, the relationship with the associate-prime contractor and the two NASA centers was very formally by contract, with little to no insight, accountability, nor communication. Ultimately, this arrangement contributed to the optical system flaw that had to be corrected on the 1993 on-orbit service mission. Further, the relationship between the two NASA centers, Goddard and Marshall, was by a very specific set of allocated responsibilities by NASA Headquarters and the U.S. Congress. Mattice gave a compelling example of this in the disconnects between the servicing concept development (Goddard) and the launch design/development (Marshall), which required many redesigns.

However, this development was not only transactional. For example, later in the program (1983), a transformational approach to requirements development and management was attempted by creating the Space Telescope Science Institute. This institute fundamentally changed how the NASA centers and contractors interacted with the scientific community (the primary end users for the HST), and moved the users to discuss the HST at the appropriate level.

This case study is not very long, only 46 pages in the main body, which makes it very approachable and digestible to students of systems engineering and program management. Mattice meets the goals set forth by the Air Force Institute of Technology by describing the technical, political, and programmatic context of the case. Mattice mentioned interviews with the Hubble Program Manager (1981-1986) and the Chief Engineer (1974-1988), although almost no description of these key players is given, which is typical for engineering case studies.

I recommend this case study to acquisition and systems engineering professionals, especially those in the space system development domains. In a couple of hours, a reader can identify and internalize many lessons that are still relevant to systems acquisition today. Read More......

Thursday, June 2, 2011

Engineers as leaders? Not a crazy idea outside the US

Leading Question: Why are the fastest growing nations lead by engineers while the US (with its slowing economy) is lead by lawyers and business managers?
Two angles:



  • US is a mature state and doesn’t desire transformational technologies, as that transformation may destabilize the current US leadership and “efficiencies” in delivering the current solutions at known profit levels with existing cultural covenants

  • Growing nations (China and India) desire the transformation to their economies and cultures that may be brought about by a new technology. Both nations having been born out of severe resource shortages, had fairly recent oppression by foreign powers, and desire to have an edge to improve their situation. Engineers and scientists have been critical historically to provide solutions that enable growth and long term stability to these countries.

Consider these two articles from Forbes and Quora about the fact that 4 out of 5 of the top government leaders in China are scientists or engineers. Counter that with the fact that only 22 members of the US Congress (out of 500+) even have a technical degree, most are lawyers. What does this say about US attitude towards innovation and transformation?

Final question for military acquisition: What is the impact to the acquisition system when engineers are told that they will never promote to leadership positions?



  • Hypothesis 1: we will tend to acquire more of the same, as there will be few mid/senior experienced engineers available to design/oversee the effort

  • Hypothesis 2: we will severely underestimate the amount of effort and other technical factors of production needed for novel systems, due to senior personnel lacking intuition or knowledge about complex system development

  • Hypothesis 3: new technologies to be acquired by the government, will consistently cost more in total life cycle cost, due to an inability to evaluate technical plans and mitigate foreseeable risks

Of course, I wish these were hypotheses, because they tend to happen. Consider when a lead program manager responds that a technical risk doesn't exist because "we didn't write handling that into the contract" or "we don't have funds this year for any mitigation". We've made the business and legal constructs king in our culture, without regard for any technical feasibility. Worse, we want lawyers and MBA educated managers in charge, both of which are very transactional career fields; instead of technologists which tend to offer visions of the future without many bars as to how everyone will contribute.

Ultimately, so long as our system continues to tell engineers that they don't have any opportunities as leaders and that they are "geeks and outcasts", I worry that our national edge will continue to erode. Buck the system, develop your best engineers are leaders, and ride the transformational & innovative wave into future prosperity.

Of course, we may end up with our engineers going to China for better opportunities, but would that really happen? (Unfortunately, the Wall Street Journal article referenced indicates that it is happening right now) Read More......

Monday, May 30, 2011

Book Review: Shop Class as Soulcraft

Shop Class as Soulcraft: An Inquiry into the Value of Work, Matthew B. Crawford, Penguin Books, 256 pages, ISBN-10: 0143117467, 2010

Overall impression
Ever wonder how engineers can be more educated, yet less experienced? Have you wondered what the value of hands-on experience is? Wonder how, when using the best model of engineering, a system can fail? In reading Matthew’s work, I quickly built up an understanding of why my intuition rebelled against prescriptive engineering models being useful for growing the next generation of experienced engineers. First, we’ll look at a key systemic leadership take away from having read this book, followed by an overall review of the book itself.

Key take away for Systemic Leadership
In analyzing his experiences in knowledge work, after achieving his PhD in Philosophy, he had a starveling observation: “if occasions for the exercise of judgment are diminished, the moral-cognitive virtue of attentiveness will atrophy.” Applied broadly from the systemic perspective, we have a situation in which prescriptive models of how to do work (formal systems engineering or software engineering models) actually counters our desire to develop experienced engineers. Essentially, detailed, solution-agnostic engineering checklists drive our engineers to be less attentiveness and have less detailed knowledge about what lies underneath. In other areas, he observes that knowledge work and education alone is insufficient to have people who have intuition to form a problem solving strategy when information is incomplete or imperfect. Ultimately, he also observes how the best minds and most motivated people will generally not choose to work in environments which are highly controlled by these intellectual models of what is to be done. This leads to “a vicious circle in which degraded work plays a pedagogical role, forming workers into material that is ill suited for anything by the over-determined world of careless labor.”

Book literature review – approachability, readability, etc.
Overall, “Shop craft as Soulcraft” was a easy read, very approachable, generally using personal narrative stories to illuminate broad areas of inquiry. Yes, there are portions that use precise, philosophical language, but those parts are generally the conclusions at the end of each chapter. If you are interested in the philosophical implications of the stories told in a chapter, this is great. If you aren’t, skip the last few chapters and you won’t miss too much.
The reader must understand that Matthew exposes quite a bit of bias against modern knowledge work, assuming that people want to understand the world around them. While this can be argued one way or the other or the general population, my interest in understanding engineers makes that assumption inherently valid (as the job of the engineer is to understand how something works). Ultimately, if you are disillusioned with “Office Space” type work, you’ll find this book provides some well-articulated discussion points for your use. On the other hand, if you understand the value to society and people of aggregating knowledge to decrease the expertise (and cost) needed to deliver products, you may have problems overcoming the personal experience biases that Matthew exposes.

Overall: I enjoyed this book, and the author was both approachable and capable of keeping my mental focus. Read More......

Monday, April 18, 2011

Book Review: Three Cups of Tea

(Note: I finished this book just a day before the controversy noted below broke - this review is based on the pre-controversy reading - some notes follow)

This book is listed on the 2011 Chief of Staff of the US Air Force Professional Reading Program

“Three Cups of Tea: One Man's Mission to Promote Peace . . . One School at a Time”, Greg Mortenson, David Relin, Penguin Books, ISBN-10: 0143038252, 2007

One person can make a difference. Greg Mortenson shows us how he made a difference to the children of Northern Pakistan. He doesn’t sugar coat this as an easy effort, numerous disappointments and difficulties are along his winding journal to build schools in the Baltistan region. I’m not qualified to comment on the literary style, but Greg’s story is sufficient compelling to pull me through the book.

The portion of the book that most spoke to me was Greg’s humble style in learning the Balti culture and providing what they need, not what he thought they needed. By becoming family with the chief elder of the village of Korphe, Haji Ali, Greg learned that Haji Ali’s greatest desire for his community was a school. Their goals were not so much to explicitly give a specific capability to people, but to transform the lives of everyone. Transformational action is at the core of systemic leadership; perceive the societal, structural need, and provide a solution that enables the society to grow and improve itself. That is the core of systemic thinking.

Another thing to note is how completely the pursuit of this goal consumed Greg’s life. He doesn’t describe his pursuit of the goal as a “labor” or a “job”, but as his passion. The book starts with Greg’s failed assault on K-2, and him committing to providing schools. Quickly, we see Greg switch from mountain climbing to school building; later in the book he notes how out of shape he feels, since he hadn’t been climbing. We could debate if Greg’s efforts were an obsession or a passion. I think that a reader should note that Greg’s level of commitment was necessary to achieve the goal he chose. While this is an inspiring example, people can and should remember that many levels of service can be valuable and transform the lives of others – but commit a sufficient level of effort to achieve the goal.

Overall, I recommend this book for the positive inspiration and example of systemic leadership portrayed.

Recent controversy: http://www.cnn.com/2011/SHOWBIZ/04/17/three.cups.of.tea.controversy/index.html

From reading the article at CNN, I feel my review still stands, regardless of the outcome of the main claims that the books is more idealized than reality. Used as an example of systemic leadership, the story works. Further, the observations of effort/commitment to achieve a goal of this isze are likely to hold and do not seem to be at the heart of the controversy. Ultimately, objective truth about anyone who is portrayed as a hero is hard to achieve. My recommendation for people to read the book isn't for the factual information on a would-be hero, but instead I recommend the book, as I stated, as an example of systemic leadership - changing people by changing the system, in this case by offering schools. Read More......

Saturday, March 5, 2011

Views from inside a true the battle rhythm

As written, our post in 4-Nov-10 about Processes and Battle Rhythms became more poignant in my life now that I'm deployed. Now working in the environment of a command center, the 609th Air & Space Operations Center for Air Forces Central Command, I live, breathe, and task saturate in that rhythm - providing operational assessments from prior periods to senior leadership. Daily, weekly, and monthly, summaries must be created, metrics evaluated against standards, and deviations examined for root causes. Best effort processes are the typical order of the day, since answers arriving after that period's decision point become very difficult for senior leaders to engage.

Why is that? A good reason, at the AOC, the OODA loop for the senior leaders is tightly controlled. We keep these individuals saturated with information and decisions. Arriving out of cycle means that it will take the senior leader (who is honestly very busy) more time to back up into a previous state's information context. Ultimately, the question becomes one of how to queue up our analyzed information (oriented observations, from our previous post) to the senior leader and ensure that future orientations will occur on time for an effective decision that will lead to action.

Unfortunately, acquisition environments tend to believe that information can arrive at any time and should immediately impact all activities. However, in my experience, when senior leaders handle the new information out of cycle, the acquisition office tends to split and fracture. Configuration control is lost ("did this study take that into account?"), plans are changed before courses of direction are decided ("the outcome of this memo is obvious, we should do this to help the boss get ahead!"), and ultimately senior leaders can become so involved with the new bit of information that other, planned decisions are put on hold - and those missed/deferred decisions start a backlog of program delays that can ultimately severely and negatively impact the program.

I have worked with senior leaders who are conscience of their battle rhythm. Although the tempo of the change may not be as desired ("change everything by COB TODAY!"), but instead of loosing the metaphorical bubble on all the other details of the program, their method ensures that the next decisions needing the information will have the new information and be able to make good recommendations for action.

The real question for leaders:

A - Do you want to give immediate, but disoriented direction for action?

OR

B - Do you want your next decision for action to be properly oriented?

I can see where option A gives the appearance of being responsive; although to a systemic thinker, option B is far more responsive, since the systemic leader in option B knows how to influence their battle rhythm (and OODA loop) so that new information impacts critical decisions. Read More......

Tuesday, November 2, 2010

"But I have a process, why care about Battle Rhythm?"

With the advent of the Capability Maturity Model (CMMI and its relatives) everyone wanted to put their system and software development activities into well defined (level 3!) processes. We were sure to measure those processes (level 4!) and ensure we are quantitatively improving (level 5!). Ultimately, the goal would be to have a well defined process to ensure that given the same inputs, we get the same outputs, in a control fashion that efficiently expends resources. Essentially, most processes focus on maintenance of invariants (baseline, basis of estimate, confidence, risk posture, function across interfaces, etc).

Battle rhythms, on the other hand, sequence a leader’s Observe-Orient-Decide-Act (OODA) loop. By sequencing the the flow of any type of project information (observations) through analysis to provide perspective (orient) to help a leader’s direction (decisions) lead to coherent activities (action). However, the goal is only coherent action, indeed a battle rhythm receiving different inputs make take radically different, but coherent, action depending on the leader, even if the analysis activities are highly regimented processes to ensure the quality of the analysis.

So based on this, why take a step back from this great improvement in formally defining system and software processes to talk about systems and software leadership's battle rhythm. Honestly, in comparison to the formality of process definition, describing a battle rhythm seems to some to be a less mature concept.

But the power of battle rhythms are their simplicity; sequence the OODA functions. Battle rhythms must exist on human timelines for items that require on going decisions - for the most part that means daily, weekly, (rarely) monthly, and (very rarely) annually. Examples of battle rhythms include: handling of action items from higher management / headquarters (daily), financial reconciliation (weekly), project assessments of progress to goals (typically monthly), personnel appraisal and development (annually), mission operational planning (such as the the 72 hour Air Tasking Order battle rhythm), and mission execution (the individual pilot's life on a daily level). While the engineering review board process may be a defined process, the battle rhythm is the means that a chief engineer is able to ensure all factors are included when reviewing a technical artifact. Indeed, that battle rhythm will look very different for a military weapon software development than for a commercial, cloud-computing entertainment software development.

Although battle rhythms are simple, there is no single battle rhythm; even for a single function, there are a near infinite number of implementations. Fortunately, organizations tend to value successful battle rhythms, so effort tends to be expended to capture the essence of a battle rhythm's template (key attributes that attempt to abstract away individual considerations). These
battle rhythm prototypes tend to be saved and distributed. In the military, highly successful battle rhythms get integrated into doctrine. Outside the military, many behavior based leadership books recommend different battle rhythms for leaders. However, the important item when applying these prototypes is to consider the modifications needed for the battle rhythm to be useful for an individual leader. All of these describe various information items that should be analyzed to support a decision on action.

I can hear the process zealots saying "ah ha - sequencing of information - that's a process!" NO! The key difference is that battle rhythms are used to get to coherent action, but they do not necessarily maintain invariants. Processes specify behavior to ensure that the same inputs lead to the same outputs; and the underlying assumption that the inputs can and will be repeated often enough to validate the control. Battle rhythms, on the other hand, have to operate (decide and act) even if the inputs are missing/low quality and further the battle rhythm does NOT guarantee that the same inputs yield the same output, since the output is a decision from a leader (and different leaders will give different outputs). Battle rhythms do not prescribe decisions, only orchestrate the OODA loop.

So hopefully, this provides some some insight and points of distinction that lead us to consider battle rhythm in the system leadership context. This article is meant not to be critical of process definition in all contexts, but instead focused on aggressively differentiating defined processes from battle rhythms. Indeed, back to our systemic leadership roots, the systemic leader shouldn’t focus solely on decisions within the process, but instead should focus on shaping the battle rhythm to ensure effective action to achieve the leader’s vision. Read More......