Archive

Rightshifting

Management Monstrosities

February 21, 2021
General, Management, Organisational effectiveness, Rightshifting, Software development
2 Comments

Management Monstrosities

Michele Sollecito (@sollecitom) kindly responded to a recent tweet of mine with the following question: 

“Why do so many well intentioned founders and companies end up creating management monstrosities?”

The “management monstrosities” referred-to are the (dysfunctional, ineffective) tech organisations we find just about everywhere these days. My work on #Rightshifting illustrates just how ineffective is the average tech company, compared with how effective they could be (and how effective Rightshifted outliers are known to be).

But Michele’s question is: “Why?”

Over twenty years and more, I’ve seen dozens of organisations up close and personal.  In none of these organisations have the folks in charge appreciated the difference between collaborative knowledge work (Cf. Drucker) and other categories of work. We can call this a Category Error.

Category Error

Collaborative knowledge work is NOT like:

  • Factory Work
  • Manufacturing
  • Office work
  • Service work (e.g. Call centres, Help desks, etc.)
  • Individual knowledge work

Collaborative knowledge work is in a distinct category all its own, and demands a fundamentally different approach to the way the work works, if we’re to see effective working.

Attempting to manage collaborative knowledge work by means common to other categories of work will inevitably lead to ineffectiveness, and all the monstrous consequences that follow from that.

Assumptions and Beliefs

Put another way, organisations import or retread the assumptions and beliefs of the category of work they believe applies to software development. As the category they assign is (almost) never “collaborative knowledge work”, the prevailing assumptions and beliefs are similarly almost never aligned to effective working.

You may now be asking “Why is the category they assign almost never ‘collaborative knowledge work’?”. I’ll leave that question for another post (if there’s any demand for such a post).

– Bob

The Evolution Of An Idea

January 19, 2020
Culture change, Familiar, Marshall Model, Organisational effectiveness, Organisational Therapy, Rightshifting
1 Comment

The Evolution Of An Idea

Many people have expressed an interest in learning more about the evolution of Organisational Psychotherapy. This post attempts to go back to the roots of the idea and follow its twists and turns as it evolved to where it is today (January 2020).

Familiar

Around the mid-nineties I had already been occupied for some years with the question of what makes for effective software development. My interest in the question was redoubled as I started my own software house (Familiar Limited) circa 1996. I felt I needed to know how to better serve our clients, and grow a successful business. It seemed like “increasing effectiveness” was the key idea.

This interest grew into the first strand of my work: Rightshifting. I had become increasingly disenchanted with the idea of coercive “process” as THE way forward. I had seen time and again how “process” had made things worse, not better. So I coined the term Rightshifting to describe the goal we had in mind (becoming more effective), rather than obsessing over the means (the word “process”, in my experience, conflating these two ideas).

“Rightshifting” describes movement “to the right” along a horizontal axis of increasing organisational effectiveness (see: chart). Even at this stage, my attention was on the organisation as a whole (and sometimes entire value chains) rather than on some specific element of an organisation, such as a software development team or department.

Circa 2008 I began to work on elaborating the Rightshifting idea, in an attempt to address a common question:

“What do all these organisations (distributed left and right along this horizontal axis) do differently, one from the other?”

Subsequently, the Marshall Model emerged (see: chart). Originally with no names for the four distinct phases, categories or zones of the model, but then over the space of a few months adding names for each zone: “Ad-hoc”, “Analytic” (as per Ackoff); “Synergistic” (as per Buckminster Fuller); and “Chaordic” (as per Dee Hock).

These names enabled me to see these zones for what they were: collective mindsets. And also to answer the above question:

Organisations are (more or less) effective because of the specific beliefs and assumptions they hold in common.

I began calling these common assumptions and beliefs a “collective mindset”, or memeplex. This led to the somewhat obvious second key question:

“If the collective mindset dictates the organisation’s effectiveness – not just in software development but in all its endeavours, across the board – how would an organisation that was seeking to become more effective go about changing its current collective mindset for something else? For something more effective?”

Organisation-wide Change

Organisation-wide change programmes and business transformations of all kinds – including so-called Digital Transformations – are renowned for their difficulty and high risk of failure. It seemed to me then (circa 2014), and still seems to me now, that “classical” approaches to change and transformation are not the way to proceed.

Hence we arrive at a different kind of approach, one borrowing from traditions and bodies of knowledge well outside conventional management and IT. I have come to call this approach “Organisational Psychotherapy” – named for its similarities with individual (and family) therapy. I often refer to this as

“Inviting the whole organisation onto the therapist’s couch“.

I invite and welcome your curiosity and questions about this brief history of the evolution of the idea of Organisational Psychotherapy.

– Bob

Further Reading

Memes Of The Four Memeplexes ~ A Think Different blog post

The Aspiration Gap

April 18, 2019
General, Marshall Model, Organisational effectiveness, Rightshifting, Software development
1 Comment

The Aspiration Gap

Some years ago I wrote a post entitled “Delivering Software is Easy“. As a postscript I included a chart illustrating where all the jobs are in the software / tech industries, compared to the organisations (and jobs) that folks would like to work in. It’s probably overdue to add a little more explanations to that chart.

Here’s the chart, repeated from that earlier post for ease of reference:

The blue curve is the standard Rightshifting curve, explained in several of my posts over the years – for example “Rightshifting in a Nutshell“.

The green curve is the topic of this post.

The Green Curve

The green curve illustrates the distribution of jobs that e.g. developers, testers, coaches, managers, etc. would like to have. In other words, jobs that are most likely to best meet their needs (different folks have different needs, of course).

Down around the horizontal zero index position (way over to the left), some folks might like to work in these (Adhoc) organisations, for the freedom (and autonomy) they offer (some Adhoc organisations can be very laissez-faire). These jobs are no so desirable, though, for the raft of dysfunctions present in Adhoc organisations generally (lack of things like structure, discipline, focus, competence, and so on).

The green curve moves to a minimum around the 1.0 index position. Jobs here are the least desirable, coinciding as they do with the maximum number of Analytic organisations (median peak of the blue curve). Very few indeed are the folks that enjoy working for these kinds of organisations, with their extrinsic (imposed) discipline, Theory-X approach to staff relations and motivations, strict management hierarchies, disconnected silos, poor sense of purpose, institutionalised violence, and all the other trappings of the Analytic mindset. Note that this is where almost all the jobs are today, though. No wonder there’s a raging epidemic of disengagement across the vast swathe of such organisations.

The green curve then begins to rise from its minimum, to reach a maximum (peak) coinciding with jobs in those organisations having a “Mature Synergistic” mindset (circa horizontal index of 2.8 to 3). These are great places to work for most folks, although due to the very limited number of such organisations (and thus jobs), few people will ever get to experience the joys of autonomy, support for mastery, strong shared common purpose, intrinsic motivation, a predominantly Theory-Y approach to staff relations, minimal hierarchy, and so on.

Finally (past horizontal index 3.0) the green curve begins to fall again, mainly because working in Chaordic organisations can be disconcerting, scary (although in a good way), and is so far from most folks’ common work experiences and mental image of a “job” that despite the attractions, it’s definitely not everyone’s cup off tea.

Summary

The (vertical) gap at any point along the horizontal axis signifies the aspiration gap: the gap between the number of jobs available (blue curve) and the level of demand for those jobs (green curve) – i.e. the kind of jobs folks aspire to.

If you’re running an organisation, where would you need it to be (on the horizontal axis) to best attract the talent you want?

– Bob

Footnote

For explanations of Adhoc, Analytic, Synergistic and Chaordic mindsets, see e.g. the Marshall Model.

 

The Big Shift

April 3, 2019
Agile, Culture change, Management, Marshall Model, Organisational effectiveness, Product development, Rightshifting, Software development
4 Comments

The Big Shift

Let’s get real for a moment. Why would ANYONE set about disrupting the fundamental beliefs and assumptions of their whole organisation just to make their software and product development more effective?

It’s not for the sake of increased profit – Deming’s First Theorem states:

“Nobody gives a hoot about profits”.

If we believe Russell Ackoff, executives’ motivation primarily stems from maximising their own personal well being a.k.a. their own quality of work life.

Is There a Connection?

Is there any connection between increased software and product development effectiveness, and increased quality of work life for executives? Between the needs of ALL the Folks That Matter and the smaller subset of those Folks That Matter that we label “executives”? Absent such a connection, it seems unrealistic (understatement!) to expect executives to diminish their own quality of work life for little or no gain (to them personally).

Note: Goldratt suggests that for the idea of effectiveness to gain traction, it’s necessary for the executives of an organisation to build a True Consensus – a jointly agreed and shared action plan for change (shift).

Is Disruption Avoidable?

So, the question becomes:

Can we see major improvements in the effectiveness (performance, cost, quality, predictability, etc.) of our organisation, without disrupting the fundamental beliefs and assumptions of our whole organisation?

My studies and experiences both suggest the answer is “No”. That collaborative knowledge work (as in software and product development) is sufficiently different from the forms of work for which (Analytic-minded) organisations have been built as to necessitate a fundamentally different set of beliefs and assumptions about how work must work (the Synergistic memeplex). If the work is to be effective, that is.

In support of this assertion I cite the widely reported failure rates in Agile adoptions (greater than 80%), Lean Manufacturing transformations (at least 90%) and in Digital Transformations (at least 95%).

I’d love to hear your viewpoint.

– Bob

Further Reading

Organisational Cognitive Dissonance ~ Think Different blog post

Something’s Gotta Give

March 19, 2019
Culture change, Organisational effectiveness, Product development, Rightshifting, Software development
1 Comment

Something’s Gotta Give

“The things businesses have to do to make software development successful are well known. And equally well known is the fact that businesses will absolutely not do these things.”

This reality puts us in a bind. We find ourselves in a position where we have to trade off successful development against conforming to organisational norms. We can have one – or the other. It’s not a binary trade-off, we can for example relax some norms and gain some (small) improvements in success. But by and large it’s a zero sum game. At least from the perspective of those folks that find value in everyone conforming to preexisting norms.

I don’t think many business folks realise this trade-off exists. Almost all the business folks I have met over the years seem unaware that their norms are what’s holding back their success in software (and product) development. I put this down to the absence of any real understanding of the fundamentally different nature of collaborative knowledge work (different to their experiences and assumptions).

Some of the Things

By way of illustration, here’s just a few of the things that are necessary for successful software (and product) development, that businesses just won’t do:

De-stressing

Removing stressors (things that create distress) from the workplace. These things include: job insecurity; being directed and controlled; being told where, when and how to work; etc..

Stressors serve to negatively impact cognitive function (amongst other things). See also: Amygdala hijack.

Trusting

Placing trust in the folks actually doing the work. We might refer to this as a Theory-Y posture.

Experimenting

Finding out through disciplined and systematic experimentation what works and what doesn’t. See: the Toyota Improvement Kata.

Being Human

Embracing what it means to be human; seeing employees as infinitely different, fully-rounded human beings with a broad range emotions, needs and foibles (as opposed to e.g. interchangeable cogs in a machine).

Intrinsic Discipline

Relying on intrinsic motivation to encourage and support a disciplined approach to work.

Meaningful Dialogue

Talking about what’s happening, the common purpose, and what the problems are.

Eschewing Numbers

Realising the limitations with numbers, dashboards, KPIs and the like and finding other ways to know whether things are moving in the “right direction”.

Prioritising Interpersonal Relationships

In collaborative knowledge work (especially teamwork), it’s the quality of the interpersonal relationships that’s by far the greatest factor in success.

Summary

If your organisation needs to see more success in its software (and product) development efforts, then something’s gotta give. Specifically, some of its prevailing norms, assumption and beliefs have gotta give. And given that these norms come as a self-reinforcing memeplex (a.k.a. the Analytic Mindset), a piecemeal approach is highly unlikely to afford much in the way of progress.

– Bob

Hearts over Diamonds Preface

March 8, 2019
Culture change, Dialogue, Organisational effectiveness, Organisational Therapy, Rightshifting, Therapy
Leave a comment

Hearts over Diamonds Preface

