Your REAL Job

Students of Ackoff and Deming will be aware of Deming’s First Theorem:

“Nobody gives a hoot about profit.”

W. E. Deming

This reminds us that senior executives are demonstrably less interested in the welfare of the organisations they serve than in their own well being.

“Executives’ actions make sense [only] if you look at them as taken in order to maximise the executive’s well being.”

~ Russell L. Ackoff

Of course, it can be career-limiting to bring this issue to general attention. As the well-known psychiatrist R D Laing said:

“They are playing a game. They are playing at not playing a game. If I show them I see they are, I shall break the rules and they will punish me. I must play their game, of not seeing I see the game.”

~ R. D. Laing

And yet, if we look at the implications for “doing a good job” – a preoccupation of many in employment, we can draw the following conclusion:

We’re doing a good job when we’re maximising our executives’ (our bosses’) well being. We’re not doing a good job when we ignore that in favour of focussing on e.g. making the company successful or profitable. This probably rings true with you if you but think about it, in your own context, for a few moments.

This underscores a hidden reality for many: our declared job is a FAUX job. Our REAL job is undeclared, unexamined, unspecified – and being good at THAT is therefore a matter of pure dumb luck and random chance. How often do you have a conversation with your senior executives about how you might contribute to maximising their well being? How can we attend to their needs – as folks that matter – without such a dialogue?

– Bob

Further Reading

Nobody Gives a Hoot About Profit ~ The W. Edwards Deming Institute Blog post

Getting Started as an Organisational Psychotherapist

A number of folks have asked me recently about my suggestions for getting started in Organisational Psychotherapy, i.e. as a practitioner (a.k.a. therapist).

This post sets down a few pointers in that direction.

Blog Posts and Books

I’ve written many posts over the past five years and more exploring the subject of Organisational Psychotherapy from various viewpoints. More recently, I published a book on the subject, which I regard as foundational in the field of Organisational Psychotherapy. The book is titled “Hearts over Diamonds” and you can find it on LeanPub (ebook version), the Apple book store (also an ebook), and in print form at Lulu.com.

To find all the Organisational Psychotherapy posts on my blog, you can use the Organisational Therapy category link, or search for e.g. “Organisational Psychotherapy“ using the WordPress search feature.

Other Entry Points

To reduce the likelihood of anchoring your own practice to my personal perspective, you might like to first enter the field via routes other than my blog posts and books. When I started, I hadn’t written anything on the topic (obviously), so I myself started with:

  • Reflections on the core purpose of what I I only later came to call Organisational Psychotherapy (particular the foundational question, see “Foundations”, below)
  • Research into some of the many schools of individual therapy (for example, the work of Carl Rogers, Marshall Rosenberg, Virginia Satir, etc.), and the nature of therapy in general
  • Reflections on my own experiences of being “in therapy”
  • Selection of a few key schools of therapy, schools which particularly resonate with you
  • Reflections on repurposing individual therapies to the field of Organisational Psychotherapy
  • Practical application in client engagements (these were, for me, mainly coaching-type engagements, at the outset)

A Game Plan

I’m pretty sure you’ll want to formulate your own “game plan” for acquiring skill, experience, and capabilities in the field of Organisational Psychotherapy. For myself, my game plan has consisted of a repeating alternation between reflection and practise, reflection and practise.

Foundations

How have I arrived at my relationship with Organisational Psychotherapy today? Having been in the world of software development, and the business of software development, for more than forty years, I’ve come to see that any significant progress towards increased effectiveness depends on organisations fundamentally shifting their collective assumptions and beliefs. You can read about this via Rightshifting, and the Marshall Model.

Given this, the question becomes:

“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?”

My own personal answer to this question is, nowadays, Organisational Psychotherapy. In the context of getting started, I invite you to find your own question (or feel free to adopt mine), and then search for your own answer.

– Bob

What Is A Customer?

In the world of Agile, and the world of business too, we hear a lot about “customer value”. Folks seem to have some kind of handle on “value” (although not everyone can agree on that one – see my post “What Is Value” for my take, based on Goldratt and his Theory of Constraints).

And for the record, we might also choose to frame the question of value within the Antimatter Principle frame, and vocabulary:

Value: The degree to which folks’ needs, in aggregate, are being (or have been) met.

But what about “customer”? So simple and straightforward. Do we even need to define it? I thought not, until a recent conversation on Twitter gave me pause for reconsidering. Specifically, the idea that maybe folks are talking at major cross-purposes, with significantly differing assumptions and definitions for the term. If we can’t agree on a basic term like “customer”, what chance alignment of a whole host of fundamental questions about software, products and business generally?

Here’s my definition, again using the Antimatter Principle as a frame:

Customer: Someone (could be either a person, or a collection of people) whose needs we’re attending to.

I’m pretty sure you’ll have a different definition of customer. I’d love to hear your take.

Before I close this post, here’s a different definition, informed by Crosby and his Zero-Defects (ZeeDee) approach to quality:

Customer: Anyone who receives or anticipates receiving something (e.g. a good or a service) from someone else.

This definition canonises Crosby’s idea that we’re all customers. And we’re all suppliers, too. And as suppliers, it falls to us to ensure that what we’re supplying is what our immediate customer needs to supply their customer(s).

– Bob

OP 101

I note I have a tendency to explain things in detail or at length without necessarily setting down the fundamentals of an idea. This post attempts to set down the fundamental of OP – Organisational Psychotherapy. (For the details, or a lengthy tour through the subject, there’s a whole passel of other posts on this blog, plus my recent book “Hearts over Diamonds”).

Tl;Dr

The performance of any knowledge work organisation is a function of its collective assumptions and beliefs about work. Significant improvements to organisational performance requires a fundamental shift in these assumptions and beliefs. Organisational Psychotherapy makes this shift both feasible and economic.

The Basic Premise

The basic premise of Organisational Psychotherapy is that the performance of any and all knowledge work organisations is a function of the collective mindset of the organisation. For significant improvements in the performance of the organisation, the collective mindset has to undergo a step-change.

P = ƒ(Collective mindset)

Collective Mindset

In Organisational Psychotherapy, “collective mindset” (a.k.a. collective or shared memeplex) we mean “the set of assumptions and beliefs held in common by more-or-less everyone in the organisation”. Assumptions and beliefs concerning work, and how work should work (i.e. how work should be organised, directed and managed).

This set of assumptions and beliefs held in common are rarely held consciously, more often existing below the level of consciousness of the organisation and its individuals, both.

Culture

We often call the manifestation of the collective mindset the “culture” of the organisation – the typical behaviours and actions of individuals and groups driven, subconsciously, by their underlying, commonly-held, assumptions and beliefs.

The Performance Challenge

Many organisation may be happy with – or at least resigned to – their status quo. These organisations do not seek to understand the roots of organisational performance. For the fewer number of organisations that do seek to improve their performance, questions such as “what makes for better performance” and “what could we do to improve performance” begin to surface.

The challenge, then, for this latter group of organisations, is to find some levers to pull, levers by which to affect the organisation’s performance in the desired direction(s).

Some yet fewer number of organisations may come to understand the connection between their collective mindset and their performance – current and aspirational. For these organisations, the challenge becomes:

“How can we shift our collective assumptions and beliefs in a direction – or directions – that support our aspirations for e.g. improved performance?”

Organisational Psychotherapy

So to the main focus of this 101 unit:

How might those organisations that see the connection between their collective assumptions and beliefs, and their performance, go about shifting those assumption and beliefs?

For individuals faces with this challenge in their daily lives (“How might I as a person go about having a happier or more productive life? How might I shift my assumptions about relationships, people, myself, etc. to see that come about?”), psychotherapy is one option they may consider, and thence embark upon.

So it is with organisations. Asking themselves the question:

“How might I as an organisation go about having a happier or more productive life, see improved performance, greater success?”

leads to the challenging question:

“How might I/we shift my/our collective assumptions and beliefs about relationships, people, myself/ourself, etc. to see that come about?”

At this point, Organisational Psychotherapy is one option the organisation may consider, and embark upon.

The Bottom Line

Until recently, organisations have not had the option of Organisational Psychotherapy. Even now it’s an option little known and still in its infancy. So organisations have been constrained to other options, such as tackling the above question “How might I/we shift my/our collective assumptions and beliefs about relationships, people, myself, etc.” from within their own resources, or with the aid of e.g. external consultants. Not being well-versed in the fields of Organisational Psychotherapy, psychology, sociology, group dynamics, etc., this path can consume much time and attention, many resources, inflate business and reputational risks, and generate high levels of waste and stress. Witness: the huge number of business books on organisational change, Digital Transformation, and so on.

Organisational Psychotherapists offers a degree of competency in these fields (psychology, sociology, group dynamics, etc.) not natively present in most organisations. This competency eases the path to the kind of change (or shift) they seek, saving time (time is money), missteps, reducing the risks, and lowering stress levels for all involved.

A Request

Whether you have found this explanation of the fundamentals of Organisational Psychotherapy useful or useless, I would be delighted and thankful to hear your comments and questions.

Beyond Command and Control – A Book Review

John Seddon of Vanguard Consulting Ltd. kindly shared an advance copy of his upcoming new book “Beyond Command and Control” with me recently. I am delighted to be able to share my impressions of the book with you, by way of this review.

I’ve known John and his work with e.g. the Vanguard Method for many years. The results his approach delivers are well known and widely lauded. But not widely taken up. I doubt whether this new book will move the needle much on that, but that’s not really the point. As he himself writes “change is a normative process”. That’s to say, folks have to go see for themselves how things really are, and experience the dysfunctions of the status quo for themselves, before becoming open to the possibilities of pursuing new ways of doing things.

Significant Improvement Demands a Shift in Thinking

The book starts out by explaining how significant improvement in services necessitates a fundamental shift in leaders’ thinking about the management of service operations. Having describe basic concepts such as command and control, and people-centred services, the book then moves on to explore the concept of the “management factory”. Here’s a flavour:

“In the management factory, initiatives are usually evaluated for being on-plan rather than actually working.”

(Where we might define “working” as “actually meeting the needs of the Folks that Matter”.)

Bottom line: the management factory is inextricable bound up with the philosophy of command and control – and it’s a primary cause of the many dysfunctions described throughout the book.

Putting Software and IT Last

One stand-out section of the book is the several chapters explaining the role of software and IT systems in the transformed service, or organisation. These chapters excoriate the software and IT industry, and in particular Agile methods, and caution against spending time and money on building or buying software and IT “solutions” before customer needs are fully understood.

“Start without IT. The first design has to be manual. Simple physical means, like pin-boards, T-cards and spreadsheet.”

If there is an existing IT system, treat it as a constraint, or turn it off. Only build or buy IT once the new service design is up and running and stable. Aside: This reflects my position on #NoSoftware.

John echoes a now-common view in the software community regarding Agile software development and the wider application of Agile principles:

“We soon came to regard this phenomenon [Agile] as possibly the most dysfunctional management fad we have ever come cross.”

I invite you to read this section for an insight into the progressive business perspective on the use of software and IT in business, and the track record of Agile in the field. You may take some issue with the description of Agile development methods as described here – as did I – but the minor discrepancies and pejorative tone pale into insignificance compared to the broader point: there’s no point automating the wrong service design, or investing in software or IT not grounded in meeting folks’ real needs.

Summary

I found Beyond Command and Control uplifting and depressing in equal measure.

Uplifting because it describes real-world experiences of the benefits of fundamentally shifting thinking from command and control to e.g. systems thinking (a.k.a. “Synergistic thinking” Cf. the Marshall Model).

And depressing because it illustrates how rare and difficult is this shift, and how far our organisations have yet to travel to become places which deliver us the joy in work that Bill Deming says we’re entitled to. Not to mention the services that we as customers desperately need but do not receive. It resonates with my work in the Marshall Model, with command-and-control being a universal characteristic of Analytic-minded organisations, and systems thinking being reserved to the Synergistic– and Chaordic-minded.

– Bob

Further Reading

I Want You To Cheat! ~ John Seddon
Freedom From Command and Control ~ John Seddon
The Whitehall Effect ~ John Seddon
Systems Thinking in the Public Sector ~ John Seddon

#NoSoftware

I wrote a post some time ago about No Hashtags (hashtags on e.g. Twitter which use the #No… prefix). My tweets occasionally mention various #No… hashtags, including #NoEstimates, #NoTesting and #NoSoftware.

I’m thinking it’s about time I delved just a little into the #NoSoftware hashtag. Like most of my posts on Think Different, this one will be brief. #NoSoftware is a deep subject, upon which I could write a whole book, had I but the inclination (or demand).

To whet your appetite, and illustrate the possibilities of #NoSoftware, we need look no further than the story of Portsmouth City Council housing repairs, where an existing, expensive and inflexible IT system was switched off, replaced with manual controls, and only later some limited software support reintroduced, once the needs of all the Folks That Mattered had been fully understood and catered to.

Payback

Let’s start with the payback of #NoSoftware.

As Steve Jobs wrote:

“The way you get programmer productivity is not by increasing the lines of code per programmer per day. That doesn’t work. The way you get programmer productivity is by eliminating lines of code you have to write. The line of code that’s the fastest to write, that never breaks, that doesn’t need maintenance, is the line you never had to write.”

~ Steve Jobs

A pretty clear alignment with #NoSoftware (yes, I’m coming to that presently) wouldn’t you say?

Let’s just dissect that statement:

Eliminating lines of code we have to write

We’re not talking about writing denser code – cramming more functionality into fewer lines. Fewer lines of code means we’re done quicker, having spent less time, effort and money on the writing of code. That’s a saving in and of itself.

Never breaks

So the lines of code we don’t write means we don’t have to worry about their quality (no matter whether you use defect prevention or testing as your go-to strategy in that arena). More time, effort and money saved.

Doesn’t need maintenance

By maintenance here, I’m thinking about changes to the code occasioned by the changing needs over time of the Folks That Matter, or changes necessitated by changing technical environments. I’m not dwelling on remediation efforts (bug fixes to production code).

More Payback

But the payback of #NoSoftware doesn’t stop with the above aspects. In the bigger picture, it’s not just about writing fewer lines of code. It’s about eschewing software-based solutions more or less entirely in favour of considering the alternatives. More payback includes:

Happier customers

It’s an old saw that “folks don’t want an 8mm drill, they want an 8mm hole”. Similarly, folks almost universally don’t want software, they’re looks to have their needs met. And software for many of these folks has too many negative impacts to be their preferred option. Software is generally written to save (suppliers) costs, not to improve customers’ satisfaction. Most people hugely prefer to interact with other human beings, rather than a computer controlled by – generally lame and inflexible – software.

Opening the Door to Changing Thinking

Software systems as generally conceived, ordered and delivered institutionalise – or “lock-in” – the existing collective mindset. Once installed and paid for, the “sunk cost” fallacy undermines any possibility of changing the existing set of assumptions and beliefs about how the works works. In the vast majority of cases the software system locks the organisation even more tightly into its existing Command & Control (a.k.a. Analytic Mindset) ways of working.

#NoSoftware – Definition

When I use the #NoSoftware hashtag, I’m inviting folks to think again about what, often, are near-autonomic responses. In this case, the System One (cf Kahneman) response – “fast, instinctive, emotional, stereotypical, unconscious and automatic” – when faced with some needs of some Folks that Matter, to satisfy those needs with a software-based solution.

I guess some folks assume that I’m advocating zero software. A kind of Luddites’ heaven. This is not my position. In using the #NoSoftware hashtag, I’m basically saying

“Under some circumstances, maybe there are other, more effective means to meet folks’ needs than the default assumption/strategy that we have to do so via software”.

“How about we think about, talk about, and consider those various circumstances, and means?”

In this way, the #NoSoftware hashtag is a metaphor for

“Would you be willing to think again, and maybe join the search for more effective, relevant or alternative means of meeting the needs in question?”

Example

Some years past, I was working with a company that offered a software product to the corporate market. The product had been in the market for some years, and it was clear that one of the blockers to market penetration was the complexity of the problem and the challenges corporate customers faced in dealing with that complexity. The company chose to build more and more software into their product to help their customers handle the complexity. No one ever discussed the options of offering a consulting service and/or a managed service, using human expertise, to replace or augment their software product. Consequences were, customers remained challenged, and the company’s revenues suffered.

Blockers

As Upton Sinclair’s Dictum tells us:

“It is difficult to get a man to understand something when his salary depends on his not understanding it.”

~ Upton Sinclair

How much more difficult, then, when it’s the revenues of a whole industry we’re calling into question. If the software industry changed tack and stopped writing software, what then? Financial ruin? World collapse?

There’s a multitude of smart people who currently waste much of their time – and lives – writing and delivering solutions to folks’ needs in the form of software. I suggest that to have this multitude refocus and retrain themselves to consider, and deliver, other forms of solution – solutions with less or no software – would make the world a better place for all the Folks that Matter. And “better”, as far as customers are concerned, would mean increased demand and more revenues for savvy suppliers.

Uptake

Like many of my invitations, I find #NoSoftware has few people willing to consider it as an alternative strategy to the status quo of just getting on with writing (more and more) software. I guess this signifies the general learned helplessness, and lack of engagement, autonomy and mastery, we find in most workplaces and employees today. So be it.

– Bob

Further Reading

Why Doctors Hate Their Computers – Atul Gawande
Forget your people – real leaders act on the system ~ John Seddon
Dangerous Enthusiasms: E-government, Computer Failure and Information Systems Development ~ Robin Gauld, Shaun Goldfinch

Why Reason When Faith is So Much More Comfortable?

I’ve become very bored trying to explain why Agile – even when practised as the Snowbird Gods intended – is a dead-end and why we might choose to bark up a different tree for progress in improving the effectiveness of software development organisations.

Firstly. No one seems at all interested in “improving the effectiveness of software development organisations”. Yes, there does seem to be some interest in being seen to be doing something about improving the effectiveness of software development organisations. Hence SAFe, DAD, LeSS – and Agile itself. None of these approaches do anything about actually improving the effectiveness of software development organisations, of course. But that’s not the point. Improvement *theatre* wins the day in just about every case. Irrespective of practices done “right”, or more often, done “in name only” (Cf AINO).

To actually do anything about improving the effectiveness of software development organisations requires we remove some fundamental system constraints, including:

  • Optimising parts of the organisation in isolation
  • Pursuit of specialism (vs generalists)
  • Control (as in Command & Control)
  • Annual budgeting
  • Extrinsic motivation
  • Ignorance of the special needs/realities of collaborative knowledge work
  • Separation of decision-making from the work
  • Decision-makers’ ignorance of and indifference to customers’ needs
  • Seeing performance as consequent on the efforts of individuals and “talent”
  • Discounting the paramountcy of social interactions and inter-personal relationships

And that ain’t gonna happen.

Second, improving the effectiveness of software development organisations kinda misses the point. In that software development is part of the problem. Making it more effective is just – as Ackoff would say – doing more wrong things righter.

Instead, a focus on meeting folks’ needs, or at least, as a minimum, attending to their needs, would serve our search for effectives rather better. And that generally requires less software, and placing software development last in terms of priority, way before understanding customers’ needs ( (and more generally the needs of the Folks’ That Matter).

Given that the software industry’s revenues are contingent on producing software (see: Upton Sinclair’s Dictum) that ain’t gonna happen, either.

Third, if we regard improving the effectiveness of software development organisations as our aim, and limit our ambitions to that part of the organisation concerned directly with software development (i.e. the IT department or the Product Development department) then, at best, we’ll only ever see a local optimisation. Which as Ackoff tells us, only makes matters (i.e. the effectiveness of the whole organisation) *worse*. To improve organisational effectiveness (not to mention supply chain effectiveness, customers’ effectiveness) requires us to consider the organisation as a system, and focus on the systemic relationships between the parts, rather than on the parts taken separately. And given that systems thinking has failed to gain much traction in over fifty years of trying, THAT ain’t gonna happen either.

I’ll just leave this here:

“If you could reason with Agile people, there would be no Agile people.”

It all looks a bit bleak, doesn’t it? Another method isn’t going to help much, either. Unless it addresses the three points outline above. As a minimum.

That’s why I have been for some years inviting folks to consider Organisational Psychotherapy as a way forward.

But reason, rationality, and a cold hard look at reality and the shortcoming of the status quo ain’t gonna happen. Until organisations see a need for that to happen.

– Bob

%d bloggers like this: