Little Islands

Trawling the seas of knowledge

Note: This is one of those rare posts )for me) where I have few to no suggestions as to how to proceed.

Islands of Ignorance

In my travels, I have seen many organisations from the inside, and many more from the outside. 

In almost all cases, these organisations strike me as like little islands of ignorance in a huge sea of knowledge. As a mariner myself, I’m well aware of the bounty of these seas. So, maybe better placed than most to see the shortfalls in our organisations’ uptake of this bounty.

Seas of Knowledge

It’s never been easier to keep up with developments (sic) in praxis – in whatever fields of human endeavour interest us. And that’s probably even more true for the fields of collaborative knowledge work, software development and product development than for any other.

And yet, almost every organisation I see operates on principles – from the executive management suite to the workers at the coal face – utterly disconnected from the seas of knowledge surrounding them. Principles grown stale and musty with the dust of ages past.

Some organisations, having an inkling of their disconnection, make token efforts to bring outside knowledge in – with brown bag sessions, encouraging folks to attend meet-ups and conferences, hiring consultants from time to time, and so on. But like fishermen on the shore with fishing poles and spears hooking the occasional fish, this ain’t so effective. Few indeed are the organisations that build trawlers and send them out with nets, sonar, radar and the like to harvest the plenty of the seas.

Why is This?

What makes organisations so inept at finding and using the huge repositories of knowledge out there – in books, on the internet, in people’s heads, and so on?

Beats me. 

I have some suspicions that the education system is partly to blame. I’ve seen many graduates who, upon doing the workforce, act as if their learning days are behind them. 

And short-termism, the bane of UK industry in particular, contributes. With the implicit idea that learning, being more valuable in the longer term, has little or no value in meeting next week’s delivery schedules, or this month’s financial targets.

I guess, too, that like navigating our planet’s vast oceans, the seas of knowledge are so vast now that special navigation equipment is necessary to tackle the challenge. And whilst a fish is a fish, a idea or item of know-how is a much more slippery thing. How to sort the wheat from the chaff? Maybe systematic experimentation can help (see e.g. Toyota Kata, or Popcorn Flow from Claudio Perrone)

Appeal

So. There you have it. No elegant ideas for addressing the situation. Just an appeal to you, dear readers, to share your experiences, perspectives, and maybe a hint or tip or two for the rest of us.

– Bob

Further Reading

The Fifth Discipline ~ Peter M. Senge
Peter Senge and the Learning Organization ~ Infed article
On Dialogue ~ David Bohm

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.

The Design Principles of Organisational Psychotherapy

Some ten years ago now, I began to design an alternative approach to helping collaborative knowledge work organisations become more effective. Typical approaches then in use included:

  • Consultancy
  • Improvement and/or change projects (most often, focussed on one or other part of an organisation, such as sales, manufacturing or product development)
  • Coaching (of individuals or teams)

I had much experience of being involved in supplying each of these different styles of intervention, and had found all of them wanting. And in finding them wanting, I decided to design a style of intervention which reduced or eliminated their shortcomings. Thus evolved the design principles underpinning my alternative approach, which I eventually came to call ”Organisational Psychotherapy”.

By popular demand I briefly describe each of these principles in this post.

Principles

Systemic

As Ackoff, Goldratt and Deming all tell us, attempting to improve any one part of an organisation (unless it’s the constraint) makes the overall performance of the organisation worse. So, Organisational Psychotherapy intervenes at the level of the whole organisation, via the collective mindset or psyche of the whole organisation.

Non-prescriptive

When dealing with people, both psychology and neuroscience illuminate the folly of attempting to coerce, oblige or otherwise cajole people into doing what we want. Organisational Psychotherapy, borrowing a principle from individual psychotherapy, provides for an style of intervention where the organisation has no pre-written manual or handbook, no methods or methodologies its people must follow, and no imposed policies, rules, procedures or ways of working. It’s up to the people involved – initially through their existing organisation structures – to decide what’s optional, what’s mandatory, and who calls the shots.

Freedom to participate (or not)

Another aspect of coercion typical of existing intervention approaches is mandating folks’ participation in the project or programme. Organisational Psychotherapy offers support for voluntary participation.

Context aware

Typical approaches come replete with a one-size-fits-all guide, handbook or set of customary practices. And these practices are generally applied with little or no consideration for the specific context of each intervention. In Organisational Psychotherapy, the client knows their own context, and as with e.g. Clean Language, the therapist is at pains to avoid introducing anything from their own context (previous domain knowledge, experience, etc.)

Normative

Some forms of intervention include elements of training, be that in the classroom or via online tools. As John Seddon eloquently puts it “ Change in a normative experience”. Which is to say, that effective change (of attitudes, assumptions and beliefs) relies on people experiencing things for themselves, and learning from those experiences about which of their assumption are falsey or inappropriate. Such learnings lead to the sought-after changes in behaviours. As the whole organisation experiences things, and learns, during its BAU (Business As Usual), collective assumptions and behaviours change.

ROI

All intervention styles promise a positive return on the necessary investment. Organisational Psychotherapy is no different – let’s not lose sight of the fact that our clients will be looking to see a return on the investment they make. I argue that the return from investing in Organisational Psychotherapy significantly exceeds the return on investment of other, more traditional, and less effective approaches.

Taking Ownership Challenges and Illuminates

Handing over responsibilities to a third party (whether that means consultants, coaches or an internal project team) undermines the ownership of the issues facing the organisation, and absolves e.g. senior management from participating directly in the change efforts. It also provides a cosy distance which generally shields senior management from the disturbing notion of having to change themselves and their own (flawed, outdated) assumptions and beliefs. Organisational Psychotherapy preserves the organisation’s collective ownership of the organisation’s issues.

Self-sustaining

Many intervention styles provide a quick fix (note allusions to narcotics here) which leave the organisation no better able to deal with its issues from its own resources than before the intervention. Another fix requires another injection of outside agency. And another. Ad infinitum. Organisational Psychotherapy seeks to enable the client to become capable in dealing with its own issues.

– Bob

Further Reading

Stances Spectrum ~ Chart comparing different Intervention “stances”
Just One Fix ~ Think Different blog post

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

Random Walks

How well does the almost universal Agile practice of “built and see if they come” serve us (as developers, as customers)?

I suggest it’s time to rethink our belief that customers (and developers, for the most part) “don’t know what they want until they see it”.

My late, great colleague and friend Grant Rule used to refer to the practice, common in the Agile domain, of building something to see if the customer likes it as “random walks through the problems-solution space”.

Quality Demands Requirements

Philip Crosby, a widely acclaimed “guru” of Quality Management, defined quality as “conformance to requirements”. As simple and blunt as that.

Recently, I’ve been reflecting on my experiences with software product development, especially the development of “quality” products that customers love. In Javelin, we place special emphasis on de-risking delivery through explicitly defining the customers and their respective requirements. Not big-bang, up-front stylee, but incrementally, just enough each couple of days to build a little more of the product and deliver it to the customer(s) for their delight, confidence, and feedback.

But in our approach, requirements (in the frame of the Antimatter Principle we call these needs) precedes building anything. Agile shops these days seems to major in building something before discussing requirements (if they ever get discussed at all). BDD offers an exception, but how many shops do BDD?

Aside: In Javelin, we identify all stakeholders (all the Folks That Matter), discuss their needs (“Stakeholders’ Needs”) and quantify them (a la Gilb – see: Competitive Engineering) in the form of Quantified Quality Objectives. Although this all generally proceeds incrementally, rather than in a big batch up front, the information is always to hand by the time someone gets around to building the relevant part of the thing in question. People work from the requirements. Always.

Random Walks are not Our Bag

Random walks are not our bag.

By cleaving to the belief that customers “don’t know what they want until they see it”, and structuring the whole approach to development around this belief, Agile shops have no incentive to improve the way they work with customers to understand their needs. No incentive to improve requirements elicitation and capture. No incentive – or means – to prevent defects and deliver zero-defects quality. Indeed, this belief and its associated practices blocks us from working to continually find better ways to create useful requirements (formal statements of folks’ needs) from which to drive quality (cf Crosby) and the improving of relationships with each other (developers, ops) and with customers.

Is this emphasis on working-from-clearly-stated-and-agreed-requirements better? Well, in my experience it makes for happier customers, happier developers, and more successful products. I’ll leave it to you to decide whether and how that’s “better”.

– Bob

%d bloggers like this: