Rethinking Business

Alternative Business

John Elkington, in 1994, posited the philosophy that business should measure themselves on a “triple bottom line: people, planet, profit.” This idea was then expanded and embellished.

· First, the Benefit Corporation was established as a legal corporate status; protecting boards and executives from shareholder lawsuits if resources were diverted to people and planet instead of maximizing shareholder value.

· B-Labs, a non-profit, offered a self-assessment tool that, with a score of 80% or higher, offered “certification.”

· Frederik Laloux spoke of “Teal” organizations that emphasized the people and governance aspects of benefit corporations.

· Conscious Capitalism, first described by John Mackey and Professor Raj Sisodia, laid out principles that were intended to guide companies towards realizing the goals of the movement.

Multiple efforts have been made to “reform” business without the scope of the alternative business efforts just cited. Examples would include Deming’s “system of profound knowledge,” Senge’s learning organizations, even some aspects of the TQM (Total Quality Management) effort.

The values, principles, and practices advocated by the various forms of alternative, and reform, business efforts share significant overlap. Often the same principle or value is expressed, but in slightly different vocabulary. These might be synthesized:

· Structural—Legal status as a benefit corporation, holarchy, connections to suppliers, clients, and communities

· Managerial—managers as resources, not authorities

· Mission—purpose driven and evolving, long term value creation

· Environment—resource consumption, impact, sustainable practice

· Governance—transparency, accountability, distributed authority, self-management

· People—human development, learning, compensation, meaningful work, self-organization, empowerment, diversity[1]

Several of these values and principles have been implemented. The number (3,600-4,000) of registered benefit corporations, for instance, continue to increase and that status is available in 37-43 (depending on how you count) U.S. states.

Patagonia conducts an environmental impact study for every new product. Zappos, originally, implemented a holocracy and peer review processes for hiring and firing. Buurtzorg Home Healthcare relies on self-organizing teams with no central management. Many companies have on-site renewable energy, LEEDS certified buildings, and local sourcing. ESOP programs for employee ownership are increasing in number.

Less common, and often eliminated in times of strict budgets: sabbaticals, employee learning/meditation time, personal development budgets.

However, only a handful of companies seem to have made systemic changes that would support most, or even a majority, of the alternative business values and principles—especially in times of budgetary stress. There are two major reasons for this: the first comes from an assumed perspective; the second, and far more critical, is IT as currently implemented.

A matter of perspective

Alan Kay once said, “the right perspective is worth 80 IQ points.”

When business first became an academic discipline,[2] it inherited/assumed a worldview, a perspective, from 19^th century physics. Specifically, that the universe was a deterministic, mechanical, and predictable system. LaPlace’s Daemon could, in principle, know the position and state of everything in the universe, as well as all the laws governing them, and could, therefore, predict the state of the universe at any point in the past or the future[3]. It was also believed that you could take apart the universe into discrete. more comprehensible, components, manipulate those and thereby control the entire system. This idea is reductionism.

In Academia, physics was king, and almost all new disciplines wanted to be equally respected and financed. So, all sought to be “sciences,” adopting formal methods of analysis and reductionism. A business was a machine. You could decompose the business into independent parts and optimize them in order to optimize the entire enterprise.

This applied to people (except executives of course) who were mere components that could be optimized and controlled via the “Scientific Management” of Taylor and the Gilbreths.

A shift in this perspective has been emerging the past two decades. It is still a minority position, seldom taught in most academic programs, and almost never implemented in the design and operation of a business.

Complexity, self-organization, autonomous components, cooperation not control, evolution, and adaptation are the hallmarks of this new perspective. Instead of machines, exemplars are biological and social systems.

Some key characteristics of this perspective:

· Interconnectedness: everything to everything, dynamic relations, vary with context.

· Adaptation: responding to continuous change, both internal, and from business environment

· Emergence: small changes can have big effects; non-predictability

· Wicked Problems: “solutions” change the “problem”

· Need to resolve and address situations with incomplete, ambiguous, and/or contradictory information.

These characteristics are reflected in the principles of alternative business models. For example:

· Holarchy instead of hierarchy

· Self-organizing and self-managing teams

· Decentralized decision making

· Agility, innovation, and adaptability

· Emphasis on human learning and abilities coupled with continuous improvement of same

Existing efforts to address issues raised by complex systems are focused and semi-independent. What is needed is an approach that offers systemic change.

Information Technology (IT)

Proponents of alternative business models, even those versed in the complex systems perspective, are essentially silent with regards IT’s systemic role in advancing or impeding the goals of those alternative models.

A primary reason—business sees IT as mere infrastructure, a necessity but simultaneously a commodity. Moreover, IT is perceived to be incomprehensible to anyone other than IT professionals. A topper, the adversarial rift between IT and business.

There are a few exceptions:

· Buurtzorg uses a custom IT focused on simple scheduling and communication tools with minimal bureaucratic overhead. They explicitly reject complex ERP tools and any kind of centralized control.

· Valve Corporation uses tools to make work visible without imposing predefined frameworks and hierarchy.

· Semco Partners mandates simple systems that cannot impose control and also disdain enterprise systems that are all about hierarchy and control.

IT remains the single biggest impediment to alternative business and, arguably all business.

The ways that IT impede, make impossible, the realization of alternative business goals:

· Sustainability. Cloud computing; massive databases; super massive code bases, streaming (e.g., Zoom meetings) demands; planned obsolescence, and more recently blockchain and AI.

· Transformation blocking

o Legacy systems with inbuilt biases for centralized hierarchical control

o Project management tools that enforce approval workflows and centralized authority

o Vendor dependencies, subscription models

o Standardization pressure. “No one ever got fired for buying IBM.[4]”

· Structural incompatibility

o ERP systems support centralized command and control

o Exception handling requires central, hierarchical, approval

o Standardized workflows enforce uniform process

o “Best practices” embedded in code

o Change management

· Cloud Architecture

· Authentication and access control tied to roles enforces hierarchy and organizational charts

o Creates and enforces information silos and prevents transparency

· Centralized databases with single source of truth

· Analytics platforms measure what’s easy, not what is needed

· Inhumane—customers as consumers and data sources, developers as commodities

· Waste

o 80-90% of IT budgets dedicated to “maintenance”

o 40-60% of what is invested in “new development” is waste; never reaches production or fails to meet needs when delivered.

Perhaps the biggest problem is a fundamental conflict in systems type. A business is a complex adaptive system (CAS). The most obvious examples of CAS are biological, ecological, or social. Composed of autonomous entities that cooperate and collaborate, constantly adapting to their environment and evolving, as-a-whole, over time.

Artificial (e.g., computers and software) or deterministic systems (e.g., the universe described by classical physics) demand known and measurable variables governed by formally stated relations and do not (cannot?) deal with ambiguity.

IT is, necessarily, an artificial, deterministic, mechanical system and is therefore fundamentally incompatible with the business that it ostensibly models and supports.

Foundations

First, recognize that a business is a system—a set of elements and the relations among them. Elements are defined and differentiated based on their contribution[5] to the system.”

Second, establish a single conceptual model for system elements; one that applies to any kind of element: a human being, a device (e.g., a copier), or a software Artifact. Remembering, of course, that elements are defined and differentiated by their behavior. The following six-part model is useful:

1. Name. An abstract label, not a proper name; e.g., Customer, not Juanita or George who are specific customers.

2. Description. A sentence or two of text describing the element as it is understood in the business domain.

3. Responsibilities. A list of “contributions to the system,” along with the nuance that the element can be relied upon and is in some way obligated to provide each listed behavior.

4. Knowledge Required. A list of specific bits of information that the element must have access to in order to fulfill a responsibility. The element has four different ways it might obtain that bit of information: it might be previously known (V), it might be provided along with an invocation to provide the service (A), it might be requested from another element at the moment it is needed (C), or the element might know where to find it (G)[6].

5. Protocol. The specific format for how a responsibility is invoked, i.e., a “message” sent to the element and to which it responds. The “message” might include information that the receive needs and the form of a response if any.

6. Events. Elements have changeable state. For example, an element named “Instrument, “might have an “out of calibration state.” States which the element is willing to share and believes other elements might have an interest in knowing are listed.

The use of this six-part model is greatly enhanced by adopting a unifying perspective: anthropomorphization, or treating every element as if it was an intelligent entity. Anthropomorphization will be key to how we think about, comprehend, and design elements and therefore enhance the single business-IT system.

Relations, at this point, require no formal definition other than, “a verb phrase that captures the essence of how two or more elements interact.”

