Archive

Culture change

A Star is Born

I’d like to tell you about my new book, “Hearts over Diamonds”. Moreover, I’d love for you to tell your friends about it, too. And about the new field it illuminates: Organisational Psychotherapy.

A New Star

Not a “celebrity” kind of star. And certainly, not me. No, a True North kind of star. A guiding star. A shining beacon in the darkness of the enduring 50+ year Software Crisis.

I’m talking about Organisational Psychotherapy, and specifically the birth of a new approach to organisational change. The kind of organisational change necessary for tackling – and maybe even ending – the Software Crisis. The kind of change necessary for organisations, finally, to start getting to grips with challenges like exploiting digital technologies, implementing business transformations, and conducting effective product development.

Organisational Psychotherapy is a new field. Some have called it revolutionary. Although grounded in over a century of global psychotherapy and group dynamics research and practice, the idea of applying therapy techniques to organisations is not widely known or understood. In the hope of making these ideas more accessible and raise the profile of this revolutionary new field, may I invite your to take a look? 

Hearts over Diamonds – the Book

It’s been ten years in the making, and a year in the writing, but it’s finally done. My new book on Organisational Psychotherapy, that is. The book is not about software development, product development or even Digital Transformation as such. Its scope is much broader, and answers the question “How might we go about building highly successful organisations wherein everyone’s needs are met?”.

The book’s title is “Hearts over Diamonds”, and you can find it on Leanpub. The title refers to the newly-dawning reality that when organisations focus on compassion, joy, meaningful relationships and humanity (hearts), their bottom line (diamonds) improves significantly. 

As Dr. Martin Seligman puts it:

”If you want wellbeing, you will not get it if you care only about accomplishment [e.g. profit]. If we want to flourish, we must learn that the positive business and the individuals therein must cultivate meaning, engagement, positive emotion, and positive relations – as well as tending to profit.”

~ Dr. Martin Seligman, Director of the Penn Positive Psychology Center

Current approaches to change, and to building effective collaborative knowledge-work organisation, are not working. I commend Organisational Psychotherapy to you as an alternative approach that offers the prospect of more success. My book aims to inform you as to why that might be.

– Bob

Management Must Manage

Years ago, when I was starting out in my study of management methods, I came across ITT and its then president, Harold S. Geneen. Setting aside his connection with Phil Crosby and the ZeeDee (Zero Defects) quality movement, Geneen was famous for many things, including one quote which has stuck with me ever since I first heard it:

“Management must manage.”

What a soundbite!

Taken at face value, it’s a homily. Management must manage. Those with management responsibilities must execute those responsibilities (rather than dicking around with other things). “Well, of course. What else would they do?”

But there’s another meaning I choose to also find within. Management must manage: when we have people appointed to management positions, those people are the ones that must manage, not some others.

The whole Agile shambles, most often labelled AINO (Agile In Name Only), stems largely from ignoring this second interpretation of Geneen’s admonition.

Early Agilists, wanting to escape from the oversight of managers who had different opinions about how to manage software development, created Agile to wrest de-facto management responsibility from those managers. Thus grew the lame-assed version of self-organisation and self-managed teams so widespread today. I say lame-assed because almost no Agile team is self-managed. How could they be, when managers still have the authority and positional power to manage?

So we have instead a festering conflict of responsibilities, causing confusion and resentment all around, and dragging down engagement and productivity. Agile can “work” when the split of management responsibilities are made crystal clear for all concerned. And when that split has the blessing of management. This is almost never the case.

So, management must manage. Not developers. Not dev teams.

That sucks. Until we realise that it can be no other way. And even then, it still sucks, unless dev teams themselves have the responsibility and authority to manage. Where the dev teams are the management. Then we have the best of both worlds. A world of autonomy, mastery and purpose. A world of engaged people aligned to a common purpose and a common approach.

– Bob

Digital Transformation

It seems like “Digital Transformation” of organisations is all the rage – or is it fear? – in C-suites around the world. The term implies the pursuit of new business models and, by extension, new revenue streams. I’ve been speaking recently with folks in a number of organisations attempting “Digital Transformation”, some for the fourth or fifth time. I get the impression that things are not going well, on a broad front.

What is Digital Transformation?

Even though the term is ubiquitous nowadays, what any one organisation means by the term seems to vary widely. I’ll attempt my own definition, for the sake of argument, whilst recognising that any given organisation may have in mind something rather different, or sometimes no clear idea at all. Ask ten different organisations what Digital Transformation means to them, and you’re likely to get at least ten different answers.

Digital Transformation is the creation and implementation of new business models, new organisational models and new revenue streams made possible by the use of new digital technologies and channels.

Ironically it’s proving to NOT be about technology, but rather about company culture (this, in itself, being a product of the collective assumptions and beliefs of the organisation).

“A significant number of organisations are not getting [digital] transformation right because of a fundamental quandary over what digital transformation really is.”

~ Brian Solis, principal analyst and futurist at Altimeter

My Interest

So, why am I bothering to write this post? Aren’t there already reams of articles about every conceivable aspect of Digital Transformation?

Well, one aspect of Digital Transformation I see little covered is that relating to the development of “digital” products for the digitally-transformed company. And the implications this brings to the party.

Digital Transformation requires the development of new products and services to serve the new business models, new organisational models and new revenue streams. Digital products and digital services. In most cases, this means software development. And organisations, particularly untransformed organisations – which even now means most of them – are spectacularly inept at both software development and product development. Some refer to this as “a lack of digital literacy”.

Things have not changes much in this arena for the past fifty years and more. Failure rates resolutely hover around the 40% mark (and even higher for larger projects). And the much-vaunted (or is it much cargo-cullted?) Agile approach to development has hardly moved the needle at all.

For the past two decades I have been writing about the role of the collective psyche – and the impact on organisational effectiveness of the collectively-held assumptions and beliefs about how work should work. And make no mistake, effectiveness is a key issue in digital product development. Relatively ineffective organisations will fail to deliver new digital products and services at least as often as 40% of the time. Relatively effective organisations can achieve results at least an order of magnitude better than this.

The Marshall Model provides an answer to the question: what do we have to do to become more effective as an organisation? And it’s not a popular answer. By analogy, people looking to lose weight rarely like to hear they will have to eat less and exercise more. Organisations looking to become more effective rarely like to face up to the fact that they will have to completely rethink long-held and deeply-cherished beliefs about the way work should be organised, managed, directed and controlled. And remodel their organisations along entirely alien lines in order to see a successful Digital Transformation and compete effectively in the digital domain.

Successful Digital Transformations demand organisations not only come up with new business strategies, organisational models, revenue streams and digital products and services, but also that they shift their collective mindset to one which aligns with their ambitions. Personally, I see shifting the collective mindset as an essential precursor to the former. Most organisations approaching Digital Transformation fail to recognise this inevitability, this imperative. And so, most Digital Transformations are doomed to underachieve, or fail entirely.

“Ask yourself whether what you’re doing is disruptive to your business and to your industry. If you can say yes with a straight face, you may well be conducting a legitimate digital transformation.” And if you’re unable to say yes, then whatever you’re doing, it’s likely not a Digital Transformation.

If you’d like to explore this topic, understand more about the Marshall Model, its relevance and its predictive power, and save your organisation millions of Dollar/Pounds/Euros – not to mention much embarrassment and angst – I’d be delighted to chat things over with you and your executive team.

– Bob

Further Reading

Reinventing Organizations ~ Frederic Laloux

The Relevance of Giants – 2. O Sensei (Morihei Ueshiba)

On most every occasion when I’m speaking in public – at conferences, workshops, and the like – I tend to mention one or more of my “Giants” of Rightshifting. Men and women who, through their lives and work have contributed significantly to my understanding of work, and in particular to my understanding of effective collaborative knowledge work.

Many folks express interest in these Giants, but I do wonder if they appreciate the relevance of the ideas and experiences of these Giants to their own daily lives at work.

I mean, what relevance does, say, O Sensei have to developers, testers, operations staff and the like? Which aspects of any of these Giants’ work could be useful or helpful or simply comforting to these folks?

In this occasional series of posts I’ll be exploring some of the Giants’ relevance to folks other than theorists, managers, consultants and the like. I’ll be sharing some insights into their work, and specifically, the likely relevance.

With these posts I hope to pique your curiosity just a little. Let’s continue, with this second post in the series, with O Sensei.

O Sensei

Morihei Ueshiba

(December 14, 1883 – April 26, 1969)  (See also: Wikipedia entry)

I’m not going to dwell on his early life and experiences in the Japanese Army, his adventures in Mongolia, nor his experiences in Manchuria and Japan during the time of World War 2.

Aikido

I suggest the primary relevance of O Sensei to most folks working in the field of software development (and production operations) is Aikido – the martial art he developed. Excepting it’s less a martial art, and more a philosophy for life, and for harmonising with others.

Unlike many other martial arts, Aikido is focussed on caring for others, as emphasised by the translation of the three kanji: ai-ki-do as the Way of Unifying Spirit or the Way of Spiritual Harmony. O Sensei envisioned Aikido as an expression of his personal philosophy of universal peace and reconciliation. O Sensei’s goal was to create an art that practitioners could use to defend themselves while also protecting their attacker from injury.

Blending“, one of the core techniques of Aikido, invites us to look at conflicts from the perspectives of the other person – or people – involved. For me, this has a direct connection with empathy – as promoted by e.g. Marshall Rosenberg and others of the nonviolent community.

“Life is growth. If we stop growing, technically and spiritually, we are as good as dead.”

~ Morihei Ueshiba

Where’s the Relevance?

How do we make it more likely that we’re all spending our time on stuff that matters? How do we go about attending to folks’ real needs? I find blending a great asset in identifying with the needs of others. As I blend, I see their perspective, and their needs, more clearly. And in turn, they can feel more listened-to. And choose to reveal other things, crucial things, that means we get to understand more about what matters to us all. With this knowledge – and goodwill – we have a better chance of focusing on what matters, and of reducing the chance of wasting some or all of our time on the inconsequential, on detours, and on dead ends.

Practical Investigation

You might like to join an Aikido dojo, to practice the physical forms of the techniques. And to discuss the philosophy with like-minded people wha have already started the journey. Beware, though, of those dojos and sensei that emphasise the physical forms at the expense of Aikido philosophy.

– Bob

Further Reading

The Life We Are Given ~ Michael Murphy, George Leonard
The Way of Aikido ~ George Leonard
It’s A Lot Like Dancing ~ Terry Dobson

The Relevance of Giants – 1. Deming

On most every occasion when I’m speaking in public – at conferences, workshops, and the like – I tend to mention one or more of my “Giants” of Rightshifting. Men and women who, through their lives and work have contributed significantly to my understanding of work, and in particular to my understanding of effective collaborative knowledge work.

Many folks express interest in these Giants, but I do wonder if they appreciate the relevance of the ideas and experiences of these Giants to their own daily lives at work.

I mean, what relevance does, say, Bill Deming have to developers, testers, operations staff and the like? Which aspects of any of these Giants’ work could be useful or helpful or simply comforting to these folks?

In this occasional series of posts I’ll be exploring some of the Giants’ relevance to folks other than theorists, managers, consultants and the like. I’ll be sharing some insights into their work, and specifically, the likely relevance.

With these posts I hope to pique your curiosity just a little. Let’s start with Bill Deming.

W. Edwards Deming

Bill Deming

(October 14, 1900 – December 20, 1993)  (See also: Wikipedia entry)

I’m not going to dwell on his work in SPC (Statistical Process Control) or SQC (Statistical Quality Control), his pivotal role in the Japanese post-war economic miracle, his 14 Point system of thought he called the “System of Profound Knowledge”, nor his Plan-Do-Study-Act (PDSA) cycle (the latter being the basis for most Agile approaches, btw).

Deming’s 95/5

I suggest the primary relevance of Deming to most folks working in the field of software development (and production operations) is primarily the idea known as “Deming’s 95/5” (although this originated in a quote from Peter Scholtes).

“The fact is that the system that people work in and the interaction with people may account for 90 or 95 percent of performance.”

From my studies of Deming, and from applying his ideas in my practice, I have come to believe that it’s the interactions between people that account for the lions share of “productivity”, “performance” and “success” in collaborative knowledge work. And the “system” a.k.a. the way the works works has a major (hidden) influence on the quality of those relationships, as well as on the work (output, results) of the individual workers.

“Dr. Deming taught me that 95% of the performance of an organization is attributable to the system (processes, technology, work design, regulations, etc.) and [only] 5% is attributable to the individual.”

~ Tripp Babbitt

Where’s the Relevance?

If, like most people, you’re looking for a better quality of life at work, Deming points the way to us improving our relationships with our colleagues, peers and managers. Maybe this perspective is something to consider on those occasions when you’re less than happy in your work, when you’re checked-out, or disengaged, or frustrated.

And Deming’s attribution of 90-95% of your performance to the system within which you’re obliged to work throws a new light on many typical organisational practices such as history-led recruitment, performance appraisals and reviews, stack ranking, criticisms (and praise) for your efforts, etc.. Your results (and self-esteem) may be taking a hit from the effects and constraints inherent in that system, not from anything you’re doing (or not doing) yourself.

Practical Investigation

Deming designed the Red Bead Experiment to illustrate these very points, in a way that most people can directly relate to.

– Bob

Further Reading

Four Days with Dr Deming ~ Latzko and Saunders
95% of performance is governed by the system ~ Vanguard web page

Cognitive Function

How often do you get pissed off by interruptions and distractions? You know, when you’re zoned in on something, in a state of flow, and something happens to break the flow? Personally, when I’m writing code, I have to be in a quiet place, by myself or with my pair or mob, else I can’t get anything done for the continual distractions.

This is but one example of how easily cognitive function can be impaired.

Common sources of cognitive impairment:

  • Distractions and interruptions
  • Stress (specifically, negative stress a.k.a. distress) Cf Amygdala Hijack
  • Tiredness, fatigue, lack of sleep.
  • Multitasking
  • Poverty
  • Diet
  • Shift patterns
  • Noise and other forms of environmental stressors (lighting, odours, vibrations, exposure to particulates, elevated carbon dioxide, etc.)
  • Physiological issues (such as colds and flu, hypoglycemia, aphasia, depression, dehydration, hypertension, obesity, trauma, diabetes, Parkinson’s, POTS, dementia, hypoxia, atrial fibrillation)
  • Substance abuse (drink, drugs, etc. – short and long term effects, chronic and acute)

Wow. That’s quite a list. Seems like almost anything can impair cognitive function.

Why Does this Matter?

So why does cognitive function matter. What’s the connection with knowledge work? I’ll spell it out in case it’s not clear:

Knowledge work – such as software development – by definition involves working with our brains. If our brains are performing well (i.e. effective or relatively high cognitive functioning) then we can expect our work to go well, things to get done quicker, with fewer errors, and so on.

Conversely, when our cognitive function is impaired, our brains will take longer to accomplish tasks, come up with less effective solutions, commit more errors, and generally perform more ineffectively.

It’s also likely that with impaired cognitive function we’ll be less reflective, with less energy or capacity to spend on thinking about our work, our relationships, our behaviours, our practices, our customers, possible innovations, our needs and the needs of others, etc..

Does it sound to you like non-impaired cognitive function is something worth having? Something worth paying attention to?

Paying Attention?

So how many folks – managers, workers, organisations – pay any attention AT ALL to folks’ cognitive functioning in the workplace or whilst working? I’d suggest the answer is none, or as near none as makes no difference.

Which seems strange to me, if we truly seek our collaborative knowledge work (and workers) to be as effective as possible. Of course, that objective may be a false assumption. Maybe blissful ignorance and indifference is preferable to paying attention and taking action? Given the reluctance I’ve encountered when broaching this subject, I suspect blissful ignorance and/or indifference holds sway.

How does it go in your organisation?

– Bob

Solutions Demand Problems

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

BenSImoTweets

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 Psychotherapy provides guidance and support to organisations in all stages of this journey.

Emotioneering

Problem

Research 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. 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 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.

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 consistent through the roof? Where joy, passion and discretionary effort are palpable, ever-present and to-the-max?

Solution (in a Nutshell)

The Antimatter Principleproposes that putting the principle of “attending to folks’ needs” at front and centre of allof the organisations 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 engineeringdisciplines 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

%d bloggers like this: