In the book Simplexity, Jeffrey Kluger points out that work is nearly always more complex than it initially appears to be:

Just which jobs we consider complicated and which ones we consider elementary, even crude, is a judgment too often made not on the true nature of the work but on the things that attend it — the pay, the title, whether it’s performed in a factory or an office suite, in blue jeans or a gray suit. And while those are often reasonable yardsticks — a constitutional scholar may indeed move in a world of greater complexity than a factory worker — just as often, they’re misdirections, flawed cues that lead us to draw flawed conclusions about occupations we don’t truly understand. We continually ignore the true work people and companies do and are misled, again and again, by the rewards of that work and the nature of the place it is done.

It may not be much of a surprise that bosses and economic theorists don’t fully appreciate the complexity in many jobs. Both groups, after all, are interested mostly in performance, never mind how it’s achieved. More surprising is the fact that coworkers are often just as poorly informed about what the person one desk over or two spots down on the assembly line actually does all day. When they do give the matter any thought at all, they almost always conclude that the other person’s job is far less complicated than it is.

The longer it takes for this complexity to become apparent, the less useful this feedback will be in implementing changes that will have lasting effects on performance. People are motivated to change their behaviors when their own interests are connected to business needs. Causes must be connected to effects so they can make sense of information and how it relates to a particular context and framing of their work. In The Principles of Product Development Flow, Don Reinertsen describes the role feedback plays in enabling teams to establish control over their environment:

Rapid feedback causes us to subconsciously associate our delivery of a work product and the beginning of the next process step. This attribution of causality gives us a sense of control, instead of making us feel we are the victim of a massive bureaucratic system.

In the book Improving Performance, Brache and Rummler describe the factors which affect the ability to perform work. Collectively, these factors determine the extent to which planned work can be successfully executed and determine the extent to which the means of performing such work can be improved over time. These factors include:

1. Job Preconditions

   1. Are the inputs accessible and suitable for processing?

   2. Can the task be performed without interference?

   3. Are the procedures and workflow logical?

   4. Is help available if required?

2. Performance specifications

   1. Do job standards exist?

   2. Are they attainable?

   3. Are they accepted by the people who must perform the work?

3. Ability to execute

   1. Are the roles that individuals are assigned to perform consistent with their experience and preparation?

   2. Do the performers have sufficient capacity available to implement these roles within the time allocated?

4. Feedback

   1. Will feedback information be relevant, accurate, specific, understandable, and timely?

   2. Will the feedback be provided in a way that is useful to the performer and so that adjustments can be incorporated within the required period of performance?

5. Motivation

   1. Have incentives and consequences been established to support desired performance?

   2. Are the criteria for reporting progress and estimates of remaining work well designed, agreed to, and appropriate to the situation?

Simply put, the degree to which work is actionable determines the pace at which work can be acted on, and the extent to which rework can be avoided. Jobs are 'actionable' if and only if they satisfy all the above attributes. When some portion of a work package does not satisfy these attributes, the time it will take to perform that work will be more variable, since work products that will be produced will be more likely to have less utility than desired, and risks associated with achieving target outcomes will be increased. Teams select the most actionable work from a work package to perform first, even though this work may not be the most important work from the perspective of the customer; while it may enhance the team's ability to demonstrate progress in the short term, this approach may not produce the best long-term results.

Legal recognition by the certification authority that a product, service, organization or person complies with the requirements. Such certification comprises the activity of technically checking the product, service, organization or person and the formal recognition of compliance with the applicable requirements by the issue of a certificate, license, approval or other documents as required by national laws and procedures. In particular, certification of a product involves: (a) the process of assessing the design of a product to ensure that it complies with a set of standards applicable to that type of product so as to demonstrate an acceptable level of safety; (b) the process of assessing an individual product to ensure that it conforms with the certified type design; (c) the issuance of a certificate required by national laws to declare that compliance or conformity has been found with standards in accordance with items (a) or (b) above.

There are many unique challenges associated with the development of such safety-critical software. The projects which must produce this kind of product typically have to deal with issues such as constrained resources, novel system architectures, and real-time performance constraints; these amplify the already difficult challenge of successfully developing software within fixed time allocations and to very demanding requirements.

The introduction of regulatory oversight and conditions into this environment can either help or hinder achieving these goals, depending upon how effectively and carefully this oversight is implemented. If insufficient attention is given to key details during project execution, or if there is a lack of understanding of the underlying requirements necessary for implementation, the risk to the resulting system development activities and products will be high.

Purpose

The purpose of DO-178's guidance is to mitigate these risks by providing sufficient information to successfully plan and implement development activities so that certification can be achieved. When experienced software certification professionals and airframe manufacturing applicants both adopt common guidance, it helps them make consistent determinations of compliance regarding design, development, and operational practices for aircraft and related ground systems.

DO-178 is neither a software development process nor a prescriptive standard for such a process. Instead, the document serves to structure and guide negotiations between applicants and certification authorities on the activities and deliverables which must be accomplished during product development and support activities. The guidance strives to balance the need for tangible material that provides a consistent basis for these determinations against the range of existing airborne software and company processes that are used in actual practice across the industry.

Interfaces

As a result, while the document provides key compliance criteria, it does not provide specific, useful information on how to apply this information on development programs, in a cookbook, 'how-to' manner. The document will thus only be effective when correctly interpreted and applied by experienced professionals, as they prepare, approve or recommend approval of technical data for submission to certification authorities. This style is consistent with the mentoring and selection process for Designated Engineering Representatives across the industry, and fundamental to Organization Designation Authorizations now in place.

The complexity and extent of the compliance data required by DO-178 depend upon the characteristics of the system/software, associated development practices, and the interpretation of DO-178 guidance, especially when it must be applied to new technology and situations in which there is little or no precedent available to draw from. Two different Airworthiness Representatives, working from the document, may still reach different decisions about the acceptability of a particular artifact, because of their experience, preferences, and situation; no standard can or should eliminate technical judgments by qualified agents.

Concepts of operation

Like any standard, each version of DO-178 had good points and bad points (and some versions even contain a few errors). However, careful consideration of its contents, combined with solid engineering judgment, is intended to produce better and safer software. The material is not always popular or easy to implement, but neither is the challenge of assuring the safety of flight. Insights about how the guidance is applied in the real world are also fed back to accomplish continuous improvement of the standard itself.

As an example of how criteria are invoked, some believe that the enhanced rigor and completeness of verification evidence required by DO-178 represents a significant cost burden on the avionics industry. Representatives have complained that producing this evidence requires an inordinate amount of effort, and question the value resulting from this effort. Such views must always be considered in the context of the standard's mission. Since the original emphasis of the DO-178 document has always been safety rather than cost-effectiveness, companies will naturally have widely varying approaches to implementing DO-178, and some are clearly more cost-effective than others.

Call to action

The initial version of the document was published in 1982, just prior to certification of the first models of Boeing's 757 and 767 aircraft. When the first revision, DO-178A, was published only 3 years later, the avionics industry had just completed a major transition from analog to digital systems, in which software played a much larger and more prominent safety-critical role. As a result of this transition, many more companies were subject to certification oversight and compliance determinations. During this initial use, an unacceptable portion of these companies struggled to successfully certify their systems, because these versions of DO-178 were not sufficiently detailed to provide them with sufficient implementation guidance.

Because of these shortcomings, the industry quickly came to a conclusion that still another version of DO-178 was needed. The new version was expected to incorporate experience from these initial applications of prior versions of the guidance and to address a number of questions that were being raised as a result of emerging technical issues and proposed new approaches. In some situations, these questions required new rules to be established, such as in identifying mechanisms for certifying reusable software components, qualifying tools, assessing object-oriented design impacts, and dealing with inoperative code in operational systems.

Emerging drivers

To pick just one of these examples, DO-178 activities are expected to produce rigorous and complete verification and traceability evidence, and the efforts required to produce this information can be quite substantial. As the complexity of software has increased, the cost to produce this verification information has also grown proportionally. While tools have always been used in many situations during development, emerging tools were envisioned to play an increasing role far beyond what had previously had been attempted. This reliance upon such tools, potentially with limited reviews of their results and artifacts, motivated the industry to consider a more explicit definition of tool qualification criteria, and to integrate those criteria into the development practices and descriptions of the rest of the document.

The DO-178B revision was also expected to align its concepts and terminology with emerging guidance for systems development which was concurrently being developed. This guidance, documented in DO-254, provides criteria for design assurance of airborne electronic hardware and describes the expected information required throughout project conception, planning, design, implementation, testing, and validation. For example, through joint agreements between the two standards efforts, it was agreed that the terminology used to describe the criticality of safety considerations needed to change from "critical, essential, and nonessential" to "catastrophic, hazardous/severe-major, major, minor, and no effect". To reflect these changes, the software levels which had originally been described in DO-178A as "Level 1, Level 2, and Level 3" would also need to be changed to "Level A" through "Level E" in DO-178B guidance. This change enabled correspondence between system and software levels to be made when accompanied by appropriate system design and implementation techniques that were used during development.

More significantly, a means of clearly defining and communicating the effect of these changes needed to be established for these corresponding requirements as these levels changed. For example, with respect to the types of verification test coverage required for Levels C, D, and E software, only statement coverage needs to be achieved, but for Level B software, decision coverage is required, and for Level A software, each part of a condition must be demonstrated to correctly affect the outcome through the program’s logic. The standards body needed to determine how these differences would be defined, and the document had to delineate them in a way that was clear, concise, and appropriate to the situation.

After consideration of all of these changes, it became apparent that a complete rewrite of DO-178A was required, despite the fact that this would be the third revision developed for this community in only 5 years.

Because of concerns about the direction which this updated version could take, hundreds of participants from across industry were involved in authoring, reviewing, and integrating the resulting DO-178B content. Organizing their efforts required developing mechanisms so that key issues could be surfaced and analyzed, alternatives weighted, and specific text for proposed guidance could be proposed so that each community of interest could form, storm, and norm there way towards consensus viewpoints.

There was significant pressure to 'get this one right'. In light of the volatility of prior efforts. With the benefit of hindsight, it is worthwhile reviewing the keys of success to this effort, which collectively enabled us to successfully manage the scale and nature of participation for the overall standardization, and to improve the quality and usability of the resulting guidance, and its acceptance by the affected stakeholders:

There was skin in the game for the participants

The development of aircraft systems and the software embedded in these systems rely heavily upon a 'safety culture' that actively focuses on producing software with dramatically fewer safety-related defects than traditional practices would normally produce. In such cultures, with lives and company reputations at stake, the opinions of practicing colleagues tend to be much more highly valued than outsiders. The engineers involved in these development efforts must pay meticulous attention to detail, and act deliberately as safety-related requirements and issues are identified. As they do this, other needs like cost-effectiveness, schedule predictability, or adoption of the latest technology innovations, while important to the business, are understandably less important than the focus of DO-178B, which is on assuring the development of software which will operate in life-critical systems.

In this situation, the committee participants recognized that the guidance which would be produced by committee activities would be of primary importance when performing their duties in their 'day jobs' but would not be the only guidance they would need to deal with. While DO178 is described as guidance throughout the document, this is because regulatory authorities describe it as an acceptable means of determining compliance for aircraft certification, without closing the door to other means. In all other ways, however, this document provides the minimum acceptable provisions (i.e. the standards) which must be taken into account in planning and implementing software-based development activities for products that are to receive regulatory approval.

For many other industry standards, such a 'mandate for use' is either not in place or is not achievable because of the way the guidance has been expressed or invoked. Further, compliance in these other situations often does not need to be demonstrated in any formal sense (though groups may still claim they are compliant, without saying by how much), or to whom and how that demonstration has been secured and recorded.

Decisions about the content of DO-178B in this context were made by striving for consensus by all participants. Consensus does not mean agreement, but rather acceptance, and requires a give and take by all participants to find common ground and jointly strengthen the negotiated position. Achieving this consensus across hundreds of interrelated issues required many meetings to work through but paid off in the quality of the resulting document and the endorsement by the broader community. When consensus could not be achieved, minority decisions were documented and were accepted by the Special Committee chairs, but this path was only found necessary in extremely limited cases, and all these concerns were resolved by final publication.

Community engagement

Such consensus-based standards may be biased towards guidance which retains the ability of industry members to refine (rather than replace) their current practices and require judgment by experienced individuals to make detailed compliance determinations. To reinforce, although a standardized format for documentation might be preferred by regulatory groups, any such format selection would likely favor some companies or groups over others. In a team of competing industry participants, any such specific recommendation would favor some over others and thus would fail to achieve the necessary consensus buy-in. The relevance of the resulting guidance with respect to the diverse implementation approaches used over this period is a direct consequence of the team environment which was fostered as the standard was developed and ratified.

Over time, this requirement for compliance demonstration has resulted in forming a community of practitioners from many different perspectives. These practitioners can come together and have meaningful discussions about development practice trade-offs and their consequences. Such trade-offs are a part of the life of every system development. At the end of the day, DO-178 and its processes don't certify safe systems; this community does. The importance of their engagement in this reflection and self-regulation cannot be over-emphasized, and such involvement by practitioners has often been missing from other efforts to crafting a body of knowledge?for other occupations or industry segments.

Terms of reference were established to scope and provide accountability for the effort

Terms of reference were established for the DO-178B Special Committee by the RTCA board to focus and stabilize the efforts of the working groups. These objectives called the group to:

• Examine existing industry and government standards and consider for possible adoption or reference, where relevant

• Assess the adequacy of existing software levels and the associated nature and degree of analysis, verification, test and assurance activities. The revised process criteria should be structured to support objective compliance determination

• Examine the criteria for tools to be used for certification credit - for example, tools for software development, configuration management, or verification

• Examine the certification criteria for previously developed software, off-the-shelf software, databases, and user-modifiable software for the system to be certified

• Examine the certification criteria for architectural and methodological strategies used to reduce the software level or to provide verification coverage, for example, partitioning and dissimilar software

• Examine configuration control guidelines, quality assurance guidelines, and identification conventions, and their compatibility with existing certification authority requirements for type certification, in-service modifications and equipment removals

• Consider the impact of new technology, such as modular architecture, data loading, packaging, and memory technology

• Examine the need, content, and delivery requirements of all documents, with special emphasis on the Software Accomplishment Summary

• Define and consider the interfaces between the software and system life cycles

• Review the criteria associated with making pre- and post-certification changes to a system

• Consider the impact of evolutionary development and other alternative life cycles to the model implied by DO-178A

This direction served as the charter for the team's activities; these terms of reference were reviewed, revised, and accepted by the entire Special Committee before being finalized. This helped to assure that the wording of this charge was understood and accepted by the members who would be implementing this mandate.

Working group responsibilities for developing content were defined

When dealing with hundreds of participants from many different sectors - regulatory agencies, airframe manufacturers, and suppliers - and many perspectives - systems engineering, quality assurance, software engineering, and management - it was necessary to organize committee activities into parallel groups. A working group structure was established so that participants could self-select where they could best contribute. Working group chairs were then selected who were committed to working together to resolve cross-group boundary issues, and who could provide the necessary leadership and guidance to help drive issues to closure within each of these sub-groups. I was the leader of the working group responsible for change management, coordination of key concepts, and integration of guidance.

Governance to manage information exchanges and decision-making was established

Governance is often an afterthought when groups are themselves developing?new governance. However, because of the number of people involved in developing and reviewing DO-178B, effective governance practices were essential to establishing trust and managing the evolution of the material being developed. A table of contents was established early on to describe the intended architecture of the document and provide a basis for assigning responsibilities to the working groups. A template for working papers was also established as a means to identify, track, and communicate progress on critical technical decisions within each working group over time, in a trade study like environment. Key concepts and features that affected multiple sections of the document were then identified, to ensure that agreed-to approaches for these concepts were developed before tackling other related issues. For example, the group wanted to avoid specifying any particular structure for required artifacts and documents that were to be produced during a DO-178B-compliant development effort, and instead of using these traditional artifact descriptors, made a conscious commitment to describe information in abstract containers that could be implemented in a variety of ways; this decision rippled through many other sections of the material that was developed. Finally, a means of identifying and tracking issues for existing content was established. This mechanism satisfied multiple purposes for the teams' authoring efforts and served as problem reports, change requests, and requests for the resulting information. The communications, tracking, and disposition of these issues were provided centrally in support of all working groups as a service for all participants.

A terminology foundation was documented and maintained

Different groups, and individuals from different backgrounds, often use this different wording in developing content they are familiar with, even though they had the same underlying meaning in mind. These same groups, in somewhat different circumstances, may also use the same wording even though they intended their wording to mean different things. Such communal differences needed to be resolved in order for the resulting guidance which they produced to be coherent.

As a classic example, consider the terms 'verification' and 'validation', which traditionally have many different definitions and interpretations. In DO-178B, verification is defined to be the 'evaluation of the results of a process to ensure correctness and consistency with respect to the inputs and standards provided to that process'. In DO-178B, verification is one of the integral processes (configuration management, quality assurance, and certification liaison), which means it cuts across all the development processes, rather than being a serial activity which begins after a predecessor activity. Validation is defined as 'the process of determining that the requirements are the correct requirements and that they are complete'. Since validation is considered a system-level activity, it is not explored further in DO-178B. Definitions such as these form a solid foundation which is used to tie the other sections of DO-178B together but need to be established upfront so that the content built upon these definitions could be integrated together with a minimum of rework.

Such verification is a part of the checks and balances which DO-178B provides to protect against mistakes. Additional protection is required when this verification must be performed independently, which is defined in DO-178B as follows:

Separation of responsibilities which ensures the accomplishment of objective evaluation. (1) For software verification process activities, independence is achieved when the verification activity is performed by a person(s) other than the developer of the item being verified, and a tool(s) may be used to achieve an equivalence to the human verification activity. (2) For the software quality assurance process, independence also includes the authority to ensure corrective action.

Once definitions such as the above were established, key concepts could then be built from this foundation. As an example, consider the document's treatment of software requirements, which are described as "a description of what is to be produced by the software given the inputs and constraints". They take two forms in DO-178B: 'high-level' and 'low-level' requirements. High-level requirements are defined as "software requirements developed from analysis of system requirements, safety-related requirements, and system architecture", and low-level requirements are defined as "software requirements from which source code can be directly implemented without further information". This definition can obviously be interpreted differently (and thus require further elaboration of low-level requirements) when applied to a new-hire and an experienced engineer, which could drive up costs unnecessarily if this elaboration proves unnecessary once the coding responsibility is assigned. The importance of independence in verification is also highlighted in this situation to ensure that the low-level requirements are taken to the required level.

Development process objectives and interfaces were baselined