Third, reinforce a known means for capturing and communication information among human beings—the Story. Stories, ranging from simple verbal narratives to cave paintings to songs, have been used among humans to share knowledge since we first acquired language[7]. Neuroscience has demonstrated that our “brains are wired for story.”

Theory

The foundation for our efforts to realize the various goals and principles of alternative business is a comprehensive understanding, a Theory, of the business as it is[8].

A need for this kind of foundational knowledge has been advocated before. Deming’s “System of Profound Knowledge,” Senge’s “Five Disciplines,” Schein’s “Deep Understanding of Organizational Culture,” and Snowden’s “SenseMaker Approach.” In the 1990’s, “Knowledge Management” was an effort to capture, formalize, and store such knowledge in a manner analogous to data and data management.

A Theory incorporates a lot of knowledge: why the business exists; guiding principles; how the business is structure and why/how that structure came to be; policies and procedures; assigned roles; goals and objectives and how achievement is assessed; what kind of interventions are required or desired when goals and achievements fall short; all of the information utilized in the business and who, when, why, and in what form, that information exists; what processes, and discrete steps in that process, are required to transform inputs to desired outputs; communication channels and connections; needs and desires of clients/customers and how to satisfy them; competition regulatory and taxation compliance; accounting rules and practices; if your business is international, all the variations of all this information as required by each country and culture in which you do business; and a lot more!

Theory is essential; but how is it acquired, how is it shared, what form does it take, and how is it utilized when needed?

To answer the first two questions, consider the only other body of knowledge that is of equal or greater scale and scope: one’s cultural knowledge, “that complex whole which includes worldview, belief, art, morals, law, custom, language, social relations, technology, and any other capabilities and habits acquired by man as a member of society.” [Paraphrasing Tyler’s definition.]

Culture is not taught; it is not learned from books. Culture is acquired by participating in the telling of stories and living experience related to story. Acquiring a comprehensive Theory of an organization requires nothing more than establishing a consistent practice of shared storytelling.

Fortunately, the basis for doing this already exists. Story telling is already a wide-spread and powerful practice in any organization. It is the real means for acquiring and sharing knowledge across the organization. Externalized knowledge, e.g., employee manuals, is necessarily limited and almost always incomplete and out-of-date.

John Seeley Brown and Paul Duguid, in The Social Life of Information, provide an example of how deep knowledge of copier repair was disseminated via the telling of “war stories” about difficult repairs among technicians over morning coffee[9].

All that is needed to ensure the people in an organization acquire a comprehensive knowledge of that organization is to add a soupçon of rigor—organize and make ubiquitous the practice.

It is also important that this Theory is comprehensively shared; by everyone in the organization. From the boardroom to the mailroom and, with emphasis, software developers. When we talk about software developers, we mean those charged with designing and implementing; not those in IT management or those in detailed technical roles, e.g., architects.

Sharing is not uniform. Local groups will have more detailed understanding of local aspects of the Theory. Just as is the case with culture. I share a midwestern American culture with a large number of people. However, I also have detailed knowledge of “university professor culture” and “Harley motorcycle culture” that is not shared.

It is critical that the overarching culture, including why the organization exists, its values, its structure, its goals, and structure is uniformly shared. The general culture provides essential context and, in some cases, constraints, that shape how any local knowledge might be expressed.

Theory, once acquired and shared, remains tacit—existing, in full, solely within the minds of those human beings who participated in the storytelling that established the Theory.

Therefore, one additional item is essential: a means for retrieving and utilizing relevant portions of the Theory as required. A visual depiction of the Theory offers such a means. This “Domain Map” would be akin to Deming’s assertion of the need for a, “map of the entire organization as an interconnected system.”

A Domain Map is not representational; it is evocative.

Representational maps include atlases, blueprints, and UML diagrams. Symbols and connections on the map represent, stand in for, things that exist in the world. Such maps are attempts to externalize and formalize knowledge and are, essentially, doomed to failure.

Evocative maps are like images on a whiteboard, religious icons, or User Story cards on the wall of an XP development office. As Kent Beck said of User Story cards, “invitations to conversations future and reminders of conversations past.” Each element of an evocative map is an evocative trigger that recalls to mind the entirety of the stories involving that element.

The Domain Map being proposed here is simple: labeled circles representing characters in the story (Elements of a System) and labeled arcs connecting circles representing interactions (Relations of a System).

Each Story can be ‘illustrated’ with a circle and arc diagram depicting the characters in that story; as a Domain Map Fragment. These Fragments can be collected and integrated to become a full Domain Map.

An Illustration

Consider the following Stories, Domain Map Fragments, and partial Domain Map for an organization, National Organ Donor Registry (NORD).

NORD exists to match humans willing to donate organs with those needing them and ensure compassionate, respectful, and efficient transplants.

Humans become Patients when they voluntarily register with NORD

Patients can be designated as donors or recipients, a status that can reverse at different points in time. Patients are identifiable, describable, and have medical profiles, including organ specific profiles.

NORD works with surgical teams outside of NORD. Each team has access to its own Facility. Teams are located across the country.

When a Facility reports an available organ, a prioritized list of recipients is scanned along with the location of the surgical team associated with that recipient. The organ is sent to the highest priority recipient within optimal travel distance.

A Report showing Recipients and health outcomes is generated monthly.

An “in progress” Domain Map including the fragments from the stories above is shown in Figure 1.

Evolution and Adaptation

Two points must be emphasized before proceeding.

· One, both the Theory and the Domain map are dynamic, constantly expanding and changing in order to capture the best current understanding of the business.

· It is not necessary to have a complete Theory or Domain Map before the business, or teams within the business, can begin making changes to adapt and evolve the business.

The real power of this ‘story-centric’ approach arises from the way it supports responding to issues, adaptation, and evolution. A story provides a “Point-of-Intervention” where change can take place. It also scopes the change to:

· Adding, modifying, or deleting a story, or

· Adding, modifying, or deleting an Element.

Consider the following stories:

One: The team discusses an issue, makes a decision, and crafts a proposal consisting of a statement of work, a budget, and a timeline. The proposal is sent to a manager for approval.

Two: upon receiving a proposal the manager reviews it and either suggests changes and returns it to the team; or, approves it and returns it to the team.

A quick look at the Domain Map shows variants of these two stories throughout the organization. Thinking about the stories, questions arise: if a manager is suggesting alterations to the proposal what knowledge is being used and how was it obtained? What intrinsic value does a signature add to the proposal.

If the manager does have access to information not available to the team; would it not be more efficient to make that information available to the team directly, where it can be integrated with all the other knowledge possessed by the team? If the manager does not have privileged information, what value is a managerial review?

In either case, it would seem advantageous to delete story two and modify the “Team” element by adding the information and a means for obtaining it as an adjunct to the team responsibility, “discuss an issue.”

Implementing this change is trivial. Eliminate the manager and give the team any necessary credentials to query the information. [Of course, the manager is not going to be too happy.]

If similar changes are made to all the other instances of the same or similar stories, the organization rapidly achieves to goals common to alternative business, establishing a holocracy and individual/team empowerment. It also has the effect of making the work itself more meaningful to the team and team members.

Although a specific change is specific and local, that change is taking place in the context of the broad shared knowledge of the organization with its values and its purpose. And, although a business is a complex system subject to unintended side-effects, potential ways the local change might affect global conditions is revealed by consulting the Domain Map. Also, because the scope of change is so limited it is easily altered or reversed if need be.

A common occurrence: more than one story and more than one element might be involved and require a slightly larger scope for any change. It would be seldom that the number of stories exceeds 4-5 and the number of elements requiring change to exceed 2-4.

IT Redux

Two items that are implicit in previous discussions need to be made explicit.

First, professional developers, the ones actually creating, testing, and deploying software, are among those participating in the story telling sessions that develop a comprehensive understanding (Theory) of the business. Thus ensuring:

· Developers[10] will have a complete understanding of business needs, the context in which software will be deployed, and the business value of that software.

· Developers can contribute to development of Theory with stories about what software can do or how it might participate in stories told by others. Every team member offers specific, sometimes unique, skills a Developer is no different.

· Business professionals on the team understand, at least to the specification and interface levels, what the software does, how to interact with it, what can be expected of it, and how it enhances their work or their human abilities.

Second, the unit of change (adaptation and evolution) remains a story or an element or a small number of stories or elements. Essentially, the decision is made to automate, at least a portion of, this story and some of these characters (elements). There is no change in vocabulary or the way that an element or a story is described or modeled. Anthropomorphization of the, soon to be, automated element(s) persists.

Eventually, of course, some degree of ‘technospeak’ will need to occur as the element will be implemented on a computer platform with all the inherent need for precision and syntactic correctness. This need arises late in the conversation, ensuring that both business and development professionals share a common understanding of that which is to be automated.

IT, as a separate system ceases to exist. The business system has elements embodied in as a bit of software executable(ing) on a hardware platform. These elements are “autonomous” in the same way that a human employee is autonomous. Automated elements communicate, collaborate, and cooperate with other automated elements with humans elements in the business system.

Borrowing a label (but not the common definition) from software, we will call individual elements that are automated Objects. An object is defined/modeled exactly as every other element; with the six-part model described above. That model is crafted by the whole team—domain and development professionals together. Everyone understands the element/Object as well as what is expected of that object in its context and as it will be used.

The only difference: an overlay of technical terms like String, Date, Number, OrderedCollection, etc. Also, the Protocol will be syntactically correct for the programming language being used. If the language used is akin to Smalltalk, none of this vocabulary will be incomprehensible to the business professionals. A final step, writing the programming code that will be executed whenever a message listed in the protocol is received.

Automating a single element is simple and straightforward. The amount of implementation time (writing and testing code, testing the response of the element to each message and confirming the response is as expected) is minimal. Coupled with some design considerations, results in automated elements of very low cost. They are easily modified or replaced when the business system changes.

Slightly more complicated is the effort required to automate a story or small group of stories. In this case it will be necessary to craft an Artifact. An Artifact is an Object and is modeled just like any other object. It encapsulates a group of Objects who work collectively and collaboratively to respond to requests from the outside world. The Artifact object receives a prompt, provides any necessary information to its encapsulated objects can perform the necessary work and return the result to the Artifact that then returns the response to whoever sent the initial request.

There is some, not a lot, of technical detail, and some design parameters, behind the construction of an Artifact. Notwithstanding, the creation of an Artifact is a matter of days to a week or two, even for the most complicated. Artifacts, like individual Elements are inexpensive and designed to be modified or replaced at minimal cost.

Conclusions

It is impossible to explain all the details behind the approach being advocated here in 4500 words or less. A book is nearing completion, one that will provide all the detail missing from this short article. Based on that book and a limited number of real-world examples it is possible to assert, with confidence, the following.

This approach will assure the capability of your business to rapidly adapt and evolve with confidence.

Radical reduction in costs will be realized. Reducing middle management within business, eliminating most IT costs, both personnel and hardware.

Deep integration of IT and business, with immediate return-on-investment obvious.

The business will greatly enhance its sustainability by moving from large-centralized, or cloud, platforms to phones, tablets, desktops, and minimal local servers.

The approach offers simple and immediate means for realizing alternative business goals like individual and team empowerment, distributed decision making, being purpose driven; all while augmenting human abilities rather than attempting to replace them.

[1] Not the common use of the term denoting racial or ethnic diversity. Rather, skill levels, multi-disciplinary, multiple perspectives, and multi-cultural.

[2] École Supérieure de Commerce de Paris, ESCP, in Paris, 1819; Wharton School, 1881; first MBA, Harvard, 1908

[3] The pesky quantum mechanics was just a minor annoyance then.

[4] No longer true, obviously, but shows how far back in history this force has existed.

[5] By what they do, not what they are. Behavior not composition. A similar distinction was made in object-oriented analysis and design, objects defined by their behavior and not by virtue of their attributes. Unfortunately, the latter concept became the mainstream definition of an object.

[6] The V, A, C, and G identifies stand for Variable, Argument, Collaboration, and Global, respectively. This reflects usage in the software world where this concept was first offered. The important thing is the description of when and how the information is obtained, not the VACG nomenclature.

[7] Stories have been ubiquitous in software development, e.g., “scenarios,” “use-cases,” and, especially, “user stories” as discussed in Extreme Programming (XP).

[8] Before Software Engineering essentially abandoned the business domain, textbooks and monographs on software development argued that you needed to understand the business before you tried to isolate problems or opportunities and design solutions for them. Interviewing techniques, observations, and modeling of the domain were taught. These practices were ignored by the mid-1970s by almost everyone developing software.

[9] The same book demonstrates why attempts to externalize and formalize this knowledge, ala Knowledge Engineering, failed.

[10] Auxiliary roles—product owners, project managers, IT managers, Data Administrators, Database Administrators, Business Analysts, Software Analysts, Architects and even Coaches and Scrum Masters are not required in the approach outlined here—except for a few of the more technical roles required to maintain legacy systems until they are replaced.