The decision makers in many software‐dominant organizations, such as the FAANGs (Facebook, Apple, Amazon, Netflix, and Google), evolved quickly from coders and software engineers unfamiliar with the advantage of the big‐picture view of the software and of the organizations developing the software. INCOSE's Systems and Software Interface Working Group (SaSIWG) has been reading a fable of such an organization that found itself in a typical terrible state, unable to respond quickly and effectively to customer needs, because it was tied up in a complex mess of silos, dependencies, management rules, and blame. While the book has garnered praise as the answer to many software organizations’ problems, it quite significantly omits any mention of systems engineering as well as much positive mention of architecture or project management. In response, the SaSIWG has been working on a set of tools to help first ourselves and then INCOSE systems engineers understand several important aspects of such organizations. First, how do such systems engineering‐deficient organizations work? Second, what does their terminology mean at a top level, in a way that doesn't take a computer science degree to understand or a day to look up? Third, how can a systems engineer break into the software engineering conversation and leave it without feeling defeated and overwhelmed by the unfamiliar jargon, but rather knowing they can be and have been useful? Finally, how can systems engineers plan in the long run to assist in engineering the complex system that is the software development enterprise and ecosystem? This is not always acknowledged as a system needing engineering, but it is universally acknowledged as “the problem” when it is not well engineered. This paper provides an overview of the tools that are being developed and outlines the guide that the group is hoping to create.

Many software‐dominant organizations ignore systems engineering completely. A recent popular book described one such organization in a fable format. The INCOSE Systems and Software Interface Working Group chose to read this book as a weekly professional development seminar to investigate where systems engineering should fit in software‐dominant organizations of the type that do not currently involve INCOSE's systems engineers. This seminar culminated in an “author day,” where the book's author responded to our questions and discussed our potential role. The book club activities produced several drafts we can turn into products to help INCOSE systems engineers better understand software, and systems engineers' potential role in such organizations, to help improve software‐intensive system success.

The software industry has been experiencing several transformations. Development teams now often autonomously deliver business capabilities to software service systems. The Unicorn Project, a best‐seller, tells how a retail company transformed into an Agile and DevOps organization. This paper uses a model from the systems engineering toolset to understand those organizational changes and proposes an evolution of the systems engineering discipline to increase the value provided by this type of organization.

In recognizing a system's complexity reflects human complexity, this treatise suggests ways to achieve effective progress in complex systems engineering by intentionally including people as an integral system part to develop or improve. We apply essential and relevant multi‐disciplinary techniques in addition to the necessary enabling technologies. However, we focus on human aspects making or breaking the system. Although this methodology can apply to almost any endeavor, software engineering is our specific example domain area.