Compliance with DO-178B is intended to establish confidence in the activities used to develop safety-critical software and assuring that these activities are producing information suitable for certifying the systems in which the software is embedded within. DO-178B's life-cycle processes are not intended to prescribe or limit the structure of the actual development processes which are put in place by development organizations; instead, the processes described in DO-178B are a descriptive vehicle for communicating expectations about the activities actually performed during development. While these actual activities may take many different forms, DO-178B defines its own set of software life-cycle processes so the actual activities can be traced to the DO-178B processes.

A set of objectives for the DO-178B lifecycle processes are also defined. These objectives define the 'intent' behind these processes and thus describe the value which each of these processes is expected to produce, in a manner like how a judiciary may consider legislative intent in determining their rulings. The objective evidence necessary for demonstrating that these objectives have been accomplished is also described. For example, testing objectives are defined as showing that requirements are fully satisfied, and demonstrating 'with a high degree of confidence that errors which could lead to unacceptable failure conditions... have been removed'. There are obviously many different approaches that can be employed to achieve such objectives, but the proof of their pudding is whether they satisfy these objectives or not. DO-178B objectives also help verify the correct implementation of safety-related requirements that flow from the system safety assessment.

Compliance data is intended to be produced as a natural product of these activities, but unlike many other standards, DO-178B does not prescribe how these activities should be structured. Interpretation and judgment need to be applied in determining the activities and deliverables appropriate to each situation in order to satisfy both DO-178B process objectives and criteria, as well as any business objectives that must also be satisfied (which are outside of the scope of DO-178B).

An evolutionary development plan for the document was outlined

Concepts in any standard need to be developed and communicated in an organized and sequenced fashion so progressive elements can be used to develop the reader's understanding as the document unfolds. A top-level document structure was derived from a consensus view of how certification programs would be described. An outline of the overall document was established, and target page counts were established for different sections, with the overall objective of keeping the length of the document to approximately 75 pages. The thinking was that more writing does not generally lead to clearer writing.

This content for this structure had to be developed incrementally by the responsible workgroups, and this material thus evolved over many meetings in which the working group members held the majority of their team's interactions. As content for the document progressed through position paper development to working-group agreed-to proposals for content and presented that content to plenary, it was apparent that the underlying concepts often did not yet 'stand-alone', and had to be explained by the working group chairs to the rest of the plenary members.

For example, a key change was made in DO-178B in how requirements for software verification were to be defined, with a greater emphasis on requirements-based testing than in DO-178A. This change was intended to discourage the practice of focusing software testing primarily to achieve structural (i.e., White-box testing) coverage, at the expense of fully testing functional and performance requirements. Requirements-based testing - augmented by a determination of the structure coverage achieved by these functional tests - is a more cost-effective and meaningful way to conduct such verification testing.

The emphasis on requirements-based testing resulted in a new and significant focus area in DO-178B, which expects consistency between requirements, code, and the tests that verify that the code satisfies the requirements. Traceability is often used to provide evidence of this consistency and completeness, and such traceability is required to be thorough and bidirectional, demonstrating that requirements trace forward to code and tests and satisfy requirements, and trace backward from tests to code and to the requirements for which the tests were created. At the higher levels of safety and criticality, DO-178B requires that this traceability evidence show 100% structural code coverage. These concepts were each developed within different working groups and were only able to achieve consensus after multiple iterations in the document test - to introduce the idea, integrate its expression, and mature its elaboration. A roadmap of these concept developments and refinements over time (which initially were communicated in the form of working group papers) was helpful to begin developing realistic projections for how long DO-178B would actually take to complete.

A repository was established for sharing information and status

An accessible means of exchanging and providing access to information was put in place to support the committee activities. This mechanism helped improve configuration control of document elements, provided protected access to working groups for the working group papers that were not ready for broader review, and helped build a community of practice to identify concerns and leverage community knowledge in trying to address them. The repository that was established was funded in a creative manner, with software licenses paid by one airframe manufacturer, the hardware paid by another, and the server and associated operations provided by a university that was actively involved in the committee activities. This repository has been so useful that has been upgraded many times and remains in use today.

An editorial team was established to integrate content into a coherent product

While the content of the document was developed by many individuals, it was important for the resulting integrated content to be written as if it had been the work of a single author. Since the document was to be international (and would thus need to be translated into other languages), care needed to be taken to assure that the language and structure of the document were amenable to this translation and that it could be accomplished without changes in the underlying meaning. As an example, the process of progressively refining requirements was described by some authors as 'decomposing requirements', but such terminology, while often used within the United States, would not translate well into French (essentially becoming 'rotting requirements'. Finally, the team needed to establish trust with the original content providers, who wanted the intent of their original writing to be preserved. Over time, what this meant was that responsibilities for the document sections transferred from individual working groups to the editorial team for final integration.

A formalized review process was employed to assure quality criteria were realized

The editorial team employed a structured review process, including a specific checklist designed for such reviews. As these reviews identified issues with the document, the working groups were initially responsible for addressing these issues and determining if the resolution required a change in a technical concept, or how it was explained. As the document entered its final form, change authority was delegated to a smaller number of individuals, to make sure the tone and style were consistent, as the number of ‘must fix’ open issues was driven to zero.

Results

Work on position papers for the document began immediately after the first meeting, using the working group structure that was established in plenary sessions. The first drafts of DO-178B began to be produced in 1989. Work continued through quarterly meetings, with the intervening publication of document updates, exchanges of issues and working group papers, and progressive refinement and convergence on the agreed-to guidance. The final release was adopted in 1992 after the responsibility for the document text was transferred to an editorial board. This team, with representatives from other working groups, conducted intensive sessions to thoroughly review the document, reconcile outstanding issues, and prepare the document for publication. The resulting product has achieved wide acceptance and remains in active use after over thirty years on all new and derivative commercial aircraft developments around the world. The document's usability, clarity, and compatibility with other standards have been well received.

This is one of the proudest accomplishments in my career. I served as the document’s architect, led the editorial group’s efforts to integrate the text produced by all the working groups, and massage their drafts into a holistic document. I received this much-appreciated note (Figure 2) from the overall cochair of the effort acknowledging my contributions:

A new revision, DO-178-C, was initiated in March 2005 and was completed in 2013. Refinements clarified and refined the definitions and boundaries between the key DO-178B concepts of high-level requirements, low-level requirements, and derived requirements, and incorporate the exit/entry criteria between systems requirements and system design (described in ARP-4754A). Since this material has now been widely used in practice for over thirty years, the above practices collectively offer advantages over less formalized approaches that have been used in other standards efforts but are applied in practice very infrequently.

Practices are only effective when used by the right people and the leaders and contributors to DO-178B can remain proud of their contributions to the practice of software engineering in safety-related systems. The above practices are offered in the hope that this evolution can produce a similarly enduring legacy in future work.

One of Steven Covey's Seven Habits is to 'Seek first to understand, and then to be understood.' Action without understanding will inject chaos, not reduce it. But achieving an understanding of any topic requires us to probe much deeper until we have considered and accepted the viewpoints of all parties for the presenting circumstances.

We must engage with intellectual precision—diagnosing situations, surfacing constraints, and grounding our actions in relevant knowledge. Only then can better outcomes emerge from informed choices.

The roots of understanding

Epistomology is the branch of philosophy that examines the nature, origin, and limits of knowledge. According to Agnes Callard, knowledge is simply the name for an answer that is the product of a completed inquiry into a question. As Figure 1 indicates, it connects observations with meaning and draws on knowledge to navigate through courses of action.

This makes understanding a prerequisite for effective action. Actions to build understanding are exploratory probes into chaos, a necessity chock full of learning opportunities. And understanding is subject to many influences that may skew interpretations and contaminate behaviors, especially when coordination is required.

Understanding, acceptance, and support

When such understanding is required across a diverse community of practitioners, rather than just from a few selected individuals, it becomes more difficult to dictate that they adopt proper behaviors. Culture rules. Each member of culture brings their own expectations, beliefs, ceremonies, and traditions which they have adopted through their experiences. No amount of explanatory power is likely to win them over from that viewpoint. Callard again: “… you learn what you really understand, and what you only appeared to yourself to understand, when you put your supposed knowledge to the test by trying to explain it to someone.”

Inevitably, in navigating this terrain, tensions reveal themselves through competing cycles of:

• scope-driven investment decision allocating resources among competing demands:

• iterative, time-boxed activities producing viable work products

• cultural responses to learning opportunities shaped by the perceived fitness of the endeavor

• responsively adapting to shifting environments

Without adaptive control tied to first principles, performance may oscillate painfully - especially in periods of decline. Yet even then, outsized rewards remain possible, albeit at the cost of tough decisions and daring commitments.

Yet even in decline, big rewards are still possible, though achieving them will require commensurately painful decisions, actions, and risks. These factors amplify the cone of uncertainty around target outcomes that waxes and wanes in two separate waves. The first results from individual engineering and construction projects of any meaningful size and complexity. There will inevitably be winners and losers that result from these decisions. Yet inevitably, the routes over which future value can be accessed must be concentrated for growth to be economically viable. Arthur M. Wellington eloquently described the challenges of such decisions in his classic 1887 work, The Economic Theory of the Location of Railroads:

The correct solution of any problem depends primarily on a true understanding of what the problem really is, and wherein lies its difficulty. We may profitably pause upon the threshold of our subject to consider first, in a more general way, its real nature: the causes which impede sound practice; the conditions on which success or failure depends; the directions in which error is most to be feared. Thus we shall attain that great perspective for success in any work a clear mental perspective, saving us from confusing the obvious with the important, and the obscure and remote with the unimportant.

Wellington's focus on outcomes, constraints, priorities, and risks requires understanding the concepts of operations for the domains of interest. Immanuel Kant described the power of abstractions in laying a foundation for such understanding:

In order to make our mental images into concepts, one must thus be able to compare, reflect, and abstract, for these three logical operations of the understanding are essential and general conditions of generating any concept whatever. For example, I see a fir, a willow, and a linden. In firstly comparing these objects, I notice that they are different from one another in respect of trunk, branches, leaves, and the like; further, however, I reflect only on what they have in common, the trunk, the branches, the leaves themselves, and abstract from their size, shape, and so forth; thus I gain a concept of a tree.

Abstractions and pattern recognition are innately linked. Generalizations of properties help us systematically develop and verify hypotheses of the connections between causes and effects. Unfortunately, these generalizations may not serve us by recognizing points of light as distant galaxies, rather than as asterisms that fit well with our popular narratives. Distractions abound, ideas are cheap, hindsight is biased, and information needed for proper decision-making may often be inaccurate or just plain unavailable.

Visionary early adopters need more than platitudes and good attitudes, especially when skeptics resist advice that is contrary to their traditions. In cultures of high resistance, change agents are grossly outnumbered. Stakeholders who are under pressure are more likely to fall back on historical patterns, even after they are no longer acceptable. Those behaviors have built their reputation and world view within their community. To satisfy the expectations of some new role, these actors must understand and accept the new actions they will be responsible for, and support the necessary interfaces with others, so improved outcomes can be achieved. Unfortunately, when reality is viewed through their lenses, causes and effects are often disconnected in time from context.

Incentives for faking it

Often leaders are infected by reality distortion fields or magical thinking. Instead, leadership must shape the environment in which the communities making up this culture operate and provide them with the necessary ingredients for change. Change agents can then define a set of objective criteria by which success will be measured and facilitate charting a course towards satisfying those criteria, and their realization, consistent with an elaboration likelihood model. Their collective beliefs may be logically inconsistent with rational analysis; nevertheless, those assigned to new roles must embrace their responsibilities and agree to support each other in making the necessary transformations. Hopefully, these require steps, rather than leaps, of faith.

In his book Balancing Agility and Discipline, Barry Boehm describes the underlying root causes of such uncertainty:

• ambiguity about the nature of the problem(s) that should be addressed

• risks about the implementation of candidate solutions

• unreconciled misunderstandings and flawed assumptions

• unknowns about what options will be available in the future, and what environment they should be evaluated within

Though this uncertainty is often masked, projects may be not much more than a bundle of ideas that have attracted the attention of decision authorities. They may choose a fork in the road after trying other options and discovering they did not adequately understand the future they were getting themselves into. In such situations, the information will always be incomplete, and decisions will always be temporary. The causal chain between desirable effects and underlying upstream decisions may not be immediately apparent, even when the facts are known. Projects are always having changes in leadership, structure, or available resources. The longer the projects are, the greater the number of events that must be successful, and the more likely it will be that gaps in performance will creep in.

Sponsors usually must choose from many different potential investment opportunities, each promising predictability and clamoring for precious resources, and presuming that all resources are interchangeable and offer similar value creation over the long term. To minimize their exposure to Parkinson's law, leaders strive to bound these sources of uncertainty, striving to achieve as predictable a set of outcomes as possible. If project outcomes were indeed normally distributed in such portfolios, it would be possible to dial in historical data and the risk tolerance sponsors were willing to absorb. But individual project outcomes are more likely to follow heavy-tailed distributions, with many underlying causes, from sparse or unreliable historical data to unfamiliar execution environments.

Oversimplification of reality

A further complication arises when this uncertainty arises when a common set of root causes are threaded through multiple projects in a portfolio. These root causes form a common failure mode across these projects that can be self-reinforcing. As an example, stakeholder's mental models inevitably are simplifications of the diverse realities in which projects must be executed. Ideally, the highs and lows of this uncertainty would be offsetting. Steve McConnell believes that teams are more likely to commit to more than they can deliver because people have an innate desire to please. The laws of physics and lessons of history are inevitably stronger than the enthusiasm of change agents and the ambitions of project advocates. Yet unless such underlying root causes for failures can be recognized and confronted, these failure modes are likely to amplify the underlying uncertainty that typically emerges individual projects themselves.

This over-simplification is an essential property of environments that are exposed to changing circumstances. Even though problems, concepts, or ideas have been embraced by stakeholders, their actual definition may not be actionable despite prior commitments to action. In these situations, each stakeholder may have their own mental models of what these abstractions mean and are likely to each adopt the interpretation most useful to them or their organizations. The systems' implications of these models may not be apparent.

Phillip Tetlock, author of the book Superforecasting, provides us with a disturbing example of the fuzziness of the lines we draw between which emerging conditions are significant and which can be overlooked:

In March 1951 National Intelligence Estimate (NIE) 29-51 was published.? "Although it is impossible to determine which course of action the Kremlin is likely to adopt," the report concluded, "we believe that the extent of [Eastern European] military and propaganda preparations indicate that an attack on Yugoslavia in 1951 should be considered a serious possibility." ...

But a few days later, [Sherman] Kent was chatting with a senior State Department official who casually asked, "By the way, what did you people mean by the expression 'serious possibility'? What kind of odds did you have in mind?" Kent said he was pessimistic. He felt the odds were about 65 to 35 in favor of an attack. The official was started. He and his colleagues had taken "serious possibility" to mean much lower odds. Disturbed, Kent went back to his team. They had all agreed to use "serious possibility" in the NIE so Kent asked each person, in turn, what he thought it meant. One analyst said it meant odds of about 80 to 20, or four times more likely than not that there would be an invasion. Another thought it meant odds of 20 to 80 - exactly the opposite. Other answers were scattered between these extremes. Kent was floored.

Despite such uncertainty, organizations must institutionalize learning across projects so the impacts of these systemic risks can be reduced, and long-term behavioral improvements can be realized.

Collective learning

Peter Senge describes the landscape in which this collective learning must unfold. The simplest form of Senge's organizational learning is called single-loop learning and involves providing appropriate feedback to members of an organization within their established, accepted, prescriptive practices. A more powerful form of learning is called double-loop learning and requires teams to recognize and reflect on the patterns of behaviors that arise under particular circumstances. Double-loop learning is particularly important in influencing teams to 'learn how to learn'.

In their book Becoming a Learning Organization, Swieringa and Wierdsma introduced an even more advanced concept they called ''triple loop learning'' (Figure 2), which involves an open inquiry into underlying why's “…that permits insight into the nature of the paradigm itself.” Research has subsequently highlighted that there are many different interpretations of this concept, though providing adequate justification for believing the change is likely (rather than just possible) would seem essential.

To create such an environment, actors must have opportunities to learn in a variety of situations and understand the behaviors they produce adequately so that causes can be connected to effects, and more informed decision-making can be orchestrated. As figure 3 shows, research in experiential learning has demonstrated that knowledge transfer in the form of oral presentations is effective less than 20% of the time. By creating situations in which students are more engaged in their learning experiences, the likelihood of successfully transferring knowledge can increase to an average of about 50%. But when students can learn by doing (and especially by deciding) and are presented with opportunities to try out ideas in a safe environment, the odds of knowledge transfer nearly triple from what is expected from a passive receiving experience.

As Ray Madachy, the author of the book Software Process Dynamics, observes:

For organizational processes, mental models must be made explicit to frame concerns and share knowledge among other people on a team. Everyone then has the same picture of the process and its issues. Senge and Roberts provide examples of team techniques to elicit and formulate explicit representations of mental models. Collective knowledge is put into the models as the team learns. Elaborated representations in the form of simulation models become the basis for process improvement... Models can be used to quantitatively evaluate the software process, implement engineering, and benchmark process improvement. Since calibrated models encapsulate organizational metrics. organizations can experiment with changed processes before committing precious resources.

Call to action

Understanding is not a one-time insight but an ongoing discipline. In communities where culture rules and constraints compound, the only path forward is through shared inquiry. So the next time you’re ready to prescribe a fix, ask instead: What’s being asked of me? Because action without understanding is like engineering without measurement: ambitions without achievements.

Coming attractions

The articles in this series demonstrate the potential power of using management simulations to provide just such a capability. These simulations can be helpful in aligning the unique perspectives of stakeholders and give them opportunities to try out alternative decisions in realistic project situations. This gives these stakeholders opportunities to connect the dots across time and space. Each article walks through a scenario that is relevant to systems and software engineering practice and provides a series of 'runs' which reveal the performance of the simulation over a project's lifecycle. Team members can interact with these simulations at discrete time intervals that align with typical decision points, rather than trying to connect cause and effect across selected periods. Simulation participants can also be organized into small teams to introduce competition into the exercise and give each of these teams the opportunity to collectively talk through what they believe is happening, based upon the simulation outputs within that session.

Others in this series

In 1997, James Collins wrote Built to Last, which went on to become an immediate classic on corporate strategy. It focused on eighteen noteworthy companies (all within the United States) that had each survived for over one hundred years at the time of the book's publication. When Built to Last was published in 1997, it promised strategic permanence through shared corporate behaviors. But by 2007, half of its exemplary companies had faded from prominence. The prescription, while well-meaning, now reads more like cargo cult programming, imitating past success without adapting to future demands.

The need for adaptation

Long-lived businesses don’t simply endure—they continuously redefine themselves. Failing to adapt erodes focus and responsiveness, trapping organizations in past successes that no longer apply. This erosion crosses sectors, affecting entrepreneurial ventures, industrial giants, and public institutions alike.

Consider Microsoft and Kodak between 1985 and 2005: both faced digitalization, globalization, and the collapse of legacy channels. One recalibrated, the other clung to its film roots. The divergence underscores that survival favors those who evolve, not those who presume past relevance guarantees future viability.

It’s understandable for successful organizations to resist change—especially when prior methods delivered results. Yet the conditions that made those strategies effective may no longer exist. Change demands not just recognition, but intentional resource allocation and sustained focus. Meanwhile, legacy operations continue demanding attention, often crowding out the capacity for renewal.

Shared principles of successful companies

I am lucky enough to work in the Puget Sound area, which is home to four premier companies in their respective industries. Surveying the principles of these companies, one is struck by how similar their intentions are:

Customer-Centricity

• Boeing: Commitment to safety, quality, and reliability in aerospace products.

• Microsoft: Innovation and collaboration to deliver value to users.

• Costco: Building customer loyalty through consistent value and service.

• Amazon: Customer obsession, starting with the customer and working backward.

Operational Excellence

• Boeing: Strong focus on compliance, ethics, and environmental responsibility.

• Microsoft: Driving clarity, energy, and success through leadership.

• Costco: High sales volume and low margins for operational efficiency.

• Amazon: Ambitious standards and ownership to ensure excellent outcomes.

Innovation and Growth

• Boeing: Aerospace innovation to connect, protect, and inspire the world.

• Microsoft: Fostering a growth mindset and encouraging adaptability.

• Costco: Using a membership-based model to drive consistent growth.

• Amazon: Encouraging invention and simplifying processes.

Employee Focus

• Boeing: Commitment to employee safety and ethical working conditions.

• Microsoft: Prioritizing employee well-being and development.

• Costco: Competitive wages, benefits, and internal promotions.

• Amazon: Ownership mentality and promoting ambitious standards.

Sustainability and Long-Term Thinking

• Boeing: Environmental stewardship and values-driven governance.

• Microsoft: Strategic partnerships for collaborative success.

• Costco: Commitment to low prices over the long term.

• Amazon: Prioritizing sustainable growth over short-term gains.

So how can such organizations effectively pursue such long-term intentions, while meeting demands imposed by short-term commitments?

The difficulty lies not in the new ideas, but in escaping from the old ones. - John Maynard Keynes, 1935

Things do not become faster, better, or cheaper by osmosis, patience, or cheerleading, but by learning the basics of execution discipline. As Complein reminds us:

The organization of any major human endeavor follows basic laws of efficiency of communication, span of control, xenophobia, specialization, and other sociological forces that drive similar undertakings to implement similar practices and structures. Systems of nature have common rhythms and trends that underlie their emergent complexity. These properties come from the structure of their organization: the deeply held relationships that define the organization as a social entity.

Clarifying performance objectives

To demonstrate the challenge of balancing these needs, consider which goals deserve what emphasis among options for customer satisfaction, speed, agility, or discipline? The answer should be simple - speed is everything since it provides the key to unlock the other goals by facilitating more rapid learning. Yet while everyone may want to operate faster, speed doesn't just emerge from such desire, and speed without discipline just produces waste faster.

According to Donald Schon, the systemic changes required to improve performance will not necessarily be obvious from inside the organizational constructs that people perform their work within:

Russell Ackoff recently announced to his colleagues that "the future of operations research is past" because "managers are not confronted with problems that are independent of each other, but with dynamic situations that consist of complex systems of changing problems that interact with each other. I call such situations messes. Problems are abstractions extracted from messes by analysis; they are to messes as atoms are to tables and charts... managers do not solve problems: they manage messes".

Problems are interconnected, environments are turbulent, and the future is indeterminate just in so far as managers can shape it by their actions. What is called for, under these conditions, is... the active, synthetic skill of "designing a desirable future and inventing ways of bringing it about". Engineers encounter unique problems of design and are called upon to analyze failures of structures or materials under conditions which make it impossible to apply standard tests and measurements.

Practitioners are frequently embroiled in conflicts of values, goals, purposes, and interests. Each view of professional practice represents a way of functioning in situations of indeterminacy and value conflict, but the multiplicity of conflicting views poses a predicament for the practitioner who must choose among multiple approaches to practice or devise his own way of combining them.

To accelerate learning across this landscape is to embrace the transparency necessary to build trust and generate a business model that is explainable, realistic, and sustainable. Since any organizational structure or culture is resistant to change, elements of the existing structure must be dismantled, then re-formed to naturally flow from and work with (rather than against) Complein's laws. The newly formed units can then begin to align their investment strategies, organizational structures, and resource allocations with this business model across all levels of the organization.

Framing the target end states

The next step in successfully performing such pivots requires defining a clear, robust, and measurable set of goals that frame the target end state and characterize the new behaviors which must be in place to realize it. Mark Pincus, the co-founder of Zynga, has said that not having clear and actionable goals can lead to death by a thousand compromises. Goals should delineate real choices made by the organization and intended to be supported by their members, rather than just regurgitating nebulous slogans without elaboration.

As the scale and complexity of a business increases, the robustness of the activities 'on the ground' necessary for meaningful progress becomes increasingly critical. Realizing such goals over multiple business cycles requires interpreting them within the context in which they are to be applied and applying a foundational set of disciplines for such goals to be realized. Most organizations, unfortunately, focus instead on only the visible aspects of projects, such as appealing new features. This can distract them from considering the invisible aspects - like outdated architecture and technical debt - which can sap the energy from the team creating and supporting new features and make it harder to realize value for everyone.

The need for discipline

The word discipline is a synonym for many related concepts, including governance, best practices, and process improvement. Each of these interventions inevitably rests on the ability to introduce behavioral changes which will influence the way work is performed. These behaviors may need to be shaped at many distinct levels. Any large organization is likely to have evolved into a mix of many different work cultures; each may consider themselves disciplined within their local context. Economist Thomas Sowell identifies the crucial aspect of knowledge exchanges across these boundaries:

Economic transactions are purchases and sales of knowledge. Even the hiring of an "unskilled" worker to pump gas involves the purchase of a knowledge of the importance of dependability, punctuality, and an ability to get along with customers and co-workers, quite aside from the modest technological knowledge required to operate the gasoline pump. The abstract existence of knowledge means nothing unless it is applied at the point of decision and action.

More complex operations obviously involve more complex knowledge-often far more complex than any given individual can master. The person who can successfully man a gas pump or even manage a filling station probably knows little or nothing about the molecular chemistry of petroleum, and a molecular chemist is probably equally uninformed or misinformed as to the problems of finance, product mix, location, and other factors which determine the success or failure of a filling station, and both the manager and the chemist probably know virtually nothing about the geological principles which determine the best way and best places to explore for oil-or about the financial complexities of the speculative investments which pay for this costly and uncertain process.

We are all in the business of selling and buying knowledge from one another, because we are each so profoundly ignorant of what it takes to complete the whole process of which we are a part.

The foundational disciplines required for building products will vary significantly depending upon the nature of the product itself. For example, a chemical engineer, a building contractor, and a software designer must each have insights into the decisions and work products required within their specialization. Yet when a particular statement of work requires interdisciplinary cooperation, the potentially competing perspectives of their different disciplines must dive into details meaningful to specialists in limited supply, such as chemical bonds, material properties, and optimal algorithm selections. These individual pieces need to interact effectively to deliver the functionality and performance which is required overall.

Constructs for improvement

Several patterns are common to how resources can be employed to pursue enhanced performance. The most frequently used constructs within this environment are:

• Process action teams, in which participants are expected to carve out time from their primary assignments to craft appropriate governance for the broader community; unfortunately, since participation is temporary, momentum is difficult to establish and sustain.

• Functional organizations that are chartered to provide 'bench strength' when projects run into problems; unfortunately, if the bench is that good, they should be starters.

• Communities of practice, which attempt to self-organize within their available bandwidth to promote whatever they see in their best self-interest. Their rallying cry is a demand for consensus so that they can block changes unfavorable to any part of the community

• Designated approval authorities who are expected to assure desired outcomes, without the ability to themselves dictate the means to those ends

• Dedicated subject matter experts who are positioned to? launch of new projects, to make sure they are on the right path

• Consultants who have less invested in outcomes than those they advise

These interventions share similar challenges in changing existing cultures - how to transfer know-what and know-how to groups that are likely to view any imposed discipline as unnecessary, misguided, or irrelevant to their situations. These postures are unfortunately often adopted in response to some crisis, and with 20-20 hindsight may receive a mandate to address the immediate symptoms of the problem, rather than making a long-term commitment to curing their root causes. Most recruits into crisis management are fire-fighters; unfortunately, while they are in the middle of fighting one fire, more fires inevitably ignite and spread.

Visualizing the changes required

Here’s a three-step approach - grounded in project-management gap analysis and behavioral-science research and consistent with the PIANOS model - for both measuring and then visualizing the intention–action gap in live projects:

1. Quantify the Gap

   1. Time-Lag Measurement:
      • Timestamp every new intention (e.g. idea logged, meeting decision) and record when the first tangible action occurs. Over a cohort of intentions, you can calculate median, variance, and trends of “execution lag”.

   2. Completion-Rate Measurement:
      • For each intention, track “acted-on” vs “abandoned.” The ratio (actions ÷ intentions) over a fixed window becomes your Action-Conversion Rate.

   3. Outcome-Metric Gap:
      • Use classic gap-analysis by defining your desired performance measures (e.g. features delivered per release, compliance tasks closed), measure actual performance, and compute the delta.

2. Diagnose Root Causes
   For each intention that stalls, evaluate whether the issue stems from lack of skill, will, or support using quick “post-mortem” surveys or team retrospectives. This lets you see which barrier most often derails execution. Target solutions - training, incentives, or structural changes - via intervention design.

3. Visualize for Insight & Action

   1. Delay Histogram or Box-Plot:
      • Plot execution lag distribution to spot outliers and the “bulk” of your delays.

   2. Burn-Up Chart Overlay:
      • On your endeavor’s burn-up chart, add a second line showing “intentions logged.” The vertical gap between lines at any date is your live intention–action backlog.

   3. Sankey Diagram:
      • Map “intentions” flowing into three bands—acted on, flagged for K/M/O causes, or dropped—using width to show volume leak.

   4. Heatmap Matrix:
      • Rows = by responsible unit; columns = gap type (time-lag, conversion-rate, KPI). Use color‐intensity to highlight worst offenders.

   5. Kanban-Style Cumulative Flow:
      • Add an “Intention” column before “To-Do” and measure how long cards linger there. The thicker that column, the bigger your upstream gap.

Consider tying these visuals into your regular stand-ups or dashboards so the team constantly “sees” where intentions stall and can swarm to close those gaps.

Call to action

When combinations of these strategies are employed, many leaders (already challenged by limited attention spans to address another fire) delegate the coordination responsibilities necessary for meaningful changes to stick. Yet when the structure of the organization itself is problematic, such delegation may just add noise and obfuscate the underlying root causes and thus block change (while delaying their resolution). As Steve Jobs would say, such people need to think and act differently, not just talk and talk.

Organizations must regularly recalibrate what they do—not just what they say they intend to do. Success is sustained not by clinging to legacy, but by confronting the friction between mission and motion. It’s time to reexamine the story we tell ourselves and ask: are our behaviors aligned with what today demands?

Leadership is the ability to influence others in ways that enable them to accomplish desired results. Organizations need leaders at many distinct levels. Everyone must tailor their leadership approaches to each unique situation that they are presented with, and measured by the traction they generate.

Some leaders may inherit positional authority from their place in the organization. Other leaders must instead achieve results through alternate means. The first of these is the ability to influence or gain cooperation from others through persuasion or rewards. The second is power, which is a stronger form than mere influence; power means you can enforce actions through consequences resulting from accountability.

The ability to exert leadership relies on which of these relationships can be accessed. Any leader must lead followers, and these followers must share knowledge, beliefs, and values for a leader to develop and extract value from these relationships. These relational attributes collectively form the glue that binds a workgroup together into an interdependent whole.

As a result, a leader's destiny is often determined by the environment that has been built for this foundation. The success of this foundation relies on the following factors:

• Purpose - the community's pride of accumulated accomplishment and the values they believe that enabled those achievements

• Direction - the changes the leader and team members feel are essential for their success, survival, and growth

• Commitments - the active involvement by team members in shaping the outcomes they are expected to pursue

• Ways and means - the interactions between key roles and processes that are essential to achieving those outcomes

• Norms - the community's standards and expected behaviors that all team members agree to be held accountable to

• Priorities - an awareness of the specific actions that must be done next, by whom, and by when for commitments to be realized

• Authority - a clear delineation of who can make decisions and how decision-making boundary disputes will be resolved

• Reporting - how information and status will be shared and represented

• Backing - a sense of whether the leader will go to bat for the team when they need it

Whenever this foundation is incomplete, a leader must help to resolve these gaps, while concurrently minimizing the impact of these gaps. Once this foundation is in place, a leader's work has just begun. Each team member still needs to be motivated to act, even though the carrots and sticks which provide this motivation may vary over time and across individuals. These motivations include:

• a desire for popularity and the respect of their peers

• a personal commitment to excellence

• personal ambition

• a need for employment security

• financial incentives

• personality tendencies (for self-glorification, criticism, etc.

• fear of failure

Experienced project leaders also recognize and help to correct any ineffective behaviors that people may exhibit because of their history, attitudes, or situations. These ineffective behaviors can include:

• stalling, bluffing, or making excuses

• making false or misleading statements

• resorting to unreasonable appeals to higher authorities

• adopting passive/aggressive behaviors

• employing direct frontal assaults on, or authority challenges to the leader?

• engaging in entrapment, smear tactics, or appeasement

Experienced leaders don't launch a counterassault when people use such tactics. Instead, they seek to broaden the collective understanding of the situation and learn how to deal with it constructively. This learning usually focuses on preventing problems before they occur. Proactive efforts to do this usually draw from effective strategies such as:

• introspection into the underlying root causes of process or quality problems

• coaching team members on improved discipline, work habits, and reinforcement of desired behaviors

• sharing perceptions of reality and connecting with available facts and data

• maintaining a consistent focus on the most important requirements and objectives of the effort (including the ability to rapidly reallocate resources to the corresponding most important tasks)

• adopting effective decision-making techniques

• developing an ability to anticipate, understand and address risks and system constraints

A project's success does not hinge on whether these strategies are checked off by players as something they support. Indeed, in large projects, such practices will usually be evident to one degree or another, depending upon the situation and people involved. And people need to believe in the endeavor, and to be nurtured, coached, and motivated to pursue excellence.

Rather, the realization of success relies upon both the consistency and effectiveness of the execution of these strategies over time and how well each team member's insights can be utilized in helping the group shape its own destiny. When this can be done, it imparts a degree of control to the team, which is especially important when trust or respect has been broken in the past.

For example, it doesn't matter whether requirements are used or not, if they are the wrong requirements, or if they are not useful to the team who must try to implement them. It doesn't matter if risks are tracked or not unless they are legitimate threats to the endeavor (vs worries). Everything else is often just going through the motions.

As a result, each project leader's primary mission should be to establish clear expectations about behaviors, help resolve the most serious risks, and actively remove the roadblocks that obscure progress, so team members can achieve desired outcomes in practical ways.

1. Inadequate linkage between the project and the broader organization's key strategic priorities, including agreed-to measures of success.

2. Insufficient involvement by senior management and business ownership and leadership.

3. Ineffective engagement with stakeholders.

4. Limited experience with effective project management and risk management approaches.

5. Too little attention to elaborating development and implementation strategies into manageable steps.

6. Premature evaluation of proposals with a focus on initial price rather than long-term value (especially with respect to securing delivery of needed business benefits).

7. Ineffective communications between the suppliers of technology across the projects.

8. Lack of effective project team integration between clients, the supplier team, and the primary responsible organization.

Consider Figure 1, which is an artist's depiction of the frequency and position of urban crimes in South London, Manchester, East London, and Eindhoven. Each individual occurrence of violent crime in each area adds to the height of the model at that location. The result forms a mountainous terrain of the variation which the locations have in these crime incidents. Such variation is the nature of statistical populations and how they differ, even in similar environmental conditions. This variation is a challenge to solution designers who are working to achieve the greatest good for such populations.

For an example drawn from the health care domain, consider this situation, discussed in Health Dialog:

If you live in northern Idaho, and you develop back pain, chances are good that you’ll undergo surgery to treat your pain. Move to the southern tip of Texas, however, and the chances that you’ll undergo that same surgery will drop by a factor of 6. The surgery is no more effective in Idaho than it is in Texas. It’s just that doctors in the northwest are more likely than those in southern Texas to recommend surgery. This phenomenon, in which doctors practice medicine differently depending on where they’re from, is called practice pattern variation. And it isn’t limited to treating back pain, or even surgical decisions.

The above situation is called unwarranted variation. It is only one of many distinct types of such variability, which arises from many diverse sources:

1. the presenting symptoms and their underlying root causes (which affects the frequency and complexity of encountering such situations)

2. the presenting conditions of the subject (i.e. medical history, the severity of illness, previous treatments, receptiveness to recommendations, etc.)

3. the novelty of the situation, and the resulting ability to use experience and draw from relevant knowledge during treatment

4. the individual skill and diligence of the treatment team

5. slips (making the proper decision regarding treatment, but making one of many missteps along the path of implementing that treatment) and mistakes (making the wrong decisions in particular situations)

We'd like to think that outcomes will be uniform, except for a few unusual cases. What we find instead is that distributions of outcomes follow one of several statistical distributions, with a handful of quite poor outcomes, a handful of exceptional outcomes (some that may appear miraculous), and a broad, undistinguished middle ground.

For example, according to the book Better:

• After an ordinary hernia operation, the chances a patient will have a recurrent hernia are one in ten in the lower group, one in twenty in the middle, and under one in five hundred for the top performers.

• For newborns admitted to Neonatal Intensive Care Units, the risk-adjusted death rate can vary between 6 and 16 percent, depending upon the hospital.

• The likelihood of successful pregnancy for in vitro fertilization varies from under 15 percent to over 65 percent, depending on where you go.

Within a particular diagnosis, differences of type 2 from the above list, combined with variations in the willingness of an institution to accept high-risk patients for treatment, will account for some of these differences, but many are simply due to the defect types 3-5, above. Over time, many of the sources of this variation can be identified and systematically reduced, but no member of the medical team is free from mistakes and slips; diagnostic errors average about 10%; errors in reading radiology films are well over twice that.

As described by Gawande:

In medicine, we are used to confronting failure; all doctors have unforeseen deaths and complications. What we’re not used to doing is comparing our records of success and failure with those of our peers. I am a surgeon in a department that is, our members like to believe, one of the best in the country. But the truth is that we have had no reliable evidence about whether we’re as good as we think we are. Baseball teams have win-loss records. Businesses have quarterly earnings reports. What about doctors?...

What one really wants to know is how we perform in typical circumstances—some kind of score for the immediate results, perhaps, and also a measure of the processes involved. For patients with pneumonia, how often does my hospital get them the correct antibiotic, and on the whole how do they do? How do our results compare with those of other hospitals? Gathering this kind of data can be difficult. Medicine still relies heavily on paper records, so to collect the information you have to send people to either scour the charts or track the patients themselves, both of which are expensive and laborious propositions.

Let's explore one disease, cystic fibrosis. This disease is infrequent, occurring in about 1000 patients per year, and given its low frequency (about 1 in every 3800 births), it is remarkable that we have made the progress that we have. Much of what we know and have accomplished with this disease is due to the diligence of the Cystic Fibrosis Foundation, which has been supporting research and patients for over 50 years. It has invested in countless research studies, helped decode the gene for the disease, and has underwritten countless innovations - new therapies, drugs, and devices. All of these could not have been done by themselves, but required a partnership with dedicated practitioners, working in a synergistic relationship. And their collective record of accomplishment of successes has been astonishing.

In 1957, the average patient with CF died by age 3. In 1964, the CFF gave a pediatrician at the University of Minnesota, Warren Warwick, ten thousand dollars to collect data on every patient at the thirty-one CF centers that year. Warwick discovered an example of positive deviance, a physician named Leroy Mathews at the Babies and Children’s Hospital in Cleveland. Leroy Mathew's patients had a median age at death that year of twenty-one years. Turning back to the book Better:

Unlike pediatricians elsewhere, Matthews viewed CF not as a sudden affliction but as a cumulative disease and provided aggressive preventive treatment to stave it off long before his patients became visibly sick from it. He made his patients sleep each night in a plastic tent filled with a continuous aerosolized water mist so dense you could barely see through it. This thinned the tenacious mucus that clogged their airways, enabling them to cough it up. Using an innovation of British pediatricians, he also had family members clap on the children’s chests daily to help loosen the mucus. After Warwick’s report came out, Matthews’s treatment quickly became the standard in this country. The American Thoracic Society endorsed his approach, and Warwick’s data registry on treatment centers proved so useful that the Cystic Fibrosis Foundation has continued it ever since. Looking at the data over time is both fascinating and disconcerting. By 1966, mortality from CF nationally had dropped so much that the average life expectancy of CF patients had already reached ten years. By 1972, it was eighteen years—a rapid and remarkable transformation.

At the same time, though, Matthews’s center had got even better. The foundation never identified individual centers in its data; to ensure participation, it guaranteed anonymity. But Matthews’s center published its results. By the early 1970s, 95 percent of patients who had gone there before severe lung disease set in were living past their eighteenth birthday. There was a bell curve, and the spread had narrowed a little. Yet every time the average moved up, Matthews and a few others somehow managed to stay ahead of the pack. In 2003, life expectancy with CF had risen to thirty-three years nationally, but at the best center it was more than forty-seven.

Today, cystic fibrosis patients get care at one of 117 specialized centers across the country, each having undergone a rigorous certification process, which assures that they follow the same guidelines for treatment, (which are far more detailed than for most other diseases). All these centers support ongoing research to find new and better treatments. Yet differences across treatment centers continue to be dramatic, especially considering the exemplar at the University of Minnesota. Returning, again, to Better:

The director of Fairview-University Children’s Hospital’s cystic fibrosis center for almost forty years has been none other than Warren Warwick, the pediatrician who had conducted the study of LeRoy Matthews’s suspiciously high success rate. Ever since then, Warwick has made a study of what it takes to do better than everyone else. The secret, he insists, is simple, and he learned it from Matthews: you do whatever you can to keep your patients’ lungs as open as possible. Patients with CF at Fairview got the same things that patients everywhere got—some nebulized treatments to loosen secretions and unclog passageways (a kind of mist tent in a mouth pipe), antibiotics, and a good thumping on their chests every day. Yet, somehow, everything Warwick did was different. Warwick's combination of focus, aggressiveness, and inventiveness is what makes him extraordinary. He thinks hard about his patients, he pushes them, and he does not hesitate to improvise.

Like most other medical clinics, the Minnesota Cystic Fibrosis Center has several physicians and many more staff members. Warwick established a weekly meeting to review everyone’s care for their patients, and he insists on a degree of uniformity that clinicians usually find intolerable. Some chafe. He can have, as one of the doctors put it, "somewhat of an absence of, um, collegial respect for different care plans." And although he stepped down as director of the center in 1999, to let a protégé, Carlos Milla, take over, he remains its guiding spirit. He and his colleagues aren’t content if their patients’ lung function is 80 percent of normal, or even 90 percent. They aim for 100 percent—or better. Almost 10 percent of the children at his center get supplemental feedings through a latex tube surgically inserted into their stomachs, simply because, by Warwick’s standards, they were not gaining enough weight. There’s no published research showing that you need to do this. But not a single child or teenager at the center has died in almost a decade. Its oldest patient is now sixty-seven. In medicine, we have learned to appreciate the danger of ad hoc experimentation on patients—of cowboy physicians. We endeavor to stick to established findings. But with his unblinking focus on his patients’ actual results, Warwick has been able to innovate successfully. And he has become almost contemptuous of established findings. National clinical guidelines for care are, he says, "a record of the past, and little more—they should have an expiration date."

This example highlights a dilemma of systematic improvement: If no one is free to innovate, or has the time to do so, little will change; but if everyone innovates independently, there will be no collective learning or systematic improvement. The key is to eliminate the common causes of variation efficiently and progressively over time and isolate those from the special causes - the errors that arise in execution, which can be tackled with training and increased oversight and diligence. There are two key practices for this to happen - transparency of outcomes and reliable measures of effectiveness.

In every complex endeavor - from delivering reliable, reusable rocket launches to orchestrating complex system & software development - balancing creativity with structure is how to turn fractured efforts into breakthrough outcomes. To replicate such successes, professionalism, discipline, and agility are essential; all require feedback and learning that are glaringly absent in traditional methods.

This article introduces the PIANOS framework - six interlocking forces that can guide any team from fragmented ideas to sustained progress using these keys. You can jump to the description of the PIANOS framework directly if its rationale is not of interest.

Diagnosis

The Yin-Yang symbol (Figure 1) represents balance and harmony in Chinese philosophy. It illustrates the idea that opposite forces - like light and dark, male and female, or order and chaos - are interconnected and interdependent. Instead of being purely opposing, they complement and complete each other. This situation is an interplay between order and chaos.

The swirling halves show that each force contains a bit of the other (represented by the small white circles), meaning that within darkness, there is light, and within light, there is darkness. Too much order constrains innovation, too little leads to escalating exposure to unmitigated risks.

Adventure lies along the margins (the yellow boundary between regions), as do rewards, both in fulfilling real needs, and in learning how to mitigate the effects of the ever-evolving chaos. This suggests that balancing efforts across this frontier is essential in all aspects of life. But how can this be done when building new things?

“First, the taking in of scattered particulars under one Idea, so that everyone understands what is being talked about… Second, the separation of the Idea into parts, by dividing it at the joints, as nature directs, not breaking any limb in half as a bad carver might.” Plato, Phaedrus, 265D

Such is the nature of building new things; ideas must be elaborated into substance using organizing frameworks with theoretical underpinnings and learning based upon mechanism design, evidence of effectiveness, and compelling track records that delivery on useful predictions.

Under traditional thinking, we typically use the term production to describe pulling together all the pieces and assembles them for the user or for mass distribution. To produce these units at scale, the configurations of components, desired product characteristics, and targeted economies of scale determine the appropriate levels of precision and automation for manufacturing, the materials to be used, and the numbers of components to be integrated. In some cases, it is more cost-effective to produce spare parts in the same batches in which the initial parts are manufactured. This ensures adequate and comparable spares are available during the expected life of the system. This essentially equates production to manufacturing.

Instead, throughout my writings, I deliberately use the term production to refer to the mechanisms used to produce outcomes, goods or services which have value and contribute to the utility of capabilities. The etymology of the term ties it to the act of bringing something forward into existence. It is derived from the verb producere, with the pro- prefix meaning "forward" and the -ducere suffix means "to lead or bring." Production therefore refers to both acts of unprecedented creation (through the engineering of new things) and manufacturing (assembling previously designed things). Over time, the use of production has also expanded to include the creation of goods, artistic works, and even abstract concepts like ideas and resources like energy. Let’s open the black box of production to see what kind of aids are helpful to orient our exploration.

An alternative approach to organizing endeavors

Existing frameworks all have good intentions: to pursue progress towards realizing goals. But few provides a universal structure that combines useful planning with adaptive flow. Further, their prescriptions are often oversold, failing to provide adequate guidance to cover the challenging situations that many projects encounter, while simultaneously being overly prescriptive for straightforward tasks.

I will be writing about my experiences with these existing frameworks in future posts. They can be helpful in some contexts while failing miserably in others. The contextual realities of complexity and uncertainty are often the key differentiators in selecting which approach should be used. But according to the book How Big Things Get Done, there are several key drivers that differentiate success and failure:

One driver is psychology. In any big project—meaning a project that is considered big, complex, ambitious, and risky by those in charge—people think, make judgments, and make decisions. And where there are thinking, judgment, and decisions, psychology is at play; for instance, in the guise of optimism.

Another driver is power. In any big project people and organizations compete for resources and jockey for position. Where there are competition and jockeying, there is power; for instance, that of a CEO or politician pushing through a pet project.

One might throw up their hands at this insight, saying these contextual aspects are outside one’s control. But people placed in these situations often fail because the situation they are exposed to is unfamiliar to them. They need to be able to safely practice and learn from mistakes, when presented with similar situations in a safe, ‘off project’ setting. That’s a place where simulations have been used effectively, and that success can be leveraged to these situations, if approached from a common orientation.

Rather than forcing people into difficult choices from among these frameworks, we should start from a meta-framework that pulls the best of class from each and provides viewpoints that are complementary and have broad applicability, spanning the range from setting up a lemonade stand to training large language models. Martin Fowler, in his forward to the book Frictionless, describes the crucial ingredients for effective throughput as feedback loops, flow state, and cognitive load:

We can only find out whether we are on the right path by getting rapid feedback. The longer the delay between that blue dot moving on my phone-map, the longer I walk in the wrong direction before realizing my mistake. If our feedback is rapid, we can remain in the second element, a flow state, where we can smoothly and rapidly get things done, improving our products and our motivation. Flow also depends on our ability to understand what we need to do, which means we must be wary of being overwhelmed by cognitive load, whether it comes in the form of poorly structured code, flaky tests, or interruptions that break our flow.

Thus, an alternative framework is offered here that exploits those hints by providing an explicit, over-arching structure which draws on the best-of-class from each of the traditional control-oriented frameworks. This alternative also offers potential as a universal framework for viewing all activities, in the same manner as the word ‘endeavor’ in my writings covers both temporary and ongoing pursuits of professionals (be they engineers, scientists, etc.) as well as regular dudes doing everyday things.

The value proposition

By providing a robust environment in which agents can rehearse, practice, learn, and build their skills in applying production strategies, tactics, and operations, they build confidence for real-world applications, develop better situational awareness, and embrace opportunities for leading orchestration.

A few requirements for designing such frameworks are worth amplifying. Frameworks should:

1. seek to integrate, rather than replace, current methods

2. address the shortfalls described with existing approaches

3. incorporate learning and feedback as the backbone of work

4. be structurally compatible with simulation implementations to aid in training and practice

5. enable tailoring guidance to be offered but not mandated

6. provide mechanisms for data collection to capture performance with minimal user input

7. be compatible with AI agents for analysis of the resulting data and to offer guidance about decisions given production system states and experiential trends.

Introducing PIANOS

In 1916, Albert Einstein warned against letting old ideas become unchallenged dogma. He argued that real progress means dismantling worn-out concepts and replacing them with systems that better serve our goals. Inspired by that spirit, we here introduce six interacting viewpoints which help organize and guide the actions necessary to achieve sustainable progress for any endeavor, using a representation that is simple enough to serve as an icon for this site, while still communicating several powerful ideas:

• Efforts to change our world involve tradeoffs between needing unprecedented innovations within unfamiliar environments and needing disciplined replication of prior successes

• Methods employed in such efforts must enable rapid accommodation to changing environments while assuring that adequate fitness is delivered

• Methods should also encourage iterative refinements which deliver adequate utility at an acceptable pace for customers

• Too much order constrains innovation, and too little risks precious resources

This collection of viewpoints is captured by the mnemonic “PIANOS”, which is derived from the first letter of each viewpoint, and is depicted in Figure 3.

This visual concept represents an iterative collaboration among agents as they pursue progress at a top level. These viewpoints can be mapped onto the concepts of operation for endeavors big and small, using a conceptual representation that is developed further in the corresponding sections of this blog. The underlying engine of the framework presumes an iterative refinement of performance and learning, driven by a focus on delivering near- and long-term results. The mission is to address the root causes of control-oriented failures, refine the architecture for expanded performance and sustainability, and exploit the productive interactions of continuous flow.

The frames of reference motivating this rendering

I spent the majority of my aerospace career in engineering organizations. It is typical for most of us to view our own world and think it is more complex, more difficult, and more unappreciated compared to others around us. As a software engineer in those roles, I understood how to release my code into service, but gave little thought to the complexity of manufacturing operations for aircraft; those other jobs were in organizations typically called Airplane Production, and my mental model of those jobs was that they were less interesting and challenging than my own.

In assignments later in my career, I had the opportunity to work in and across those organizations, and came to understand that they, like me, had a mixture of precedented and unprecedented work. They, like me, had to be creative in how they approached their work, had to perform their work to standards, had to make tradeoffs between short- and long-term opportunities, and took great pride in the results. I came to realize that the activity of production applied to both environments, and this framework emerged from that realization.

PIANOS viewpoints

The framework’s viewpoints are as follows:

• Production - Production is the primary orientation and is depicted by the inner Ying-Yang symbol in swirling black (depicting chaos) and blue (depicting order). Navigating this boundary involves three interconnected and subordinate elements which interact to implement production’s key features:

  • Exploration - traversing an unfamiliar region of a landscape to gain knowledge about that environment

  • Evaluation - assessing attributes (characteristics, volume, or value) of a situation within a particular context

  • Transformation - following a course of action, order, or plan to translate goals and inputs into desired outcomes

  
  Exploration activities are represented by the red gear in the diagram, reflecting their uncertainty. The yellow gear depicts the evaluation actions necessary to accomplish focused elaboration, verification, and refinement, whose outcomes may drive further exploration or transformation. Finally, the green gear depicts the successive incubation, transformation, and maturation of capabilities suitable for entry into service. These colors correspond to the classic stoplight charts often used in summarizing the status of activities.

  
  The interactions among these cogs represent interlocking cycles - with both exploration and transformation activities interdependent on each other and upon their corresponding evaluations - to drive iterative cycles of progress.

Surrounding this cyclical, reentrant production process are five broader forces, each employing a distinctive color symbolizing the agents who responsible for guiding these three production gears towards structured progress. Note that in Figure 3, each of these has an interface to the external environment, which provides the context of the problem or mission of interest. These viewpoints guide and influence production, and are:

• Innovation - researching, experimenting, and engineering novel capabilities and solutions into existence

• Adaptation - enhancing the suitability, resiliency, and efficacy of production capabilities within dynamically evolving environments

• Navigation - analyzing, elaborating, and exploiting effective pathways to progress over a capability’s lifecycle. Navigation requires active monitoring and balancing resources to:

  • meet current operational needs through the sustainable use of available capabilities and resources

  • position future capabilities for addressing the sometimes competing strategic and operational objectives anticipated across future time horizons

• Orchestration - collaborating across viewpoints to assure performance, exchange data and control information, and respond to feedback so that intended outcomes can be achieved within environmental constraints; these interactions occur at both the holistic level and in lower-level subsystem through coupling

• Synthesis - iteratively configuring, aligning, and tuning existing capabilities to enhance their fitness for use

Up until now, I have described these elements as viewpoints - holistic, context-dependent lenses used to describe how reality behaves from a particular perspective. At first blush, they may seem merely a category scheme. But they can also be thought of as analogous to fields in physics:

• Each element is a distributed substrate which provides a dynamic continuum across physical subsystems and contexts

• Interactions between these elements resemble entanglements, since the state of any one element can influence or constrain another

• Changes in one field can ripple across others, even if not directly adjacent, as would be expected in a classical hierarchy

Capabilities translate such viewpoints into actionable competencies necessary for operating effectively.

The producers and consumers of critical exchanges

Figure 4 provides an overview of some of the entanglements necessary to integrate these viewpoints into a cohesive whole. There is no start or end to actions here, as this diagram depicts relationships, not flow. These relationships span the full range of endeavors but to keep the representation as simple as possible do not depict the competition, challenges, and constraints imposed by external environments. The dynamics introduced by those dependencies will be developed further in future posts.

This figure exposes my bias for action and belief in the power of comprehensive data and process architectures. Such architectures are sources of clarifying definition for relationships when they are properly realized. These relationships impact both the nature of the tools used in these contexts and the communications and information management challenges that present themselves in such environments. This structure also lays the groundwork for thinking about opportunities for improvement. But each of these elements must be instantiated with the specific activities appropriate to the context and goals being pursued.

As the figure indicates, activities are always the hubs of value-generating effort, and the nature of these activities must be considered carefully, especially with respect to the agents who are to perform them and buy off their implementation. The term ‘agent’ is used rather than ‘people’ (or aggregations of people such as organizations) to reinforce the idea that some functions may be performed by individual humans, others by algorithms, and still others by hybrids of collaboration across these pathways.

In practice, slips and delays play a big part in performing these activities (indicated in figure 5 by double slashes across a flow). These quality escapes and delays represent one of the biggest challenges to the acceleration of outcomes.

Analyses of these interactions can help explore the expected outcomes under various initial conditions and operational strategies and can reveal potential gaps in concepts and mental models. As these relationships must be instantiated in a concrete (rather than abstract) context, they will manifest as a more complex and diverse structure than the elements represented in this portrayal.

The power of these forces is evident from their integration:

This framework also provides a reusable structure that - once elaborated - enables comparisons across endeavors from a common structural context. Simulations based upon these ideas thus provide participants with opportunities to perform such tradeoffs, improve their understanding of different situations, and practice alternative responses, all in a safe learning environment. I will unpack this opportunity further as sufficient interest arises.

The PIANOS framework invites teams to embrace the adventure along the yellow boundary of Figure 1 - where innovation meets discipline, and ideas become impact. Whether you're navigating swirling chaos or aligning for breakthrough execution, these six forces offer a structured path forward. Sign up for continuing posts to discover how PIANOS can turn fragmented efforts into sustainable progress, helping you orchestrate bold outcomes with clarity, creativity, and purpose. And to continue in this journey of exploring production, the next article in this series is here.