In case you’re undecided as to whether my recently published book on Organisational Psychotherapy will be worth some of your hard-earned spons, here’s the text of the preface to the current edition (full book available in various ebook formats via Leanpub and in paperback via Lulu.

Will This Book be Worth Your Time?

To my knowledge, this is the first book ever written about Organisational Psychotherapy. Thanks for taking the time to have a look. This is a short book. And intentionally so. It’s not that Organisational Psychotherapy is a shallow domain. But this book just lays down the basics. Understanding of the deeper aspects and nuances best emerges during practice, I find.

This book aims to inform three distinct groups of people:

  • Senior managers and executives who might find advantage in hiring and engaging with an Organisational Psychotherapist.
  • Folks who might have an interest in becoming Organisational Psychotherapists themselves, either within their organisations or as e.g. freelancers.
  • Folks within organisations who might find themselves involved in some way in their organisation’s engagement with one or more organisational psychotherapists.

We’re all busy people, so I guess you may be curious, or even a little concerned, as to whether this book will provide a good return on the time you might spend reading it. I’ve tried to arrange things so that you can quickly answer that question.

I intend this book to be easy to understand, and to that end I’ve used as much plain English as I can muster. I guess some folks find the whole idea of Organisational Psychotherapy somewhat intimi‐ dating, and fear the ideas here will “go over their heads”. Let me reassure you that I’ve tried to make this book common-sensical, friendly and down-to-earth.

Foundational

“Out beyond ideas of wrongdoing and rightdoing there is a field. I’ll meet you there.”

~ Rumi

In writing this book, I’ve set out to define the emerging discipline – or field – of Organisational Psychotherapy.

In a nutshell, Organisational Psychotherapy is a response to the growing realisation in business circles that it’s the collective mindset of an organisation (often mistakenly referred-to as culture) that determines an organisation’s overall effectiveness, productivity and degree of success. By “collective mindset” I mean the beliefs, assumptions and attitudes that an organisation as a whole holds in common about work and how the world of work should work.

Roots

Organisational Psychotherapy leverages over a hundred years of research and experience in the field of personal psychotherapy, a field which has evolved from its roots in the Middle East in the ninth century, and later, in the West, through the works of Wilhelm Wundt (1879) and Sigmund Freud (1896). Research and experience which, in large part, can usefully be repurposed from the individual psyche to the collective psyche (i.e. the organisation).

In my career of over thirty years in the software business, I’ve run the whole gamut of approaches in search of organisational effectiveness, in search of approaches that actually work. It’s been a long and tortuous journey in many respects, but I have come to believe, absolutely, that success resides mostly in the relationships between people working together, in the web of informal customer- supplier relationships within and between businesses. And I’ve come to believe that organisational effectiveness mostly comes from the assumptions all these folks hold in common.

Given that, I ask the question:

“What kind of intervention could help organisations and their people with uncovering their existing, collectively-held, beliefs, assumptions and attitudes? With discussing those, seeing the connection with their business and personal problems and challenges, and doing something about that?”

The answer I’ve arrived at is Organisational Psychotherapy. And so, when I’m working with clients these days, Organisational Psychotherapy is my default mode of practice.

But this book does not attempt to make the case for my beliefs. It’s not going to try to persuade you to see things my way. Organisational Psychotherapy may pique your interest, but I’m pretty sure you’ll stick with what you already believe.

So, if you have an open mind, or generally share my perspective already, this book may serve you in getting deeper into the practicalities and benefits of Organisational Psychotherapy, whether that’s as:

  • a decision-maker sponsoring an intervention
  • a potential recruit to the ranks of organisational psychotherapists
  • an individual participating in an Organisational Psychotherapy intervention in your organisation

Relationships Govern Dialogue

A central tenet of Organisational Psychotherapy is that it’s the quality of the relationships within and across an organisation that moderates the organisation’s capacity for meaningful dialogue. As we shall see in more detail later, fragmented and fractious relation‐ ships impair an organisation’s ability to surface, discuss and recon‐ sider its shared beliefs.

Effective Organisational Psychotherapy needs a certain capacity for skilful dialogue within and across an organisation. Absent this capacity, folks have a slow, laborious and uncomfortable time trying to surface and discuss their commonly-held beliefs and assumptions.

In practice, then, any Organisational Psychotherapy, in its early stages at least, must attend to improving relationships in the workplace, and thus the capacity for meaningful dialogue. This helps the organisation have more open and productive dialogues – should it wish to – about its core beliefs and implicit assumptions, about its ambitions and goals, about the quality of its relationships and dialogues, and about its strategies for success. I wholeheartedly believe that:

People are NOT our greatest asset. In collaborative knowledge work particularly, it’s the relationships BETWEEN people that are our greatest asset.

Whether and how the organisation might wish to develop those relationships and dialogues in pursuit of its goals is a matter for the organisation itself. Without Organisational Psychotherapy, I’ve rarely seen such dialogues emerge and thrive.

The Goal

Improving relationships in the workplace, and thereby helping the emergence of productive dialogues, are the means to an end, rather than the end itself. The goal of all Organisational Psychotherapy interventions is to support the client organisation in its journey towards being more – more like the organisation it needs to be. Closer to its own, ever-evolving definition of its ideal self.

We’ll explore what that means in later chapters.

References

Lencioni, P. (2012). The Advantage: Why organizational health trumps everything else in business. San Francisco: Jossey-Bass.

Patterson, K. (2012). Crucial Conversations: Tools for talking when stakes are high. Place of publication not identified: McGraw Hill.

Schein, E. H. (2014). Humble Inquiry: The gentle art of asking instead of telling. San Francisco: Berrett-Koehler.

Solutions Demand Problems

September 6, 2018
Antimatter principle, Culture change, Emotioneering, Engineering, Flow, Flow•gnosis, Flowchain, Marshall Model, Organisational effectiveness, Organisational Therapy, Product development, Rightshifting, Software development
3 Comments

Solutions Demand Problems

I’m obliged to Ben Simo (@QualityFrog) for a couple of recent tweets that prompted me to write this post:

I very much concur that solutions disconnected from problems have little value or utility. It’s probably overdue to remind myself of the business problems which spurred me to create the various solutions I regularly blog about.

FlowChain

Problem

Continually managing projects (portfolios of projects, really) is a pain in the ass and a costly overhead (it doesn’t contribute to the work getting done, it causes continual scheduling and bottlenecking issues around key specialists, detracts from autonomy and shared purpose, and – from a flow-of-value-to-the-customer perspective – chops up the flow into mini-silos (not good for smooth flow). Typically, projects also leave little or no time, or infrastructure, for continually improving the way the work works. And the project approach is a bit like a lead overcoat, constraining management’s options, and making it difficult to make nimble re-adjustments to priorities on-the-fly.

Solution (in a Nutshell)

FlowChain proposes a single organisational backlog, to order all proposed new features and products, along with all proposed improvement actions (improvement to the way the work works). Guided by policies set by e.g. management, people in the pool of development specialists coalesce – in small groups, and in chunks of time of just a few days – around each suitable highest-priority work item to see it through to “done”.

Prod•gnosis

Problem

Speed to market for new products is held back and undermined by the conventional piecemeal, cross-silo approach to new product development. With multiple hands-offs, inter-silo queues, rework loops, and resource contentions, the conventional approach creates excessive delays (cf cost of delay), drives up the cost-of-quality (due to the propensity for errors), and the need for continual management  interventions (constant firefighting).

Solution (in a Nutshell)

Prod•gnosisproposes a holistic approach to New Product Development, seeing each product line or product family as an operational value stream (OVS), and the ongoing challenge as being the bringing of new operational value streams into existence. The Prod•gnosis approach stipulates an OVS-creating centre of excellence: a group of people with all the skills necessary to quickly and reliably creating new OVSs. Each new OVS, once created, is handed over to a dedicated OVS manager and team to run it under day-to-day BAU (Business as Usual).

Flow•gnosis

Problem

FlowChain was originally conceived as a solution for Analytic-minded organisations. In other words, an organisation with conventional functional silos, management, hierarchy, etc. In Synergistic-minded organisations, some adjustments can make FlowChain much more effective and better suited to that different kind of organisation.

Solution (in a Nutshell)

Flow•gnosis merges Prod•gnosis and FlowChain together, giving an organisation-wide, holistic solution which improves organisational effectiveness, reifies Continuous Improvement, speeds flowof new products into the market, provides an operational (value stream based) model for the whole business, and allows specialists from many functions to work together with a minimum of hand-offs, delays, mistakes and other wastes.

Rightshifting

Problem

Few organisations have a conscious idea of how relatively effective they are, and of the scope for them to become much more effective (and thus profitable, successful, etc.). Absent this awareness, there’s precious little incentive to lift one’s head up from the daily grind to imagine what could be.

Solution (in a Nutshell)

Rightshifting provides organisations with a context within which to consider their relative effectiveness, both with respect to other similar organisations, and more significantly, with respect to the organisation’s potential future self.

The Marshall Model

Problem

Few organisations have an explicit model for organisational effectiveness. Absence of such a model makes it difficult to have conversations around what actions the organisation needs to take to become more effective. And for change agents such as Consultants and Enterprise Coaches attempting to assist an organisation towards increased effectiveness, it can be difficult to choose the most effective kinds of interventions (these being contingent upon where the organisation is “at”, with regard to its set of collective assumptions and beliefs a.k.a. mindset).

Solution (in a Nutshell)

The Marshall Model provides an explanation of organisational effectiveness. The model provides a starting point for folks inside an organisation to begin discussing their own perspectives on what effectiveness means, what makes their own particular organisation effective, and what actions might be necessary to make the organisation more effective. Simultaneously, the Marshall Model (a.k.a. Dreyfus for Organisations) provides a framework for change agents to help select the kinds of interventions most likely to be successful.

Organisational Psychotherapy

Problem

Some organisations embrace the idea that the collective organisational mindset – what people, collectively believe about how organisations should work – is the prime determinant of organisational effectiveness, productivity, quality of life at work, profitability, and success. If so, how to “shift” the organisation’s mindset, its collective beliefs, assumptions and tropes, to a more healthy and effective place? Most organisations do not naturally have this skill set or capability. And it can take much time, and many costly missteps along the way, to acquire such a capability.

Solution (in a Nutshell)

Organisational Psychotherapy provides a means to accelerate the acquisition of the necessary skills and capabilities for an organisation to become competent in continually revising its collective set of assumptions and beliefs. Organisational Psychotherapists provide guidance and support to organisations in all stages of this journey.

Emotioneering

Problem

Research (cf Buy•ology ~ Martin Lindstrom) has shown conclusively that people buy things not on rational lines, but on emotional lines. Rationality, if it has a look-in at all, is reserved for post-hoc justification of buying decisions. However, most product development today is driven by rationality:

  • What are the customers’ pain points?
  • What are the user stories or customer journeys we need to address?
  • What features should we provide to ameliorate those pain points and meet those user needs?

Upshot: mediocre products which fail to appeal to the buyers’ emotions, excepting by accident. And thus less customer appeal, and so lower margins, lower demand, lower market share, and slower growth.

Solution (in a Nutshell)

Emotioneering proposes replacing the conventional requirements engineering process (whether that be big-design-up-front or incremental/iterative design) – focusing as it does on product features – with an *engineering* process focusing on ensuring our products creaate the emotional responses we wish to evoke in our customers and markets (and more broadly, in all the Folks That Matter™).

The Antimatter Principle

Problem

How to create an environment where the relationships between people can thrive and flourish? An environment where engagement and morale is consistently through the roof? Where joy, passion and discretionary effort are palpable, ever-present and to-the-max?

Solution (in a Nutshell)

The Antimatter Principle proposes that putting the principle of “attending to folks’ needs” at front and centre of all of the organisation’s policies is by far the best way to create an environment where the relationships between people can thrive and flourish. Note: this includes policies governing the engineering disciplines of the organisation, i.e. attending to customers’ needs at least as much as to the needs of all the other Folks That Matter™.

– Bob

Some Alien Tropes

September 4, 2018
Culture change, Marshall Model, Organisational effectiveness, Rightshifting, Software development
Leave a comment

Some Alien Tropes

Most people, and hence organisations, fear the alien, And by doing so, cleave to the conventional. Yet progress, change, and organisational effectiveness depend on embracing the alien.

“Problems cannot be solved with the same mindset that created them.”

~ Albert Einstein

To help folks understand what I mean by the phrase “alien tropes” here’s a short list of tropes from the Synergistic mindset. Very alien to all the Analytic-minded organisations out there.

  • Treat people like adults. In all things.
  • Allow people to choose their own terms, conditions, locations, salaries, equipment and ways of working together.
  • Understand who matters and what each of these individuals need.
  • Attend to all the needs of all the folks that matter.
  • Be aware of both the prevailing and the desired social dynamic in the organisation.
  • Think in terms of communities and teams, not individuals. Ensure all the policies of the organisation support this perspective.
  • Actively support and encourage self-organisation, self-management and self- determination (e.g. of teams).
  • People really do want to contribute, learn, make a difference and do the best they can.
  • Effective collaborative knowledge work is a learnable set of competencies.
  • Skilful dialogue is essential for effective teamwork and, as a skill, requires constant practice and development.
  • Intrinsic motivations add, extrinsic motivations subtract.
  • Productivity in collaborative knowledge work demands superior cognitive function.
  • Stress causes a decline in cognitive function.
  • Stress has many causes (fear, obligation, guilt, shame, lack of safety, …).
  • Eschew leadership in favour of e.g. fellowship.
  • Common (shared) purpose has a unique power.
  • Enthusiastically model and support discussion, debate, open-mindedness and the ability to change oneself and one’s assumptions, beliefs.
  • Alien tropes do not come naturally to people. Support their uptake.
  • Do not fear the alien; embrace it, use it, exploit it.

I’d be delighted to expand on any of the above, if and when invited to do so.

– Bob

 

Most Models Are Wrong

June 10, 2018
Culture change, Marshall Model, Organisational effectiveness, Rightshifting
Leave a comment

Most Models Are Wrong

“The most that can be expected from any model is that it can supply a useful approximation to reality: All models are wrong; some models are useful”.

~ George E. P. Box

George E. P. Box

George Edward Pelham Box FRS (18 October 1919 – 28 March 2013) was a British statistician, who worked in the areas of quality control, time-series analysis, design of experiments, and Bayesian inference. He has been called “one of the great statistical minds of the 20th century”. He repeated his aphorism concerning the wrongness of models in many of his papers.

The first appearance (1976) reads:

“Since all models are wrong the scientist cannot obtain a “correct” one by excessive elaboration. On the contrary following William of Occam he should seek an economical description of natural phenomena. Just as the ability to devise simple but evocative models is the signature of the great scientist so overelaboration and overparameterization is often the mark of mediocrity.”

 ~ George E. P. Box

He wrote later (1978):

Now it would be very remarkable if any system existing in the real world could be exactly represented by any simple model. However, cunningly chosen parsimonious models often do provide remarkably useful approximations. For example, the law PV = RT relating pressure P, volume V and temperature T of an “ideal” gas via a constant R is not exactly true for any real gas, but it frequently provides a useful approximation and furthermore its structure is informative since it springs from a physical view of the behavior of gas molecules.

For such a model there is no need to ask the question “Is the model true?”. If “truth” is to be the “whole truth” the answer must be “No”. The only question of interest is “Is the model illuminating and useful?”.

~ George E. P. Box

What’s A Model?

The Marshall Model belongs to the group of models collectively referred-to as Scientific Models.

“A scientific model seeks to represent empirical objects, phenomena, and physical processes in a logical and objective way. All models are in simulacra, that is, simplified reflections of reality that, despite being approximations, can be extremely useful. Building and disputing models is fundamental to the scientific enterprise. Complete and true representation may be impossible, but scientific debate often concerns which is the better model for a given task.

Attempts to formalize the principles of the empirical sciences use an interpretation to model reality, in the same way logicians axiomatize the principles of logic. The aim of these attempts is to construct a formal system that will not produce theoretical consequences that are contrary to what is found in reality. Predictions or other statements drawn from such a formal system mirror or map the real world only insofar as these scientific models are true.

For the scientist, a model is also a way in which the human thought processes can be amplified.”

“Models are typically used when it is either impossible or impractical to create experimental conditions in which we can directly measure outcomes. Direct measurement of outcomes under controlled conditions (see Scientific Method) will always be more reliable than modelled estimates of outcomes.”

The Marshall Model

I’ve written a number of blogs posts (plus a White Paper) on the Marshall Model, and its relationship with Rightshifting, so I’ll not repeat that material here.

How is the Marshall Model Useful?

  • Explains the fundamental source of productivity – or lack of it – in organisations generally.
  • Predicts the likely path of attempts to “go Agile or “be Agile”, embark on Digital Transformations, adopt Lean or Theory of Constraints, etc..
  • Situates a range of approaches to business productivity along a spectrum (the Rightshifting spectrum), in order of effectiveness.
  • Defines the challenge facing organisations that wish to significantly improve their productivity and effectiveness.
  • Illustrates the role of the collective psyche (within social systems).
  • Offers a way forward to higher productivity, joy, engagement and seeing folks’ needs better met.
  • Provides interventionists with insights in how to intervene in organisations seeking to improve, similar to the way the Dreyfus Model provides interventionists with insights in how to intervene in situations where individuals seek to improve their skills. (How to best adapt and adopt styles of intervention to suit where the organisation is at, in its journey towards maximum effectiveness).
  • Offers a seed for building a shared mental model of the factors governing an organisation’s relative effectiveness, as well as a means to understand the mental models typically in play within organisations.

Some time ago I wrote a post on how folks might use the Marshall Model.

Aside: Please let me know if you would value an elaboration of any of the above points.

Summary

“Truth … is much too complicated to allow anything but approximations.”

~ John von Neumann

The Marshall Model is not Truth. It is truthy, in that it has some utility as described above. It is a hypothesis, one I’d be delighted for folks to debate, dispute and discuss. Do you have, for example, your own go-to model for explaining organisational productivity? Where does the Marshall Model sit, for you, on the spectrum of “highly useful” through to “not very useful at all”? Would you be willing to share your viewpoint or hypothesis on organisational effectiveness and productivity?

– Bob

Further Reading

All Models are Wrong ~ Wikipedia Entry
Scientific Modelling ~ Wikipedia Entry
George E.P. Box ~ Wikipedia Entry
Mental Models ~ Wikipedia Entry
Models Are The Building Blocks of Science https://utw10426.utweb.utexas.edu/Topics/Models/Text.html

The Marshall Plan

June 8, 2018
Antimatter principle, Community, Culture change, Dialogue, Leadership, Organisational effectiveness, Organisational Therapy, Rightshifting, Software development, Teambuilding
2 Comments

The Marshall Plan

I guess most people, when they start a new job or client engagement, have in mind the things they want to do and see happen. Most likely, things they’ve seen or made happen in previous jobs or engagements. Along with, maybe, some things they’ve read or heard about and are minded to try out, given the opportunity. (And what better opportunity than the honeymoon period of a new job or client?)

We might choose to call this an agenda.

My Agenda

I’m no different, excepting perhaps the items that feature on my agenda:

  • Invite participation in discussing “who matters?” (with respect to i.e. the work and the way it works)
  • Empathise with the emergent community of “folks that matter” (not exclusively, but as a priority)
  • Invite folks to listen to each other’s volunteered observations, hear each other’s feelings, and explore each other’s needs.
  • Invite folks to solicit and then begin attending to each other’s requests (explicit and implicit)
  • Offer and provide support to folks and communities in their journeys

Note: I’ve not included on my agenda anything about specific actions that I myself might want to do and see happen, beyond the items listed. Specifically, although I’ve written often about strategies such as Flowchain, Prod•gnosis, Rightshifting, the Marshall Model, self-organising/managing teams, the quality of interpersonal relationships and interactions, etc., I don’t bring these into my agenda. If folks discover these strategies for themselves, they’re much more likely to understand their fundamentals, and maybe come up with even more effective strategies.

The Antimatter Principle is the only strategy I’ve regularly written about that recognisably features on my prospective agenda, and then only by extending invitations to participate in that strategy. (Note: Attentive readers may just notice the tip of the Organisational Psychotherapy iceberg peeking out from the above agenda).

I’ve reached a point in my journey where, keen as my ego is to see all my ideas (strategies) made manifest, my experience tells me that’s not the way to go for the best outcomes for the community as a whole.

As for the Marshall Plan, I believe it’s best, in the longer run, to have the folks involved (in particular, the people that matter) do their own discovery and learning. Discovering for themselves, over time – through means they also discover for themselves – effective strategies for attending to folks’ needs (often including the principles underlying those strategies). I see my role in this Plan as supporting – in whichever ways folks request, or say they need – this collective endeavour. Such support quite possibly to include actively helping the discovery and learning, whenever there’s an explicit (albeit refusable) request for me to do so.

– Bob

Further Reading

The Benefits of Self-directed Learning

Difficult Conversations

June 4, 2018
Antimatter principle, Dialogue, Listening, Nonviolent Communication, Organisational effectiveness, Rightshifting, Software development
1 Comment

Difficult Conversations

Before this turns into a mini-series, I’d just like to add one observation to my previous two posts.

Setting aside the outcomes sought by the people that matter, outcomes related to the business and its needs, there’s the not inconsequential matter of the unexpressed outcomes sought by these folks with respect to their own personal needs. Often, these needs are not discussed, shared or even registered at a conscious level by the individuals concerned. And often, then, explicit outcomes have yet to be identified – both by them and by us.

There’s not much point addressing the needs of the organisation (see my previous post) without also attempting, at least, to address the needs of the individual people that matter. This asks of us more effort, because we’re likely to be starting “further back”, before these folks have even expressed their personal sought outcomes. And because they may be reluctant to get into these kinds of conversations, being unusual in a workplace context. And then there’s the difficulty involved in “speaking to power” or at least empathising with people in positions of power.

Examples

Some examples may help clarify this observation.

Senior managers and executives, in articulating the sought outcomes listed previously, may also want to control the solutions chosen, hence their providing solutions in the form of wants. Often there’s an underlying need to feel “in control”, driven by some need, such as their need for order, or personal safety, or kudos.

Similarly, articulating their sought outcomes may, in part, derive from their need for tangible progress, or a need to be seen as the driver of that progress.

Summary

Entering into, and sharing the exploration of these often intensely personal topics is certainly difficult. But that difficulty can ease when we have the right conditions – such as trust, friendship, skill, and safety. And without such conversations, we’re that much more likely to spend much time and effort on delivering outcomes that no one really needs, or worse – that actively work against folks’ needs.

– Bob

Further Reading

Crucial Conversations ~ Patterson & Grenny
Difficult Conversations: How to Discuss What Matters Most ~ Patton, Stone, Heen & Fisher
Discussing the Undiscussable ~ Bill Noonan
Feelings Inventory ~ List at the Centre For Nonviolent Communication
Needs Inventory ~ List at the Centre For Nonviolent Communication

Wants, Needs

June 3, 2018
Antimatter principle, Dialogue, Engineering, Innovation, Lamentation, Leadership, Management, Organisational effectiveness, Product development, Rightshifting, Software development
1 Comment

Wants, Needs

My previous post seems to have struck a chord, judging by the number of retweets on Twitter. It also presents an opportunity to explore a perennial challenge of building things for other people: teasing out real needs from expressed wants.

Have you ever worked with business folks who articulate their wants in the form of solutions, rather than as solution-free “requirements”? As means rather than ends?

Let’s take another look at the list of desired outcomes (wants) appearing in the aforementioned post:

  • A more coherent, disciplined approach to software development
  • Improved governance and oversight
  • Improved estimates
  • Better due-date performance (reliable on-time delivery)
  • More visibility into project roadmaps
  • Common standards
  • Better project organisation
  • People working “in sync”
  • Senior management confidence (in e.g. the teams’ ability to deliver)
  • Higher staff motivation and engagement

Business Analysis for the Way the Work Works

From my days as a Business Analyst, I’ve learned that uncovering needs means having an ongoing dialogue with the people that matter. A dialogue in which we dig down, together, into the things they say they want, so as to uncover their real needs. Once we’ve teased apart the wants from the needs, we’re in a better place to choose effective strategies (solutions) for addressing those needs. Going with the superficial wants tends to box us in to the strategies (means) they provide. Strategies which often fall short of being effective.

I suspect what I’m talking about will become clearer as we examine in turn each item from the above list…

Item: A more coherent, disciplined approach to software development

This looks to me like a solution masquerading as a need. That’s to say “a more coherent, disciplined approach” seems like more like means to other ends, than and end in itself. What might those ends be? What might be the underlying needs driving this proposed solution? A dialogue with the people that matter seems in order here. A dialogue that could prove challenging, absent a degree of trust and willing collaboration. And even assuming we are all able to dig down towards the underlying needs, just as in building software there’s no guarantee we’ve identified those needs accurately, until we’ve built and delivered something and seen it “in production” long enough to gather some feedback. Active feedback, which also implies iteration and evolution: “Is this really meeting the needs of everyone that matters? Is it good enough yet? What else do we need to do to improve it further?” etc..

For illustration, I’ll take a stab at the needs which might underlie this want. Maybe some folks suppose that “a more coherent, disciplined approach” will bring order to the present chaos (a need for order). Maybe some folks suppose that “a more coherent, disciplined approach” will make delivery of e.g. features or product increments more predictable (a need for predictability).

Maybe productive and effective dialogue will uncover other latent needs implicit in this want.

Item: Improved governance and oversight

This also looks to me like a solution masquerading as a need.

Maybe some folks choose “Improved governance and oversight” as their automatic, default solution (strategy) for bring order to the present chaos (a need for order).

Item: Improved estimates

This again looks to me like a solution masquerading as a need.The No Estimates movement and debate has just about done this one to death. What might the supposed need for “improved estimates” imply. What’s really need here?

Item: Better due-date performance (reliable on-time delivery)

Whilst we could imagine this as yet another solution masquerading as a need, in this case I find this want more interesting, maybe closer to a real need than the previous two items.

I suspect some folks that matter may suppose that “better due date performance” is the obvious means to improve (external) customer satisfaction, and thereby revenue, repeat business, profit, market demand, market share, and other business metrics. Maybe those involved in the way the work works, armed with an explicit, agreed need to satisfy one or more specific business metrics, would be able to come up with ways of working which effectively address those metrics. In other words, valuable innovations.

Item: More visibility into project roadmaps

This again looks to me like a solution masquerading as a need. What might be the underlying need here? Maybe it’s something born of a feeling of powerlessness in the absence of information about what’s happening. Maybe it comes from a sense of frustration or embarrassment when having to face customers and investors expecting information about product release schedules, feature sets, and road maps. Whatever the case, an effective, productive dialogue may flush out some of those underlying feelings, and thereby lead to a better understanding of the needs we’re all trying to address.

Item: Common standards

Yet again this looks to me like a solution masquerading as a need. I’ve heard this want many times in numerous companies. This looks to me like an implicit solution to the question “how do we become more flexible, how can we cost-effectively deploy and redeploy our developers between projects and project teams as business priorities change?” I guess the people that matter suppose that “common standards” is the obvious answer. But it’s our job to understand the underlying need and come up with the most effective solution (strategy) for addressing it, not just the most common solution.

But I could be barking up the wrong tree about the presumed underlying need here, so I’d want to have conversations with the people that matter so as to really understand what they might be trying to achieve through addressing this want.

Item: Better project organisation

Another solution masquerading as a need. What might “better project organisation” bring us? Better due date performance? More visibility into project roadmaps and current status? See explanations, above, for the needs which might underlie *those* wants.

Item: People working “in sync”

Solution masquerading as a need. What might “people working in sync” bring us? Reduction in friction and waste? Improved flow (of products and features into the market)? Better due date performance? By digging down, though dialogue, we may uncover candidates for the underlying needs, which we can proceed to validate through delivering a way the work works, and getting feedback on the degree to which that way of working effectively addresses folks’ real needs.

Item: Senior management confidence (in e.g. the teams’ ability to deliver)

This is probably the one item in our list of sought outcomes that’s closest to a real need. We can intuit the scale of the problem (shortfall in senior management confidence) by looking at all the solutions they’re helpfully trying to provide us with, via the other items here. Solutions (masquerading as needs) that they believe will improve things and thereby deliver the boost in confidence they seek (and need). Ironically, the solutions they provide – being very much less effective solutions than those we can come up with for them, as experts – often undermine the very outcomes they seek.

Item: Higher staff motivation and engagement

Very laudable. But let’s not let the humanity of this want blind us to its nature as (yet another) solution masquerading as a need. What’s the end in mind? Why might the people that matter seek “higher staff motivation and engagement”?

So they can feel better about the culture for which they they feel responsible? As a means to increased throughput and thus improved revenues and profits? Again, until we know what they really need, any solutions we provide will likely fall well short of the mark. In other words, wasted effort.

Summary

So, we can see that taking “sought outcomes” at face value can lead us into sleepwalking into addressing superficial wants, and adopting other people’s (non-expert, relatively ineffective) solutions. Solutions which rate poorly on the effectiveness scale, and which in any case may well be addressing the wrong needs. I find it ironic just how much non-expert interference and micromanagement goes unnoticed, unchallenged and unlamented. Plenty of time for lamentation a year or two later.

Bottom line: When building software, the biggest risk lies in building the wrong thing (getting the requirements wrong), and it’s not any less of a risk when “building” – we might choose to call it “evolving” or even “engineering” – the way the work works.

– Bob

A Hiding To Nothing

June 2, 2018
Agile, Antimatter principle, Culture change, Dialogue, Engineering, Leadership, Management, Organisational effectiveness, Product development, Rightshifting, Software development
3 Comments

A Hiding To Nothing

Most large companies are on a hiding to nothing if and when they decide they’re “going Agile” for software development. “Going Agile” can only ever deliver the outcomes these companies seek if the whole organisation is prepared to change some of its fundamental beliefs about how organisations should be run.

Sought Outcomes

What outcomes do larger compares typically seek from “going Agile” in their software development teams? Here’s a partial list:

  • A more coherent, disciplined approach to software development
  • Improved governance and oversight
  • Improved estimates
  • Better due-date performance (reliable on-time delivery)
  • More visibility into project roadmaps
  • Common standards
  • Better project organisation
  • People working “in sync”
  • Senior management confidence (in e.g. the teams’ ability to deliver)
  • Higher staff motivation and engagement
  • Shorter timescales (i.e. “from concept to cash”)

Why These Outcomes Are Unrealisable

What’s not to like in the outcomes these companies seek by “going Agile”? Although maybe not comprehensive – they lack, for example, outcomes like “joy in work”, “folks getting their needs met”, “improved flow” and “customer delight” – there’s a bunch of stuff here I could get behind.

Setting aside the observation that some of the above “outcomes” – such as “common standards” and “people working in sync” – are more solutions than needs, “going Agile”, per se, is not the answer for delivering these outcomes. At least, not within the Analytic mindset world view.

Why the Analytic Mindset is the Blocker

With an implicit Theory-X, local optima (manage the parts separately) perspective, any and all solutions attempting to deiver these outcomes through “going Agile” are doomed to undermine the very outcomes sought.

It’s likely to start well, with much interest and hope expressed by the staff. After all, who wouldn’t want more autonomy, more mastery, more purpose in their work? But as things progress, existing company policies, rules, attitudes, etc. will begin to assert themselves. To the detriment of staff morale, motivation and engagement. Pretty soon, staff will begin to question the sincerity of the management in their support for “going Agile”. Pretty soon, it will start to become apparent to anyone who’s paying attention that existing policies, rules, etc., have to change fundamentally to see the outcomes sought begin to happen.

And with declining staff engagement in “going Agile”, and reducing enthusiasm for understanding the principles necessary for making Agile successful, progress will slow to a crawl. At this point, middle-management, who have to carry the burden of making “going Agile” happen will also begin, quietly, to question the wisdom of the senior management direction. This will lead to their more often reverting to orthodox, “tried and tested” (and less personally burdensome) ways of working. And more often baulking at the effort needed to push through adoption of more Agile practices.

What To Do?

So, what’s a company to do? Most companies will not realise, or want to hear, that the Analytic mindset is fundamentally incompatible with successfully “going Agile”. So, another Agile adoption failure is in the making.

Personally, having helped various companies face up to this challenge, I’d say:

“It’s extremely unlikely that you’ll want – or even be able – to give up your existing world view. At least in the short term. So something’s got to give. And it’s probably better that you give up on “going Agile”. But DON’T give up on wanting things to be better. Park your Agile aspirations, and try another path, another solution. After all, it’s the OUTCOMES you seek that matter, not some specific – and cargo-culted – solution.”

So what might that alternative solution look like? What can an unrepentantly Analytic-minded organisation do to improve its software development outcomes?

My recommendation would be to focus on the interpersonal relationships within and between departments. Help developers understand and relate to customers (both internal and external) better. Help other folks within the organisation better understand and relate to developers.

Leveraging these improving relationships, encourage multi-party, cross-function dialogue about the outcomes sought, and what folks of every stripe can do, every day, to begin to shift the organisation’s rules, policies, structures and assumptions.

In a nutshell, be less autocratic, directive and strategic, and more democratic, collegiate and opportunistic.

And remember, I’m here to help.

– Bob

Not Obviously Wrong

May 26, 2018
Culture change, Doctrine, General, Product development, Rightshifting, Software development
Leave a comment

Not Obviously Wrong

What’s obviously wrong in software and product development? The list is continually changing, but here’s some stuff which was not obviously wrong ten or twenty years ago, which has recently become obviously wrong, at least to many people in the world of software development:

Obviously Wrong

  • Big batches and queues of work (aka Waterfall)
  • Utilisation (i.e. keeping resources fully busy)
  • Ignoring stakeholders (a.k.a. The Folks That Matter™)
  • Big Design Up Front (BDUF) (a.k.a. long feedback loops, or none at all)
  • Violence in the workplace
  • The daily commute

And here’s a list of stuff which has not (yet) attained the status of “obviously wrong” – and so appears in the list labelled “Not Obviously Wrong”:

Not Obviously Wrong

  • Estimating (see: #NoEstimates)
  • Management
  • Command and control
  • Telling (ordering) people what to do
  • Leadership
  • Specialisation
  • Cost accounting
  • Projects (see: #NoProjects)
  • Big developments in big chunks with big groups of people
  • Ignoring the costs of delays
  • Testing (a.k.a. inspection)
  • Demanding compliance to defined ways of doing things (a.k.a. process dogma)
  • Separating ownership of the way the work works from the people that do the work
  • Agile
  • SAFe
  • Scrum
  • Kanban Method
  • Ignoring the Cost of (misconceived) Focus
  • Work (as contrasted with e.g. Serious Play)
  • Open plan offices
  • Local optimisations
  • Dress codes (suits, ties, etc.)
  • etc.

How do items get to move from the one list to the other? (note: everyone has their own two lists, and each item moves at different times for different folks). How do your two lists look, at the moment?

Unlearning

Looking at this another way, the obviously wrong list above has items that, although once not obviously wrong, now appear on many folks’ obviously wrong list, having made the transition through e.g. a process of reflection, evaluation, discussion and above all UNLEARNING.

No Hashtags

FWIW, it occurs to me that we might choose to regard the raft of #No… hashtags on Twitter as opportunities to consider in which of our own – and others’ – lists the related (hashtagged) topic appears.

– Bob

Do Nothing That Is Not Play

May 16, 2018
Culture change, Innovation, Nonviolent Communication, Organisational effectiveness, Rightshifting
Leave a comment

Do Nothing That Is Not Play

If we think about it calmly for but a moment, one logical outcome of nonviolence is folks not working for a living, but playing for a living.

Innovation

Many companies seem desperate for “innovation”. Is innovation more like to come about through folks doing what they’re told (“working”) or through playing with things, as they see fit? I posit the latter is far more likely.

And no, this is not some flight of fancy. Do we really embrace wholeheartedly the set of assumptions labelled by Douglas McGregor as Theory-Y?

Theory-Y assumptions are: (1) physical and mental effort are natural and most people (depending on the work environment) find work to be a source of satisfaction, (2) they generally, on their own motivation, exercise self-control, self-direction, creativity, and ingenuity in pursuit of individual and collective (company) goals, (3) they either seek responsibility or learn to accept it willingly, and that (4) their full potential is not tapped in most organisations.

Could it be that folks’ “full potential is not tapped in most organisations” because they are obliged to “work” rather than play?

Could it be that engagement (and productivity) would take an amazing leap forwards if we invited folks to “play” rather than “work”?

Could you have the courage to experiment to find out for yourself?

Or are we all so in thrall to what Walter Wink calls The Domination System that play as an alternative to work is undiscussable?

– Bob

Further Reading

Serious Play ~ Michael Schrage
The Importance of Play (A Valentine for Marshall Rosenberg, part 2) ~ John Kinyon
What If #7 – No Work ~ Think Different
The Human Side of Enterprise ~ Douglas McGregor
Theories of Motivation ~ Think Different

World Class? Really?

May 2, 2018
Engineering, General, Leadership, Management, Marshall Model, Organisational effectiveness, Product development, Rightshifting, Software development
1 Comment

World Class? Really?

Some six years ago now, I wrote a post describing what might characterise a world class software / product development / collaborative knowledge work business.

In the interim, I’ve had some opportunities to work on these ideas for various clients. My consequent experiences, whilst in no way invalidating that post, have thrown up different perspectives on the question of “world class”.

Firstly, do you want it? Moving towards becoming a world class business involves a shed load of work, over many years. Do you want to commit to that effort? Even though the goal sounds noble, ambitious, attractive, does your business have what it takes to even begin the journey in earnest, let alone stick at it.

Then, do you need it? Absent powerful drivers spurring you on towards the goal, will you have the grit necessary to keep at it? Or will the initiative flounder and drown in the minutiae of daily exigencies, such as the constant pressure to get product and features out the door, to keep investors satisfied with (short term) results, etc.? And is the ROI there, in your context? If you do keep on the sometimes joyful, oftentimes wearisome path, and attain “world class” status, will the effort pay back in terms of e.g. the bottom line?

If your answers to the preceding two questions are yes, then we can get down to considering the characteristics of a world class collaborative knowledge-work business.

What might it look like, that goal state? Here’s my current take:

Context

Just in case a little context might help, here’s a variant of the Rightshifting chart which illustrates world class in terms of relative effectiveness (i.e. how effective are world class organisations relative to their peers?) The yellow area highlights those organisations (those at least circa 2.5 times more effective than the median) we might consider world class:

Fields of Competency

Any world class collaborative knowledge-work business must have mastered a bunch of different fields of knowledge. That’s not to say everyone in the organisation needs to have reached mastery (Level 5 – see below) in every one of the follow fields. But there must be a widespread acquaintance with all these fields, and some level of individual competent in each.

I suggest the following Dreyfus-inspired model for characterising an individual’s (practitioner’s) level of competency (or action-oriented knowledge) in any given field:

Level One (Novice)

The Novice level in each Field invites practitioners to acquire the basic vocabulary and core concepts of the Field. Attainment criteria will specify the expected vocabulary and core concepts. The Novice level also invites practitioners to acquire and demonstrate the ability to read and understand materials (books, articles, papers, videos, podcasts, etc.) related to the vocabulary and core concepts of the Field.

Level Two (Advanced Beginner)

The Advanced Beginner level in each Field invites practitioners to acquire the ability to critique key artefacts commonly found in the given Field. The Advanced Beginner level also invites practitioners to read more widely, and understand different perspectives or more nuanced aspects of, and peripheral or advanced elements within the Field.

Level Three (Competent)

The Competent level in each Field invites practitioners to acquire and demonstrate a practical competency in the core concepts in the Field, for example through the ability to apply the concepts, or create key artefacts, unaided.
The Competent level also invites practitioners to acquire and demonstrate the ability to collaborate with others in exploring and applying the abilities acquired in the Novice and Advanced Beginner levels.

Level Four (Proficient)

The Proficient level in each Field invites practitioners to acquire and demonstrate the ability to prepare and present examples and other educational materials appropriate to the given Field. The Proficient level also invites practitioners to acquire and demonstrate the ability to coach or otherwise guide others in applying the abilities acquired in the Novice, Advanced Beginner and Competent levels.

Level Five (Master)

The Master level in each Field invites practitioners to acquire and demonstrate national or international thought leadership in the Field. This can include: making significant public contributions or extensions to the Field; becoming a publicly recognised expert in the Field; publishing books, papers and/or articles relevant to the Field; etc.

The Fields

Any business that aspires to world class status must attain effective competencies in a wide range of different fields. The following list suggests the fields I have found most relevant to collaborative knowledge-work business in general, and software / product tech businesses in particular:

Flow

  • Flow (product development) (n): the movement of the designs, etc., for a product or service through the steps of the design processes which create them.
  • Continuous Flow (n): The progressive movement of units of design through value-adding steps within a design process such that a product design or service design proceeds from conception into production without stoppages, delays, or back flows.
  • See also: Optimised Flow Demonstration (video)

Deming

  • * Many in Japan credit Bill Deming for what has become known as the Japanese post-war economic miracle of 1950 to 1960.
  • William Edwards Deming (October 14, 1900 – December 20, 1993) was an American engineer, statistician, professor, author, lecturer, and management consultant. Deming is best known for his work in Japan after WWII, particularly his work with the leaders of Japanese industry.

Risk Management

  • Risk management is the discipline and practice of explicitly identifying and managing key risks.

    “Risk Management is Project Management for grown-ups.”
    ~ DeMarco & Lister

  • Potential benefits include:
    • makes aggressive risk-taking possible
    • protects us from getting blindsided
    • provides minimum-cost downside protection
    • reveals invisible transfers of responsibility
    • isolates the failure of a subproject
  • Note; Many Agile practices are, at their heart, about risk management.

Mindset

  • Mindset a.k.a. collective (organisational) memeplex (n): A set of memes (ideas, assumptions, beliefs, heuristics, etc.) which interact to reinforce each other.

“A memeplex is a set of memes which, while not necessarily being good survivors on their own, are good survivors in the presence of other members of the memeplex.”
~ Richard Dawkins in The God Delusion

  • The “organisational mindset” is a set of beliefs about the world and the world of work which act to reinforce each other.
  • These interlocking beliefs tightly bind organisations into a straight-jacket of thought patterns which many find inescapable. Without coordinated interventions at multiple points in the memeplex simultaneously, these interactions will prevail, as will the status quo.

Requirements a.k.a. Needs Management

  • A more or less formal approach to identifying and communicating needs
  • Any approach that ensures that everyone involved in attending to the identified needs shares a clear understanding of the required outcome(s): “doing the RIGHT thing”.

Fellowship

  • A system of organisational governance based on the precepts of Situational Leadership and with a primary focus on the quality of interpersonal relationships as a means to improved organisational health and effectiveness.
  • More generally, paying attend to the quality and effectiveness of the collaborative relationships across and through the business (and the extended value network of which it is a part).

Cognitive Function

  • Cognitive function (Neurology) (n): Any mental process that involves symbolic operations–e.g. perception, memory, creation of imagery, and thinking; Cognitive Function encompasses awareness and capacity for judgment.
  • Effectiveness of collaborative knowledge work is dictated by both e.g. quality of interpersonal relationships and degree of Cognitive Function.
  • See also: Cognitive Science

PDCA

  • PDCA (plan–do–check–act, or plan–do–check–adjust) is an iterative four-step method used for the control and continuous improvement of processes and products. It is also known as the Deming circle/cycle/wheel, Shewhart cycle, control circle/cycle, or plan–do–study–act (PDSA).
  • Based on the scientific method, (Cf. Francis Bacon) e.g. “hypothesis” – “experiment” – “evaluation”.

Statistical Process Control (SPC)

  • Statistical process control (SPC) is a method of quality control which uses statistical methods. SPC is applied in order to monitor and control a process.
  • Key tools used in SPC include control charts; a focus on continuous improvement; and the design of experiments.
  • See also: The Red Beads and the Red Bead Experiment with Dr. W. Edwards Deming (video)

Lean Product Development

  • Lean Product Development applies ideas from Lean Manufacturing to the design and development of new products (See e.g. books by Allen Ward and Michael Kennedy)
  • Aims to improve the flow of new ideas “from concept to cash”.
  • Can also help raise levels of innovation.
  • Exemplar: TPDS (Toyota Product Development System)

Don Reinertsen’s Work

  • Don Reinertsen is the author of three of the most definitive and best-selling books on product development.
  • His 1991 book, Developing Products in Half the Time is a product development classic.
  • His 1997 book, Managing the Design Factory: A Product Developer’s Toolkit, was the first book to describe how the principles of Just-in-Time manufacturing could be applied to product development. In the past 16 years this approach has become known as Lean Product Development.
  • His latest award-winning book, The Principles of Product Development Flow: Second Generation Lean Product Development, has been praised as, “… quite simply the most advanced product development book you can buy.”

Neuroscience

  • (Cognitive) neuroscience is concerned with the scientific study of the biological processes and aspects that underlie cognition, with a specific focus on the neural connections in the brain which are involved in mental processes.
  • (Cognitive) neuroscience addresses the questions of how psychological/cognitive activities are affected or controlled by neural circuits in the brain. Cognitive neuroscience is a branch of both psychology and neuroscience, overlapping with disciplines such as physiological psychology, cognitive psychology, and neuropsychology.
  • See also: Cognitive Function

Theory of Constraints

  • The Theory of Constraints (TOC) is a management paradigm originated by Eliyahu M. Goldratt.
  • TOC proposes a scientific approach to improvement. It hypothesises that every complex system, including manufacturing processes, consists of multiple linked activities, just one of which acts as a constraint upon the entire system (the “weakest link in the chain”).
  • TOC has a wide range of “thinking tools” which together form a coherent problem-solving and change management system.

Self-organisation

  • Self-organisation (n): Ability of a system to spontaneously arrange its components or elements in a purposeful (non-random) manner. It is as if the system knows how to ‘do its own thing.’ Many natural systems such as cells, chemical compounds, galaxies, organisms and planets show this property. Animal and human communities too display self-organization.

    “An empowered organization is one in which individuals have the knowledge, skill, desire, and opportunity to personally succeed in a way that leads to collective organisational success.”
    ~ Stephen R. Covey

Quantification

  • In mathematics and empirical science, quantification is the act of counting and measuring that maps human sense observations and experiences into members of some set of numbers. Quantification in this sense is fundamental to the scientific method.
  • See also: Tom Gilb

Systems Thinking

  • Systems thinking provides a model of decision-making that helps organisations effectively deal with change and adapt.
  • It is a component of a learning organisation – one that facilitates learning throughout the organisation to transform itself and adapt.
  • See also: Peter Senge, Russell L. Ackoff, Donella Meadows, etc.

Psychology

  • Psychology (n): the study of behaviour and mind, embracing all aspects of conscious and unconscious experience as well as thought. It is an academic discipline and an applied science which seeks to understand individuals and groups.

Argyris

  • An American business theorist, Professor Emeritus at Harvard Business School, and known for his work on interpersonal communication, organisational effectiveness, double-loop learning and learning organisations.
  • See also: Action Science.

Psychotherapy

  • Psychotherapy (n): interventions which facilitate the shifting of perspectives and attitudes, and thus, human behaviours.
  • See also: Organisational Psychotherapy

To the above list of Fields, I invite you to add any which may have specific resonance or relevance to your own business.

And then there are the lists of technical capabilities you need to be present in your various business functions, too.

Aside – CMMI

As an aside, CMMI also provides an extensive list of “capability areas” ( circa 128 different areas, last time I looked) focussed on engineering capabilities. Note: I find the CMMI list useful, but only as a primer, not as a full-blown recipe for success.

Summary

All the above begs the question: how to get there? And, how close are you to world class, so far?

– Bob

Holistic Solutions for Product Development Businesses

March 17, 2018
Culture change, Flow•gnosis, Flowchain, Innovation, Organisational effectiveness, Product development, Rightshifting, Software development
Leave a comment

Holistic Solutions for Product Development Businesses

Several people have been in contact this week to say “It’s all very well talking about holistic solutions for software development, but who really has any notion of what that might even look like?”

Which is a fair question.

Aside: Let’s note that the phrase “holistic solution for software development” is an oxymoron of the first order. By definition, software development is but part (and generally a small part) of any solution that addresses customer or market needs. Even software “pure plays” have a lot of non-software components.

So, I thought I’d describe just one holistic solution for whole organisations that develop new products containing some software. For want of a better name, I’ll call it this example “Flow•gnosis”. With this example, I hope that maybe one or two readers might find a spark of insight or inspiration to broach the question of a True Consensus in their own organisation.

I’ll try to keep this post brief. I’d be happy to come talk with you about holistic product development solutions for organisations, in person, if you have any real interest.

Flow•gnosis?

Flow•gnosis is a hybrid born of FlowChain and Prod•gnosis. FlowChain is not specifically a holistic solution, focussing as it does on improving the flow of knowledge work through a development group or department whilst moving continuous improvement “in-band”. Prod•gnosis is specifically a holistic solution for effective, organisation-wide product development, but says little about how to organise the work for e.g. improved flow or continuous improvement.

Together, they serve as an exemplar of a holistic solution for knowledge-work organisations, such as software product companies, software houses, tech product companies, and organisations of every stripe with in-house product development needs.

Let’s also note that Flow•gnosis is just an example, to illuminate just a few aspects of a holistic solution. Do not under any circumstances consider copying it or cloning it. Aside from the lack of detail presented here, you’d be missing the whole point of the challenge: building a True Consensus, as a group, with your people, in your context.

What’s the Problem?

Before talking more about a solution, what’s the problem we’re trying to solve?

I’ll work through an almost universal problem facing organisations that “do” software development. A problem that some enterprising supplier or management team might choose to address with an “innovative” solution.

Understanding the Problem

Here are some typical Undesirable Effects (UDEs) I hear from many companies involved in software and product development:

UDE: Delivery is not fast enough (long time-to-market)

UDE: New products cost too much to develop (high cost to bring to market)

UDE: We struggle to keep our products at the cutting edge

UDE: We always drop balls in hand-offs of tasks (i.e. between specialists, or business functions)

UDE: Continual contention for in-demand specialists

(For the sake of brevity, I’ll skip the building and analysis of the cause and effect graph. Your analysis will be different, in any case).

Root cause: Developing new software, products and services through a byzantine labyrinth of tasks and hand-offs, between and across dozens of specialisms within the company and its network of suppliers and distributors. This approach causes many delays (waste of time), mistakes (waste of effort, money), contention of resources, etc.

Conflict: A) Specialists must work together in their own specialist groups or silos to maintain their cutting-edge skills and know-how. B) Specialists from across all specialisms must work together as a group else handoffs and queues will cause many delays and mistakes.

Conflict arrow: Specialists cannot work in their own groups advancing their specialist knowledge at the same time as they work together with other kinds of specialist on new product ideas.

Flawed assumption at the root of the conflict: Specialists must work together. What makes this so? Only the old rules of the organisation. That silos (a.k.a. business functions) “own” their clutch of specialists. What if we changed that rule? (Note: this change is one key element of Toyota’s TPDS). And if we changed that rule, what other rules would we need to change too?

A Bird’s Eye View of Flow•gnosis

Prod•gnosis looks at an organisation as a collection of parallel Operational Value Streams, each dedicated to the selling and support of one of the organisations’ (whole) product or service lines. And each with its own team or collection of people doing the daily work of that operational value stream. Further, Prod•gnosis asks “How do these operational value streams come into being?” And answers with “They are made/created/developed by a dedicated Product Development Value Stream.”

FlowChain describes a way of working where a pool of self-organising specialists draws priority work from a backlog, executes the work, and delivers both the requested work item, and posting new work items (for improving the ways the work works) into the backlog. In this way, FlowChain both improves flow of work through the system, and brings continuous improvement “in-band”

By merging Prod•gnosis and FlowChain together into Flow•gnosis, we have an organisation-wide, holistic example which improves organisational effectiveness, reifies Continuous Improvement, speeds flow of new products into the market, provides an operational (value stream based) model for the whole business, and allows specialists from many functions to work together with a minimum of hand-offs, delays, mistakes and other wastes.

The latter point is perhaps the most significant aspect of Flow•gnosis. Having customer, supplier, marketing, sales, finance, logistics, service, billing, support and technical (e.g. software, usability, emotioneering, techops, etc.) specialists all working together (cf. Toyota’s Obeya or “Big Room” concept) enables the evolution of “Mafia Products” and “Mafia Offers” which the more traditional silo-based models of business organisation just can’t address effectively.

Out With the Old Rules, In with the New

Flow•gnosis is an innovation. Irrespective of the promised benefits of Flow•gnosis, we have learnt in recent posts that adopting an innovation ONLY brings benefits when we change the rules.

Let’s apply the four questions to our Flow•gnosis innovation and see what rule changes will be necessary to truly reap the benefits.

Q1: What is the POWER of Flow•gnosis?
A1: Flow•gnosis makes it commercially feasible for a company to repeatably come to market with new “Mafia Products”.

Mafia Product: “A product (or service) so compelling that your customers can’t refuse it and your competition can’t or won’t offer the same.”

Q2: What limitation does Flow•gnosis diminish?
A2:  Serialisation of specialist work (passing things back and forth between various specialist and business functions).

Q3: What existing rules served to help us accommodate that limitation?
A3: Handoffs. Queues. Batches. Separation of command and control from the work. Process. Process conformance. Local measures. Constant expediting. Critical path planning (Gannt charts, WBS). Local optima. Functional management (discrete management of each separate business function).

Q4: What (new) rules must we use now?
A4: Flow. Value streams. SBCE. Holistic measures. Ubiquitous information radiators. Cost Of Delay prioritisation. Buffer management. Constant collaboration. Dedicated teams of generalising specialists. Self-organisation. In-band continuous improvement. Resource levelling. Limits on WIP.

Summary

This post has been a – necessarily brief – look at one holistic solution to (software) product development. Crucially, we have seen how old rules have to be replaced, and what many of the replacement new rules might look like.

I invite you to remember that Flow•gnosis is just an broad-brush example of a holistic solution. Please don’t consider copying it or cloning it. And remember the real challenge: building, as a management group, a True Consensus.

– Bob

Further Reading

Meeting Folks’ Needs At Scale – Think Different blog post

Obstacles to True Consensus – Summary

March 15, 2018
Culture change, Dialogue, Innovation, Organisational effectiveness, Rightshifting
1 Comment

Obstacles to True Consensus – Summary

[Tl;Dr: Major improvements in the effectiveness of any organisation go begging, because the skills and experience for reaching the necessary True Consensus are almost always absent.]

This is the final post in my recent mini-series about obstacles to True Consensus.

The Big Picture

Let’s step back and try to take in the big picture for a moment.

I most often label this big picture “Organisational Effectiveness”. You might prefer to call it “improving the bottom-line”, “productivity”, or simply “success”.

Why does this big picture matter to me? Because of the impact ineffective organisations have on the people who work in them, on the people who depend on their products and services, and on society as a whole.

Employees

I’m a software engineer at heart. I have so many times worked with software engineers and other folks wanting to make a difference in the world, and being unable to do so because of the ineffectiveness of the organisations within which they work. Sooner or later, these folks simply give up on their dreams and “check out” (remaining employed but disengaged) or quit. Having been in the same boat myself on any number of occasions, I feel like I can relate. And, BTW, that’s why I now serve organisations in the role of Organisational Psychotherapist, actually doing things – albeit non-software engineering things – to “make a difference”.

Customers

I’m a customer of these organisations, too. We all are. Not out of choice, let me add. I have in mind the various organs of state, in which we have no say regarding the shoddy services and lame products they foist on us. Not that most private corporations are much better.

Society

How do ineffective organisations impact society? Apart from the waste of public money (many are in the public sector) that could be put to better use elsewhere, the sheer number of ineffective organisations lead us all to believe that ineffectiveness is normal and unavoidable. We seem to have lost the belief that we can ever expect to see things become better.

The Key to Improved Effectiveness

It’s pretty much accepted that the ability to transcend paradigms (an organisation’s beliefs, assumptions and rules about work) is the greatest lever to improve effectiveness. And by effectiveness, I mean reducing or eliminating things that should not have been done but nevertheless were done. See my recent post: Reliability and Effectiveness for details and objective measures of this.

In other words, the prevailing paradigm, or mindset or memeplex governing an organisation determines its effectiveness. And so, it’s obvious that to improve effectiveness, we must “shift” this paradigm. This is where most organisations falter and fail. They have no experience or capability in achieving a True Consensus. Such a thing looks like an impossibility.

Aside: Agile

In case you’re wondering if there’s any relevance to tech companies and their employees and customers: All flavours of Agile are essentially forms of local optima. Local optima, in that Agile initiatives are almost always limited to one silo (the “development” or “IT” silo) in the organisation. Most people in organisations doing software development are obliged to place their faith in systems of local optima. This is because the prospect of building a True Consensus across the whole organisation seems so daunting, so impossible, so contrary to prevailing behaviours, as to never receive serious consideration or discussion. And so, systemic ineffectiveness is locked in.

True Consensus

A “True Consensus” is when ALL top managers agree on the exact SAME action plan, with each and every top manager regarding his or her components of the joint action plan as his or her own baby.

Whether in a single organisation, or society as a whole, True Consensus is a prerequisite for concerted action to make things better, to make things more effective. On the path towards effective organisations, progress will only come about if the top teams, and eventually their whole organisations, can agree on their core problems and find coherent, holistic ways forward, together. True Consensus is the necessary prerequisite for Rightshifting any organisation.

This mini-series and its precursors has described one path to arrive at such a True Consensus, including describing the obstacles we can expect to encounter along the way, and ways of overcoming those obstacles.

In brief, the described path consists of repeatedly practicing, as a group and emergent leadership team, these steps:

  • understanding the core conflict in a problem by discovering the inherent flawed assumption
  • agreeing on a direction for a solution
  • elaborating that direction into a full (holistic, company-wide) solution or plan of action
  • agreeing on how to implement that full solution
  • enacting the implementation

You can find more details in the posts of this mini-series:

Obstacles to True Consensus – The Dominant Impatient Visionary

Obstacles to True Consensus – The Smart Conservative

Obstacles to True Consensus – Extrapolating From the Past

Obstacles to True Consensus – Solutioneering

Obstacles to True Consensus – Summary (this post)

and in the four posts prior to the mini-series itself:

Organisational Psychotherapy and the Bottom Line

Pillars

Innovation ALWAYS Demands We Change the Rules

Reliability and Effectiveness

And you can find even more in-depth elaboration of these ideas in e.g. Goldratt’s audiobook “Beyond The Goal”.

– Bob

Further Reading

Beyond the Goal ~ Eliyahu M. Goldratt (Audiobook only)
Leverage Points: Places to Intervene in a System ~ Donella Meadows
The Asch Conformity Experiment (Video)

Organisational Psychotherapy and the Bottom Line

March 9, 2018
Culture change, Management, Organisational effectiveness, Organisational Therapy, Rightshifting
1 Comment

Organisational Psychotherapy and the Bottom Line

The core of the Rightshifting message is:

For those interested in bottom-line results, the results of the holistic (Synergistic) approach always dwarfs the results of the Analytic approach.

A system of local optimums is not an optimum system at all; it is a very inefficient and ineffective system.

Because of interdependence and variation, the optimum performance of a system as a whole is not the same as the sum of all the local optima.

If all the components of a business system [i.e. the organisation’s silos] are performing at their maximum levels, the system as a whole will not be performing at its best (or anywhere near its best!).

And that’s why, if we’re truly driven by bottom-line results, we might consider doing everything we can to move to a holistic (a.k.a. Synergistic) approach.

The Main Blocker

But what’s the main blocker to our moving in that direction? All senior executives in a company may agree in principle that a holistic approach is desirable. And yet, so infrequently do companies actually take concerted action to make this happen. Why is this?

True Consensus

Absent a “True Consensus”, action will be unlikely.

What is a “True Consensus”?

A “True Consensus” is when ALL top managers agree on the exact SAME action plan, with each and every top manager regarding his or her components of the joint action plan as his or her own baby.

So, how to reach such a true consensus? It can, so often, look like an impossibility.

What are the real obstacles (barriers) to a “True Consensus”?

For the most part, the real obstacles are the behaviours of key people. Not dysfunctional behaviours, though, but the outstanding, positive behaviours that have got the company to the successful place it occupies today.

These key people include: the Dominant Impatient Visionary (a.k.a. the engine of the company),  the Smart Conservative, and others who extrapolate from past experience.

Note: for expanded definitions of these character types, see later posts in this series, including:

Obstacles to True Consensus – The Dominant Impatient Visionary

Obstacles to True Consensus – The Smart Conservative

Obstacles to True Consensus – Extrapolating From the Past

Obstacles to True Consensus – Solutioneering

Facilitating a True Consensus

How, then, to bring these key people closer together in such a way that they can arrive at the necessary True Consensus? And at the shared Action Plan? And keep them aligned and on course as that shared Action Plan unfolds?

Here’s where Organisational Psychotherapy can help. Organisational Psychotherapy increases the quality and effectiveness of the dialogues between a company’s key people. Dialogues without which the building of a True Consensus will most likely fail to get off the ground, stall or dissipate.

Over To You

How will you and your peers go about building the True Consensus necessary to unlock the power of the holistic approach in your company? Could you use those hugely improved bottom-line results? Or is your current self-image, and set of assumptions, beliefs and tropes, more important to you than bottom-line results?

– Bob

Further Reading

Beyond the Goal ~ Eliyahu M. Goldratt (Audiobook only)

Reliability and Effectiveness

March 6, 2018
Marshall Model, Metrics, Organisational effectiveness, Rightshifting
1 Comment

Reliability and Effectiveness

Many times when presenting either the Rightshifting curve:

or the Marshall Model:

I have been asked to define “Effectiveness” (i.e. the horizontal axis for both of these charts). I have never been entirely happy with my various answers. But I have recently discovered a definition for effectiveness, including a means to measure it, which I shall be using from now on. This definition is by Goldratt, as part of Theory of Constraints, and appears in his audiobook “Beyond the Goal”.

Measurements

Measurements serve us in two ways:

  1. As indicators of where we are, so we know where to go. For example, the dials and gauges on a car’s dashboard.
  2. As means to induce positive behaviours.

We must always remember, though, that we are dealing with humans and human-based organisations:

“Tell me how you measure me and I’ll tell you how I behave.” ~ Goldratt

We must choose measurements to induce the parts to do what’s better for the company as a whole. If a measurement jeopardises the performance of the system as a whole, the measurement is wrong.

Companies already have one set of measurements which measure their performance as a whole: their Financial measurements: e.g. Net profit (P&L) and investment (Balance Sheet)

What about when we dive inside the company as a whole, though? We then have two areas in which we have to conduct measurements:

  1. Support for and evaluation of management decisions
  2. Oversight on execution (how well are we executing on the decisions we’ve made?)

We generally don’t have good measurements in terms of decisions, nor good measurements in terms of execution.

We have to remember we’re dealing with human beings. And as long as we’re dealing with human beings, we have to realise that by judging any person on more than five measure, we’re creating anarchy. Simply because, with more than five measurements, people can basically do whatever they like, and likely still score high on one of them. And their bosses can nail them on some measurement they fail to deliver against. More than five measurements is conceptually wrong.

Categories of Measurement

So, how to categorise thing so that human beings can grasp the situation? Can we do better than we do now? Theory of Constraints suggests we can.

What resources do we have to help us formulate measurements in each of the above two areas; management decision-making, and execution of those decisions?

  • For decision-related measurements – there are lots of resources available to help e.g. books on Throughput Accounting.
  • For execution-related measurements – there is next to nothing published anywhere.

Continuous Improvement

I’ll not make the case for continuous improvement here. But if we wish to induce people to continuously improve, where should we focus our measurements? On things that are done properly, or on things that are not done properly? Which of these two foci better drives action? Focussing on the things we’re doing properly tends not to drive improvement. So we must concentrate on things that are not done properly.

How many things are not done properly? Kaplan suggests that in most businesses, there are more than twenty categories of things that are not done properly. But for humans to grasp our measures, we have already decided we need at most five categories, categories that completely cover everything that is not done properly, with zero overlap or duplication. Finding a way to categorise things that meets our criteria here is a nontrivial challenge.

Goldratt says there are only two categories:

  1. Things that should have been done but were not.
  2. Things that should not have been done but nevertheless were done.

Just two categories, with zero overlap. Beautifully simple.

And each of the above two categories already have a word defining them:

  1. Things that should have been done but were not – unreliability.
  2. Things that should not have been done but nevertheless were done – ineffectiveness.

Let’s swap these around into positive terms: Reliability, and Effectiveness.

Lovely.

Reliability and Effectiveness

Can we find measures to quantify Reliability and Effectiveness? How can we put numbers on our reliability? How can we put numbers on our effectiveness? Because, without numbers, we’re not measuring.

Let’s consider what is the end result of being reliable, in terms of the system as a whole. And what is the end result of being effective, in terms of the system as a whole? Not in financial terms though, as reliability and effectiveness are not financial things. We know this intuitively.

Reliability

Things that should have been done but were not.

The end result of being unreliable, in terms of the system as a whole, is that the company fails to fulfil its commitments to the external world. In other words, the company fails to ship on time. Do we already measure on-time shipment? Yes. We call it Due Date Performance. That’s a measure of how much we ship on time. “Our company Due Date Performance is 90%”. The unit of measure is almost always “percent”. What behaviour does this unit of measure trigger? Does it trigger behaviour that is good for the company? No. It encourages us to sacrifice on-time shipment of difficult, larger shipments in favour of smaller, easier shipments. So the dollar value of the sale must be part of any reliability measurement. We cannot ignore the dollar value. And neither is time is a factor in percent units. How late is each late shipment? We must include time, too. So, let’s change our “Reliability” units from “percent” to “Throughput dollar days” – the sales dollar value of each orders that is late, multiplied by the number of days it is late, summed across all late orders. The sum total is the measurement of our (un)reliability.

This is of course  a new unit of measure: Throughput-dollar-days. To infer trends, or to compare the performance of e.g. groups or companies, we will need time to train our intuition in the significance of this new unit of measure. As we begin to get to grips with this new unit of measure, it can help to present it as an indicator (a number in some fixed range, say 1-10, or as we use in Rightshifting, and the Marshall Model, 0-5) until we have adjusted to the Throughput-dollar-days measure.

Effectiveness

Things that should not have been done but nevertheless were done.

If we do things that we should NOT have been doing, what is the end result? Inventory. Do we already measure inventory? Of course we do. But how do we presently measure inventory? Either in terms of a dollar value, for example “$6 million of finished good inventory”, or in terms of a number of days, for example “60 days of finished goods inventory”. But both dollars AND time are important. Existing units of measurement for inventory drive unhelpful local behaviours like over-production and poor flow. So, how to measure to induce helpful behaviours? For each item of inventory, let’s use the dollar value of the inventory multiplied by the number of days that we’re holding that inventory under our local authority. We’ll call this unit of measure “Inventory-dollar-days”.

And one more measure of effectiveness: local operating expense. (For example, scrap, or salaries – with a given subunit of the company).

Note: We can fold quality into these measures simply by not recognising a sale, or a reduction in inventory, until the customer accepts the items (i.e. until the items meet the customer’s quality standards).

Summary

Now we have means for defining effectiveness, (and reliability) in a way in which we can also measure it. I feel very comfortable with that.

– Bob

Further Reading

Beyond the Goal ~ Eliyahu M. Goldratt (Audiobook only)

Relevance Lost: Rise and Fall of Management Accounting ~ Kaplan & Johnson

The Goal ~ Eliyahu M. Goldratt

Throughput Accounting ~ Thomas Corbett

The Balanced Scorecard: Translating Strategy into Action ~ Kaplan & Norton