Antimatter Principle Elaborated

Around a year ago I wrote a post with the title “Antimatter Evo“. For those who may have found it a little over-long, and for those who prefer lists, I’ve extracted the core Antimatter Principle elements into this briefer post. And I’ve also added a list of related Think Different posts under “Further Reading”.

Twelve Principles for Software Development

The Twelve Principles of Agile Development as seen through the Antimatter Principle lens, and its vocabulary:

1. Our highest priority is to continually attend to the needs of everyone that matters.

2. Handle changing needs, and changing membership of the “everyone that matters” community, in ways that meet the needs of the folks that matter.

3. Deliver stuff as often as, and by means that, meets the needs of everyone that matters.

4. Share needs and solutions as often as, and by means that, meets the needs of everyone that matters.

5. Motivate people to the degree that, and by means that, meets the needs of everyone that matters.

6. Facilitate sharing of information, feelings, needs, etc. to the degree that, and by means that, meets the needs of everyone that matters.

7. Choose a primary measure of progress that meets the needs of everyone that matters.

8. Choose a pace that meets the needs of everyone that matters.

9. Agree on attributes of quality, and levels of quality, with respect to the means of the endeavour, that meets the needs of everyone that matters.

10. Spend effort only where it directly attends to some need of someone that matters.

11. Agree on attributes of quality, and levels of quality, with respect to the organisation of the endeavour, that meets the needs of everyone that matters.

12. Pursue improvement, with respect to the means and organisation of the endeavour, that meets the needs of everyone that matters.

Summary

The Antimatter Principle is simplicity itself (just four words) – “Attend to folks’ needs”.

The above list illustrates how the Twelve Principles can be subsumed by just the one.

– Bob

Further Reading

The Antimatter Principle ~ Think Different blog post
A Vocabulary for the Antimatter Principle ~ Think Different blog post
The Folks That Matter™ ~ Think Different blog post
The Needsscape ~ Think Different blog post
Wants, Needs ~ Think Different blog post
How To Connect With Folks’ Needs ~ Think Different blog post
NeedsFlow ~ Think Different blog post
The Agile Path to Quality ~ Think Different blog post

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? Where are the Red Lines?”

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

%d bloggers like this: