Archive

Culture change

The Edge of Intolerable

In your workplace…

How tolerable is it to trust developers (and others) to manage their own time?

How tolerable is it to trust developers to talk with customers?

How tolerable is it for people to simply “play”?

How tolerable is it to trust people to do what they believe is best for the company and its present, and future?

How tolerable is it to have people set their own salaries, hours, locations, and tools?

How tolerable is it for people to choose who they’ll team with?

How tolerable is it for teams to choose where to focus their efforts?

How tolerable is it to spend time on improving the way the work works, on improving quality, on not shipping a product or feature right now?

How tolerable is it to use logic and data to direct efforts rather than rely on the opinions of the highest paid people?

How tolerable is it to ask these kinds of questions?

The Tolerability Envelope

If you’re looking to make a difference, ask not “What is the best we can do?” but rather “What is the best we can do that will be tolerated here?”

And to make a major difference, would you be willing to start a movement towards making more things more tolerable?

– Bob

Congruence

What if the last twenty years has been another classic example of software developers solving the wrong problem?♥

What if “agility” was never the issue as far as business was and is concerned? What if business agility is NOT the most useful response to, or strategy for, life in a VUCA world?

We hear so much about the need for agility. It’s now a given, an unchallenged assumption. Maybe even an undiscussable assumption? Well, I’m challenging it. And in the spirit of this blog – always having an alternative to offer – I propose congruence as a more useful response to the challenges of a VUCA business environment.

Agility: the power of moving quickly and easily; nimbleness.

Congruence: Similarity between self-image and actual experience.

Carl Rogers stated that the personality is like a triangle made up of the real [or actual] self, the perceived self, and ideal self. According to Rogers, when there is a good fit between all three components, the person has congruence. This is a healthy state of being and helps people continue to progress toward self-actualisation.

Applied to organisations, we can say that an organisation is made up of the real [or actual] organisation, the organisation as it perceives itself, and its ideal self. When there is a good fit between all three components, the organisation has congruence. This is a healthy state of being and helps the organisation progress toward being all it can be.

Without congruence, organisations won’t know what to do with agility, or how to get it. Without congruence, a VUCA environment presents challenges which incongruent organisations are poorly equipped to meet.

So, forget the past twenty years and the search for agility. Congruence is the thing.

– Bob

Footnote

♥ It was a bunch of software developers that invented and promoted the idea of agility (for software development) some twenty years ago now. Businesses everywhere have seized on this prior art in their attempts to cope with the upswing in perceived volatility, uncertainty, complexity and ambiguity in the business environment.

PS

The same argument also applies to the birthplace of the agility meme: the software development silo. Forget the past twenty years and the search for development agility. Congruence is the thing.

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

%d bloggers like this: