On Living, Leading, (Re)designing, and Coaching

The case of Aravind

The following video shows what's possible when you declare a new future possibility and act in the present to make it a reality.

I hope you are inspired by this as I have been.

Take care,

-Steve

Different Ways of Leading and Organizing Generate Developmental Mismatches

Just as individuals develop so do organizations. More to the point, we could say that the ways individuals organize develops. We've all experiencing the difference between a team leader that organizes projects well and those that don't.  A big part of the difference, I suggest, is in the way of organizing taken by each leader.

Around 1999-2000, I developed a model for several different styles or ways of leading and organizing that follows the well-understood trajectory of adult development (from developmental psychology). My premise is that the way individuals organize expresses the level of development of their observer.

Here is a high-level summary of the model starting with the least developed way of organizing.

1. Assessment responds to the need to ground organizing in our concerns about what's happening
2. Vision responds to the need to establish a direction, identities, and offers
3. Opportunity responds to the need to make immediate progress
4. Task responds to the need for being effective
5. Process responds to the need for improving efficiency
6. Knowledge responds to the need for diversifying offers and renewing (revisioning) identities
7. Compassion responds to the need for placing people (that develop) at the center of organizing
   
8. Wisdom responds to the need for timely action and conservation of energy when acting
   
9. Love responds from the inherent interdependent relationships in which we exist to the organizing challenges
   
10. Presence response from the inherent temporal and spatial co-presence in which everything occurs
    

Together these ways create and respond to the challenging situations every leader faces daily. To achieve effectiveness, efficiency, and the fulfillment of customers and employees in the short and long-term, all ten ways need to be alive and healthy.

Each of these ways displays different self-reinforcing patterns of awareness and action, of concern and response, of language and practice. Each is way is a different observer of the organization and the challenges it faces. And each way has a different way of responding to the challenges.  What is crucial is to match the demands of the challenges that the organization faces with the appropriate response.


Leaders and organizations often struggle because they have mastered one or a few of these ways of leading and organizing but the challenges they face demand a different way of leading and organizing. However, instead of learning new ways of leading and organizing they simply do what they've mastered over and over, harder and harder, with the same unfortunate results. In short, they are stuck and not learning or developing.

Many leaders don't even know that other ways of leading and organizing exist and are possible. And those that see that other ways are possible often don't step into the action learning that is requires to develop those new ways.  For sure this is a hard road to walk. Developing a new way of leading and organizing can take years. And in today's business climate, it is rare for leaders to willingly step into a multi-year deconstruction/reconstruction of how they lead and work.  However, on the flip side of the argument, the acceleration of change we experience in today's world demands that companies reinvent themselves approximately every 3-5 years. In fact what is needed is to take on the practice of development (of transformation) as an ongoing and continuous endeavor. Indeed, it has always been so whether we've known it or not. Better to take it on consciously that to be dragged kicking and screaming unconsciously into the morass that so often accompanies transformation and deep learning.

One early step to taking on this endeavor is to have a map of the territory and a reading on where you are within it. The 10 ways of leading and organizing provide one good map. More than one map is required. And when using such maps one must always keep in the forefront that "the map is not the territory."

With a map of the basic developmental contour of the territory of leading and organizing, you can make an assessment of which ways have been learned and mastered by which leaders, which teams, which functions.  The dynamics are complex between levels of organizing and within the interactions between organizations. As one simple example, teams that are attempting to organizing using a higher ordered way - say Process - will struggle if there management or their collaborators are using a lower ordered way - say Task or, worse, Opportunity. Being able to observe and diagnose such developmental mismatches opens up new ways to respond to organizational problems effectively that didn't exist before.

For sure the description of the map above is insufficient to perform an assessment. If you want to explore performing such an assessment in your organization, contact me.

In the meantime, I'd love to hear what y'all make of this. What new possibilities open up by seeing that there can be developmental mismatches between the styles or ways of leading and organizing used by people.

Take care,

-Steve

Multividuals - A generative take on being integral

I was reading my friend Guillermo Wechsler's blog and he has an interesting point in his post on Services for Multividuals.  Let me offer a quote to illustrate Guillermo's perspective on "multividuals". In speaking about one of his customers he says:

"They were dealing with a physician as if the physician were a homogeneous individual with needs. What they didn't realize was that just being a physician was being a conflicting network of role identities that even the physicians were unaware of. Physicians play, at the same time, the roles of: the healer, the hospital employee, a self-employed entrepreneur, an experimental scientist, a political activist, among others. Each of these roles have a different structure of concerns, ethical values, moral norms, and instrumental goals that produce interesting tensions and possibilities for change and innovation when you are able to map them, make them explicit, and recognize interesting "user-generated" bridging practices already invented by spontaneous collaboration. While the healer wants more time to listen to a person in pain, the employee wants to perform out of the hospital's standards of efficiency -- "bed usage" or referral rates. And the entrepreneur wants to maximize economic value. All these conversations do not fit together easily. Of course, the set of role identities that I just mentioned is very narrow; but it is a lot bigger than thinking about physicians as those that prescribe your drugs."

What Guillermo is revealing in this observation is an aspect of the integral intuition - to embrace multiple perspectives - that, in my experience, most integral theorists and practitioners miss by stopping at quadrants, levels, lines, and states (see what is integral? for more on these). For sure we can say that the multiplicity of roles identities "live" within the quadrants. But describing roles identities with the language of quadrants really isn't that helpful for generating interesting shared futures.

In addition to the multiple social role identities that we have as humans we also have systems of intrapsychic parts or subpersonalities within us. Two good discourses on this come from Internal Family Systems (IFS) and Voice Dialogue. I'm more familiar with IFS so let me offer an illustration from that discourse.

In IFS, we understand ourselves as a Self System composed of parts and a Self (also called the True Self or Higher Self in some traditions). Parts are of two kinds: Exiles and Protectors. Exiles are the traumatized and wounded parts of us that were formed when we were young. They are painful to experience and it is the job of the Protectors to prevent us from experiencing that pain.  Protectors come in two flavors: Managers, who control circumstances and states to keep the Exiles and their painful feelings away, and Firefighters, who act rashly to intervene and protect us from the Exile's pain when the Managers fail.

To illustrate, many of us have an Exiled part that feels unrecognized for our contribution. It can feel very painful to access this part of us because it can trigger negative self-assessments such as worthlessness and deficiency. And because being unrecognized for our contribution is painful to experience we might have a Manager that acts to avoid feedback from others. No feedback = no possibility of feeling unrecognized. However, sometimes feedback isn't avoidable. We get feedback from a client or our boss often unprompted. And even if it is positive feedback we often can't take it because the feedback never captures the breadth and depth of our actions and who we are and so we feel unrecognized and the accompanying pain.

The Self is an open, accepting, curious, and compassionate presence that is not divided or split off as parts are. Through the Self we access a holistic experience of ourselves. The Self is our source of authenticity whereas parts generate reactivity. From these simple distinctions offered by IFS, we can begin to understand the system dynamics between our various parts and the Self and how that generates our behaviors and, in turn, our results in life. IFS gives us an active way of interacting with our parts to unburden them and open new possibilities for action.

Please follow the link above to learn more about IFS. I don't have the time or space to go further here.

To combine these two perspectives, we are both an interior Self System and an exterior Social Role System. We are "multividuals" in our interior and exterior identities. In fact, this is how we actually live. Socially, we live multiple identities (e.g., a son, a father, a husband, a brother, a leader, a customer, a supplier, etc.) each with their own concerns, moods, and narratives. And, within ourselves we have multiple parts each with their own concerns, feelings, and narratives.

Working in integral ways means also working with these structures of self and public identity not just quadrants, levels, lines, states, and types. Working (phenomenologically) directly with how we know ourselves and how others know us enables us to generate new ways of being. It is generative as opposed to descriptive.

The distinction between descriptive and generative approaches is analogous to the distinction between the map and the territory. The map may be useful, but in the end we must respond to the territory we find ourselves within not to the map of it.

I'd love to hear your thoughts, comments, and questions.

Take care,

-Steve

Case Study: Re-inventing the Practice of Requirements Management in a Software Company

This is the first in a series of postings I'm calling "Case Studies". Each posting will present a particular project of which I have personal knowledge. These cases are a study in the application of an integral-ontological design approach which is intended to support personal development and social evolution (see my posts on the purpose of business and beyond "knowledge management") within an organization and/or its network or organizations.

My interest in presenting this is to generate discussion about what was done that could not only help readers but also to help me get more deeply in touch with what was done and, naturally, what can be improved upon next time.

Background:

This project was performed in a mid-sized publicly traded software company of ~1400 employees on a "big" project to produce the next major revision to the company's primary product. The code name for the project was Puma. The design team for this re-invention of practices included a cross section of key players from marketing, engineering, release management, program management, and testing. The staffing for the Puma project numbered ~120 engineers spanning ~9 development sites dotted around the globe from the US, Canada, Europe, and India.

I was the visionary and lead designer for this project.

Presenting problem:

The software company is struggling with standard requirements management practices that include the following:

• Marketing talked to customers and prospective customers about what they need from the software product. These needs are resolved into product requirements which are described in a Product Requirements Document (PRD). Requirements are grouped (prioritized) into "must have" and "nice to haves".
• Engineering receives the PRD from Marketing and allocates software engineers to implement them. A plan is generated by the software engineers to fulfill the "must have" requirements. Commitment to fulfill the "nice to have" requirements is deferred until enough "must haves" are completed and there is an accurate sense of how much time and effort remains before release to implement "nice to have" requirements.
• Testing receives the developed product intended to fulfill the requirements. In turn, they test the product to ensure that the requirements are indeed fulfilled. If they aren't, a bug report is filed and resolved by engineering.
• The product ships when scheduled unless, in the assessment of the key marketing and engineering managers, the product is sufficiently buggy. In such a case, the release is deferred for anywhere from a few days to a few months while the bugs are fixed.

In spite of the use of standard requirements practices, the software company continues to disappoint customers with the wrong features or features that are poorly designed and implemented. Customers aren't 100% dissatisfied. Indeed, the product is considered largely successful. However, customers have learned to not buy major releases until at least one "point release" is shipped because the company has a history of not quite getting things right the first time. Either the feature sets are incomplete, too complex to use, or too riddled with bugs. And customers have learned to protect their interests by waiting for new features to mature. This delay in value generation makes managing the business difficult for executives.

In addition, there are frequent disagreements between marketing, project management, engineering, and testing as to what must be built. And the requirements descriptions often don't resolve this disagreement and often are the very source of this disagreement.

Note: In my 16 years of experience in the software industry, this company's situation is very typical - typical of probably 80-90% of all software companies that I've seen.

Breakdowns that provoked re-invention of requirements management:

• It is not clear what is required and what isn’t required (even when we have a description of the requirement). There are different interpretations of the same requirement and no way to resolve the differences leaving the answer to the question "what is required" unresolvable in many cases.
• It is not clear how uncertainty/ambiguity in requirements is resolved; often resolution occurs late and doesn’t include the customer’s viewpoint or resolution doesn't occur at all and the feature is deferred.
• It is not clear how something becomes a requirement often leaving unresolved if something is actually required or not. Often necessary changes are discovered that aren't part of any requirement in the PRD. Is it a requirement or isn't it? The current practice produces confusion rather than clarity on this point.
• It is not clear how changes to requirements are made. Must they always result in a changed PRD? At what point does the PRD become obsolete and, if this occurs, what replaces it as the definition of the software?
• It is not clear who owns requirements - marketing, engineering, testing, and/or the customer?
• It is not clear how related requirements emerging separately from marketing and engineering are reconciled and merged.

Naturally, the company's obligation is to satisfy customer and generate business results. Current practices are generating partially satisfied customers at best and really unhappy customers in some situations at worst. In addition, these practices consumed valuable resources in generating products that didn't generate value for the customer. Therefore, the current requirements management practices were wasteful. Therefore, current practices put the company at risk for not fulfilling its obligations to its customers or stockholders.

Threat:

A requirement is pretending to be something it can never be – an unambiguous and complete description of a product or feature. Because of this, meeting our obligations are threatened unless we do something else to address the problem of generating customer satisfaction in an economical way.

• The requirement is always interpreted in a background of interpretation (also called the background of obviousness) some of which is shared and some of which is not shared between those who use the requirement (e.g., marketing, engineering, project management, testing, and the customer).
• The differences in the background of interpretation between different users of the requirement description generates different interpretations. Note, these are not misinterpretations but simply different interpretations.
• It is impossible to fully unconceal and share the background in which the requirement is intended to be interpreted; if the background is shared this isn’t a big deal because the intended interpretation will be formed; if the background isn’t shared then this completely undermines the ability to depend upon the description of the requirement for coordinating the action necessary to satisfy the customer. This later case is typical, the former rarer.
  

Opportunity:

Competitors are similarly shackled by the standard interpretation of requirements management that is broken. If we can invent a new practice for generating customer satisfaction in a more economical way, we could generate a significant competitive advantage.

Diagnosis:

• This is not a problem of poor requirements descriptions (for which the solution would be train people to write better requirements). No matter how much energy we put into improving descriptions, we can never escape the fact that they are still descriptions. And because they are still descriptions, they will always be interpreted differently by people in different roles, with different concerns, with different experiences, and different backgrounds of interpretation.
• The non-obvious question we are left with: How do we know what to do to generate the right product and, ultimately, customer satisfaction if we can’t rely on descriptions of requirements?
• We have a mess of miscoordinated backgrounds of interpretation (backgrounds of pre-understanding and obviousness). We need to respond to this as a coordination breakdown and not as a problem of ambiguous or incomplete requirements descriptions.
  

Recommendation:

• Although we tend toward seeing this problem as poor requirements description, we always (and already) wind up dealing with this problem as a coordination breakdown. For example, when testing discovers that the product doesn't meet their interpretation of the requirement description, they open a bug report. A bug report is a request to fix the bug. The bug gets assigned to a software engineer who commits to fixing the bug. The software engineer and the tester will have a conversation discussing what they both feel is required. After some discussion and possibly involving marketing or, in some cases, a key customer, they will agree on how the product must work and the software engineer makes a commitment to make the fix. The software engineer fixes the product and the tester tests that it fulfills what they agreed to. All of this action is coordination and not the improvement of descriptions. First it is coordination of changes to the software product. Second it is coordination of the background of interpretation of the software engineer and the tester (and anyone else they bring into their conversation). Although this is, more or less, what we do to resolve the breakdown, we still think that it is a failure of the requirements description instead of having poor and unconscious coordination practices. So the answer to the "non-obvious question" above is to address such breakdowns in generating customer satisfaction through more conscious and carefully designed coordination practices and not more careful wording and review of requirement descriptions.
• The first step is to re-invent what we are already and unconsciously doing - resolving breakdowns in what to build as a coordination problem - in a way that makes it conscious, legitimizes it as sound practice for generating customer satisfaction, and enables us to build competence, power, value, and competitiveness while eliminating significant economic waste generated from our attempt to resolve the problem by improving descriptions (which includes learning fancy ways to specify requirements, making descriptions longer and more verbose, review cycles, customer reviews and sign-offs, and peer reviews and sign-offs).
• Therefore, the basic recommendation is to bring new language and practices for effectively coordinating action (and therefore coordinating backgrounds of interpretation) in order to significantly reduce or eliminate the wastes of producing software that doesn't generate value for the customer and satisfy the customer.
  

Declaring new future possibilities:

• Be responsive to customers, not controlling of circumstances and people. When we shift our focus to improving coordination instead of improving descriptions, we shift into being responsive to customers and away from trying to control the circumstances and people to implement requirements. Being in conversation with customers generates more value (and less waste) than working from requirements descriptions.
• Eliminate the waste of producing software that doesn't generate value and satisfy the customer.
• To have a new and powerfully competitive way of generating satisfied customers through delivering software features.
  

Design of the new requirements management practices:

• Declaration of economically important wastes: links within the chain of communication from end user (customer) to software engineer increase the complexity of the coordination necessary to produce customer satisfaction. Therefore, practices such as elaborating requirements descriptions in PRDs are wasteful. Fundamentally, effort put into improving descriptions is waste. Eliminate those steps from the process by closing the conversational distance between customer and developer and simplify the necessary coordination.
• Design practices in the space of possible breakdowns: we have declared that this is not a breakdown of descriptions but a breakdown of coordination. Therefore, design and adopt practices for coordination of action and coordination of the shared background of interpretation. These are practices for managing commitments through language acts - requests, offers, promises, assertions, assessments, and declarations. These coordination acts (also called speech acts) are used in a particular way in something called a "conversation for action." And it is these conversations for action that perform the coordination of both changes to the product and coordination of backgrounds of interpretation. The conversation for action occurs between a "customer" and a "performer" and when breakdowns occur in the fulfillment of commitments, both roles engage together to bring resolution.
• Build a tool that supports the new coordination practices - allowing people to manage multiple conversations for action simultaneously.
• Re-interpretation of a requirement as a test – meaning a requirement is a request for the software product to pass a new test (also called conditions of satisfaction).
• Collapse of customer’s, marketing’s, management’s, developer’s, and tester’s interpretations; for us this meant going from having a Product Requirement Document (owned by Marketing), a Product Specification (owned by Engineering Project Management), a Design (owned by the software engineer), a Test Specification (owned by the tester), and a Test (also owned by the tester) to having conversations for action that coordinate the passing of tests. This is commonly called test-driven development.
  

Mobilization of new capacities:

• In order to begin mobilizing the change, we created a story about the shared future we were constructing (which is basically what you see in this case study). And this story both reframed our presenting problem, generated new insight into how we generate it, presented new possibilities for preventing and resolving the breakdown that generated an inspiring mood surrounding the change.
• The story spoke more of how we needed to re-invent what we were already (unconsciously) doing - coordinating action in response to breakdowns in building the product and generating customer satisfaction - than to change to something else entirely. This is not to suggest that the re-invention wasn't a significant change to our practices. It certainly was. But this is to suggest the manner of bridging from what we currently do to the new practices.
• Lastly, the story produced an unsettlement of the taken-for-granted assumptions about requirements management. This unsettlement was necessary in order to open a new space for a new set of practices. Naturally, this unsettlement generates feelings of anxiety and assessments of incompetence and mistrust. These must be faced head-on and worked through in order to establish the new practices rather than shied away from.
  

Accumulation of power:

• Beginning with one team, the Puma team, we deployed the coordination practices and tools.
• At first, the process of coordination was too complex, cumbersome, and constraining. This was quickly modified (see the learnings section for more) to simplify it and simultaneously make it more flexible.
• With practice and coaching, Puma team members were able to build skill, build trust in the new practices and each other's use of them, and become inspired by the possibilities, both present and latent, in the approach.
• This generated "momentum" for use of the new approach as superior to the previous approach.
  

Outcome of this case:

• More effectively coping with uncertainty in what is required, changing requirements, and varying (sometimes widely) interpretations of how to satisfy customers.
• Increased customer satisfaction through deeper customer involvement in the production of software resulting in substantially more valuable software.
• Decreased cost of software design and development through elimination of waste - software that didn't generate value for the customers.
• Increased employee satisfaction through smoother negotiations around different interpretations and, over time, fewer breakdowns as a result of increased shared background of interpretation.
• Increased competitiveness over competitors using standard practices for managing requirements.
  

Learning:

In the interest of full disclosure, while the project was successful on several points I personally consider it only partially successful.  Probably the largest success was the major shift in the culture from loose and unconscious coordination to disciplined and conscious coordination through making and fulfilling internal commitments. This is not a trivial shift and the positive impact of this shift was evident, particularly, as time went on. Probably the largest "failure" was that even after a year of development, the tools to support the new process were still painful to use and we were still struggling in pockets of the organization (mostly remote from the re-invention team) with people/teams who wanted to use the new practices and tools as if they were the old practices (see below).

Here are some other learnings:

• You have to put the term "requirement" to rest in order for this design to take hold. We didn't do this and paid the price. The term "requirement" tends to evoke the interpretation that the description generates value because it captures the "truth" of the changes to be made to the software. It is not the description of the requirement that generates value, it is the conversation that coordinates changes to the software held between the "user" (customer) and the "software engineer" (performer). In agile project management, they have adopted the term "user story" in place of the term requirement. I like this term because it captures more accurately what is being presented by the user to the software engineer - a user's interpretation of a required usage. In turn, the software engineer is allowed to have their own story (interpretation). This focused on the generation of shared meaning through conversation and coordination as what is necessary between the user and the software engineer. If I were to do this project again, I would use a term like "user story".
• The first design of the coordination process included four linked conversations for action and the linkages were "enforced" by the tool. This design was complex and users found it difficult to know where they were in the process in spite of indications in the tool itself telling them what process step they were in. The design was cumbersome in that it was difficult to quickly move a requirement through the process due to the large number of coordination acts. In addition, if a mistake was made, users could only correct the problem by going through a series of further coordination acts to force the state of the requirement back to a previous state. Lastly, the design was constraining in that a user could only coordinate between named roles coded into the four conversations for action. This design was scrapped for a simple design of one conversation for action between a customer (the responsible marketing representative) and one performer (the responsible engineering representative). Within any phase of the conversation for action, it was possible to instantiate other conversations for action related to the requirement based on the particular coordination needs of fulfilling the requirement.
• We also learned that in deploying a system of this nature, it is best to start small with one team and work with just that team until all the kinks are worked out. The story that we created to mobilize the company to change was so compelling and so inspiring that there was a massive rush by nearly the whole marketing and engineering departments (over 450 people total) to the new system in its early days before the kinks were worked out. This made for a widespread painful transition to the new system as new versions were rolled out on a monthly basis to fix bugs, resolve usability problems, and address design flaws. It also taxed the re-invention team (which was 1 designer/trainer/coach and 2 implementers) to provide adequate support and to satisfy varied and often conflicting requests from different teams.
• Lastly, whenever you introduce a new interpretation of a core practice as we did in this case, you must be vigilant for people re-interpreting the new practices as if they were the old practices in new garb. This effectively re-implements the current system but in a new language and a new tool. This re-interpretation of the new as if it were the old will happen to everyone unless the old interpretation is sufficiently unsettled within them. And this requires a personal coaching styled approach to change management. If you unsettle the whole company at the same time, the collective anxiety generated will overwhelm the efforts of those responsible for the re-invention. Imagine being attacked by a swarm of bees and you'll get the picture. A single bee - even two or three - can be dealt with. However, when you have hundreds or thousands of bees, your capacity to respond is easily overwhelmed.

Postscript 1: An historical perspective on the challenges of requirements management

In their 1979 book Structured Systems Analysis, authors Chris Gane and Trish Sarson, articulate five enduring challenges that developers of software systems face when articulating what to build with their customers. These challenges are as fresh today as they were then.

1. The designer finds it hard to learn enough about the customer’s needs to understand what specific software to build to generate value for the customer. What makes this especially hard is that designers don’t know what they haven't been told about the customer’s needs and wants.
2. The customers don’t know enough about what is possible for the designer to build. Further, there is no way to accurately model a functioning design before building it as there is, for instance, in the building construction industry.
3. Designers must collect as much information as they can about the customer’s needs but quickly become overwhelmed with too many details of the customer’s technical and business processes and environment because they don't yet know which details are important.
4. It is difficult to establish one contract that equally addresses the needs of the designer to understand what to build and the needs of the customer to understand what will be delivered. Contracts that meet the designers needs are typically too technical and detailed to be useful for customers. Likewise, contracts that meet the customers needs are typically too abstract to be useful for designers. Only when the system has been built do both the designer and the customer have something to react to and discuss and by then it is too late.
5. There are multiple design perspectives – interface, process, data, logical, physical, etc. – and the development of any one design perspective for use in negotiating with customers often places premature constraints on developing other design perspectives which can result in an inferior design and product.

These challenges are as relevant to today’s software developers as they were to Gane and Sarson’s readers in 1979. The reason for their enduring relevance is, as Gane and Sarson articulate, these challenges “arise in any situation where people of different backgrounds, with different views of the world and different vocabularies, have to work together.” For this reason, these challenges will remain relevant far into the future.

The world of the developer and the world of their customers are different because they come from different backgrounds. And this difference results in miscommunication, misunderstandings, and mistakes. So developers often build software that doesn’t fully meet the customer’s needs and therefore isn’t as valuable to customers as it could have been. This frustrates both developers and customers, keeps return on investments in software development relatively low, and leaves unresolved significant customer problems.

Gane and Sarson introduced the method of structured systems analysis, which includes a data and flow modeling language, to address these challenges. Their approach to analysis was a good attempt to generate a new language of design which would address the enduring design challenges they recognized by enabling the designers and customers of software systems to bridge between their worlds. And their approach generated some important successes.

I see Gane and Sarson as very wise practitioners with good intuitions about the centrally important challenges of software development. With the insight that these challenges arise when people with different backgrounds, different views, and different vocabularies have to work together. However, in my view, they proposed a solution founded on a partial understanding of background (listening) and vocabulary (language). And this partial understanding led them down the path of inventing new means for describing software requirements and designs rather than new means for coordinating backgrounds of interpretation. Others have followed in their footsteps - OOD, UML, etc.  And these are certainly improvements upon Gane and Sarson, however, as I pointed to earlier they are still descriptions and will suffer the same breakdowns as previous attempts at description.

Postscript 2: An integral take on this project

From an integral perspective (see what is integral?), there were practices in each quadrant that contributed to continuing the standard tradition of requirements management. So this project required building a new observer (actor) in all four quadrants simultaneously through bringing new linguistic distinctions and new practices.

Upper Left Quadrant - Cultivation of new moods in the face of uncertainty and ambiguity that predispose actors to enter conversations rather than work (and re-work) descriptions; learning to make new assessments of progress (e.g., how conversations for action are progressing rather than how descriptions of requirements are progressing).

Upper Right Quadrant - Embodiment of new practices for coordination, new practices for resolving breakdowns in coordination.

Lower Left Quadrant - Design and adoption of new social practices for building shared meaning through building shared backgrounds of interpretation; new sources of trust were invented; new forms of waste were declared. Through these practices the culture was shifted so that it supported a new way of addressing shared concerns.

Lower Right Quadrant - New social systems and processes were invented and encoded into tools that support the use of the process. Roles and responsibilities were shifted to support the new process.

Developmentally, this project was a shift from organizing at what I call the Process level (in my model of development) to the Knowledge level, or, in the lingo of Spiral Dynamics was a shift from ORANGE to GREEN. The developmental shift required the interpretation that meaning isn't held in the words (requirements descriptions) but instead in how the words are interpreted by a person. And further, that we have different ways of making these interpretations resulting in different meanings of the words. This is one of the fundamental insights of postmodern levels of development (starting with Green).

Given that all developmental levels are always present in any organization, it was necessary to find ways to align the actions stemming from each level, especially RED, BLUE, ORANGE, and GREEN, which are the most prevalent in such a setting.

RED was free to charge into uncertainty and ambiguity with a sense of ownership and without the need to control others.

BLUE was grounded in declaring the customer's voice as being the source of "true requirements" as opposed to the document.

ORANGE was engaged in being responsive to the customer instead of continuously improving technical descriptions.

GREEN was able to add sensitivity to the emotional, relational, and autonomy dimensions of the conversations between customer and performers without getting snagged in consensus decision-making because within the conversation for action, accountability for fulfilling on certain commitments is clearly delineated.

Don Beck (of Spiral Dynamics fame) talks about gathering support for a new way of being across the spiral as creating a meshworks - an integral design that gathers support for a new way from all quadrants, all levels, all lines, and all states.

Lastly, I must thank Chauncey Bell and Guillermo Wechsler (of BABDI) who I hired as consultants on this project. They brought with them an extensive and deep new interpretation of (ontological) design that they learned while in partnership with Fernando Flores. These two had a significant impact on the re-invention and, in many ways, taught us all how to look at our breakdowns in new and powerful ways. Those of you familiar with their work will no doubt see their influence throughout.

Hope you enjoyed this piece. It was lengthy - my longest post to date. But I felt this was better as a single post.  I'd love to hear your comments and questions.

Take care,

-Steve

Beyond "Knowledge Management"

Years ago (in 2001) I developed a model of how leading and organizing develops through fundamental stages of development. Each stage has a different way of observing and organizing. The simple version of this model goes like this: First we must learn to make assessments, then setting visions, then looking for and initiating action to capitalize on opportunities to realize the vision, then structuring the tasks, then optimizing the processes, then enabling the generation and sharing of knowledge, and so on (yes, there are other stages).

Within each of these stages there are observers, discourses, and methods for organizing work. For example, the observer of the task stage structures work hierarchically and takes divide and conquer approaches to completing work. The practices of traditional project management (e.g., PMI) were born from this observer. In addition, the observer of the process stage conceptualizes work as transformations of inputs to outputs within workflows that are optimized by feedback and feedforward loops. The practices of process management were born from this observer.

And so it is with the knowledge stage - the observer here has given birth to the practices of "knowledge management." I put this in quotes because I do not literally mean managing knowledge in the traditional sense of managing as a form of control. While there are leadership and management practices born from each stage's observer, the practices of leading and managing (and organizing) are fundamentally different because they are assessing and responding to fundamentally different worlds. In fact, my savvy writers in this field prefer to use terms like enabling knowledge creation and sharing or enabling innovation rather than knowledge management. And I must say, I like these linguistic reframes as well.

And so it is today that the most developed approach to leading and organizing that is commonly talked about in academia, leadership and business books, and in the popular press is this so-called "knowledge management."

Since my model was derived from research in developmental psychology I was able to speculate that the stages of development that were deeper/higher than the "knowledge stage" would generate a way of leading and organizing that was beyond knowledge management. I called this "compassionate management" (again the term management needs some reframing).

The major shift in perspective from "knowledge management" to "compassionate management" is that the purpose of business is not just to make money. The purpose of business (as explored in previous posts) is to support personal development and cultural (and societal) evolution. This is not in opposition of profit-making. Indeed, profit-making is an imperative. However, when we shift the raison d'etre of business from profit to people, to say it in a snappy way, we shift the organizing principle at the heart of the business. And this new organizing principle is compassion.

I'm working with a client right now (a >$1B pharmaceutical company) that is the largest example I've come across of compassionate management. Prior to taking on this client, I only saw examples of this in small teams, never on such a large scale.  Earlier this week, one of their Senior Business Partners captured the spirit of the shift to compassionate management by saying, "We usually see that you can get work done through people. However, we also see that you get people 'done' through work."

Compassionate management does not oppose knowledge management (or any prior form of management). Instead, it includes them all but what it adds is that these forms of management (including profit-making) are in the service of "getting people 'done' through work" as the central organizing principle.

More on compassionate management in another post ... for now, I hope that this has been food for thought.

Take care,

-Steve

Reinvention is the Next Productivity Collective

What is a productivity collective? It is a collective movement to unsettle a current way of working in order to bring new interpretations of waste and new practices for removing them and improving productivity.

You might know about productivity collectives by their "brand names" - Lean Manufacturing, Six Sigma, ISO 9001, CMMI, Agile Project Management, etc. The history of ways of working in every sector is made by the emergence of new productivity collectives.

I'm working with several others, including my friend Guillermo Wechsler, on a paper exploring the phenomena of productivity collectives. Take a look and let me know if you want to join the conversation.

Why are productivity collectives important? We live in exponential times. Times they are a' chang'n'.

In order to remain competitive and stay alive, over the next two decades businesses must get good at (at least) one thing - re-inventing themselves and their ways over and over again. But an historical survey quickly reveals that businesses often take years and sometimes decades to fundamentally re-invent their ways.

The times we live in call for a different approach to reinvention - they call for a reinvention of reinvention - and this is birth of a new productivity collective.

What are the newly emerging productivity collectives? Here's an interesting one - holacracy.

-Steve

What is the purpose of business?

Well, it has been a while since I posted. Life and work have taken a prioirity over writing. So I'm going to reinvent this blog somewhat. The focus will be the same, however, the written volume will be smaller but more regular, and unfortunately, a lower volume of graphic art.

Today's consideration ... what is the purpose of business? Some may say profit. Some may say growth. But I'd like to propose an alternative thought.

Business is a vastly complex "mechanism" for personal development and social evolution. In business we are always coming up against our learning edge both individually and collectively. Which means that business is a powerful generator of openings for development and evolution. Business creates the conditions necessary for both on a regular basis.

I'm not saying that we shouldn't concern ourselves with growth or profit. In fact, without these concerns, business might not generate openings for development and evolution. However, the superordinate purpose of business must be recognized as personal development and social evolution. And once this is the case, then we will be more able to balance the concerns of growth, profit, social responsibility, work-life balance, and sustainability.

This shift is necessary to build a world that works for our children and their children.

Take care,

-Steve

Breakdowns are openings for new thoughtless acts

I just received the book thoughtless acts?: observations on intuitive design by Jane Fulton Suri of IDEO.  This is a small book of mostly pictures of - you guessed it - thoughtless acts. According to her,

"Thoughtless acts are all those intuitive ways we adapt, exploit, and react to things in our environment; things we do without really thinking."

Thoughtless acts are simply the way we cope with our world. Just imagine if coping with the simplest thing like walking across the room took thought? We'd never get anything done.

Thoughtless acts are not careless acts. Thoughtless acts are acts we do to take care of our concerns and ourselves. Take as an example this mail carrier resting his legs.

Until we die (and who knows, maybe beyond), our life is a never-ending string of thoughtless acts ... except when we have a breakdown. In the occurrence of a breakdown, our acts are no longer thoughtless. As we've explored before, breakdowns open the space for new designs. And new designs are openings to new thoughtless acts once they are embodied.

As leaders, designers, and coaches, the study of thoughtless acts is a study in how and how well we cope with breakdowns. In Fulton Suri's book, she present various kinds of thoughtless acts - reacting, responding, co-opting, exploiting, adapting, conforming, and signaling.

The picture above comes from IDEO's Thoughtless Acts flickr pool. Fulton Suri reminds us that there is no definitive interpretations of these thoughtless acts. The value is in what you see. So, what do you see?

What do thoughtless acts reveal about our way of being?

Have fun with it!

-Steve

Design consulting is the new management consulting

Over the past few days I've been reading a white paper called Transformation Design produced by The Design Council's RED unit. This paper was originally published last February on their RED blog but I just recently discovered it. From their blurb ... "RED is a 'do tank' that develops new thinking and practice on social and economic problems through design-led innovation."

What attracted me to their work is that they think the practice of design is on the cusp of a major shift, "one that represents a step change in scope, approach, and impact" according to their paper. And they name this step change in design approach "Transformation Design." They offer these possibilities for transformation design.

"A new design discipline is emerging. It builds on traditional design skills to address social and economic issues. It uses the design process as a means to enable a wide range of disciplines and stakeholders to collaborate. It develops solutions that are practical and desirable. It is an approach that places the individual at the heart of new solutions, and builds the capacity to innovate into organizations and institutions."

They make the point that traditionally organizations have been designed to cope with a complicated rather than a complex world. A complicated world requires hierarchical control structures which break down problems into less complicated and more manageable problems.

However, they suggest, that we don't so much live in a complicated world as a complex world. Problems like addressing climate change aren't complicated and bendable to the will of hierarchical control. Addressing climate change requires many people and many organizations around the world to change their behavior on many different levels. That makes addressing climate change a complex problem. And hierarchical models of organization (and design) aren't well-suited to addressing such complexity. In fact, they hamper addressing complexity.

The Red unit suggests that "even organizations could be design objects." And this is the fulcrum around which the new design discipline is emerging - design is not simply design of things, it is design of behaviors (dare I say ways of being).

They name as tenets of this new design approach the following:

1. Defining and redefining the brief - participating with the client to declare the design problem instead of taking the client's design brief as the declaration of the problem
2. Collaborating between disciplines - complex problems cannot be addressed from a single point of view
3. Employing participatory design practices - solutions must emerge from those intended to deliver and use them
4. Building capacity, not dependency - because 'design is never done,' build the capacity to continue adapting and designing
5. Designing beyond traditional solutions - design must move beyond designing things and into designing behaviors and experiences
6. Creating fundamental change - create systemic change on a national scale to address shared social and economic concerns

The design community is waking up to the larger role and impact of design in shaping our lives as human beings. And this requires designers to work in a new and different way.

And the parallels of transformation design to leading, designing, and coaching as I've been exploring them in this blog are many. It seems to me that RED has declared a breakdown in the current practice of design to meet the complexity of today's problems. And, while they don't use this language, they have discovered that the most important designing is ontological designing - designing ways of being.

As I was reading this article I realized that design consulting is the new management consulting.

Take care,

-Steve

We design our world while our world designs us

I started this blog to explore the relationships between leading, designing, and coaching and how they all play a central role in our lives. I've started to explore the question of leadership with the series on the three big breakdowns every leader must face. Now, I'd like to begin weaving the question of design into this exploration.

Like the question 'what is leadership?' the question 'what is design?' is worth a lifetime of inquiry. Some design philosophers have even suggested that no agreement about the nature of design is really possible because design is configured and reconfigured again and again in so many different applications.

There is not a single thing around us - desks, cups, computers, keyboards, mice, doors, rooms, houses, schools, businesses, roads, cars, cities, airplanes, nations, etc. - that is not designed. Design is everywhere in the made world and yet it is so often concealed from our awareness because it is doing its job. When designs work, life works. And when life works, we don't really notice that designing is working.

And then we also have moments where life isn't working for us - where our designs aren't working. We call these moments breakdowns (a term we borrow from Heidegger). Breakdowns aren't necessarily a bad thing, although they can be bummer when they happen. Instead, their value is that breakdowns reveal to us where we need a design in order to get something or some part of our life to work.

Design is a practice whose purpose is to anticipate breakdowns and enable us to cope with them skillfully, effectively, and efficiently. Design is an action that happens in the present for the sake of generating a future that works.

Evey intentional act is an act of design. Every time we act with concern for our future, we are designing. The choices we make regarding decorating, dress, food, drink, homes, education, politics, business practices, and so many others reveal that we are designers. Design is fundamental to our way of life. We are all designers (but don't tell those people who think that design is a profession).

Tony Fry, one of my favorite design philosophers points to three aspects of design that must be considered.

1. the designed object that results from the designed act or process
2. the designer (or designing tool)
3. the design process that is the on-going designing of the designed object as it functions or dysfunctions

Each of these are worth careful consideration. Personally, I am most drawn to consider the third - the design process, as Fry calls it.  I don't like this naming because it is too easily confused with the process through which the design arises. Instead, I call this - somewhat awkwardly - "the designed as process." That is to say that a design acts in the midst of relationships to design the actions that are possible within those relationships.

For example, the presence of a cup with a handle designs our manner of drinking - how much we can drink before refilling, how we hold the cup, how hot the liquid can be so that we can still hold the cup, etc. That is to say that designs - a cup with a handle - also design their use. We design our world while our world designs us.

Perhaps this is what was so radical about Andy Warhol's Campbell's soup can as art. Warhol took a design and situated it in a totally different context - art - and in doing so, revealed our taken-for-granted and therefore previously invisible relationship with it. He changed its designing of us.

The major social crises we face today - global warming, economic instability, political deadlock, health care, etc. are all products of design. The major crises in our lives - work-life balance, unfulfiling relationships,  feelings of victimization, and meaninglessness are also products of design.

Design is a practice that is fundamental to both leading and coaching because it is essential to living - to our very being. We'll pick up this thread in another post.

Take care,

-Steve