Organisational effectiveness

Amongst many gems, my new “real page-turner” of a book, “Memeology”, defines an approach to measuring the progress of your organisation at culture change (page 44 in the current print/pdf version – or search for “sparklines”).

Are you interested in tracking your efforts at changing the culture of your organisation – and hence its effectiveness?

P.S. I’m available to help you implement this scheme.

No, you can’t buy in to Agile without changing your thinking. Your OWN thinking. Can you buy that in?

Absent such change, any imagined or sought benefits must inevitably be foregone.

Apart from the benefits of theatre, that is.

(See other posts here for why the real benefits of buying in to Agile are not worth the candle, anyways).


I propose its the theatrical benefits which are the only benefits of interest, nowadays.

We’re Still Working in the Dark Ages


Medievalism is a system of beliefs and practices inspired by the Middle Ages of Europe, or by devotion to elements of that period. Closely related to and encompassing Feudalism, and the Manorial system.


Medievalism’s foundations include Faith, Seigneuriage, and land lordship.


Despite many legal and social changes since the Middle Ages, from the perspective of folks working in organisations there’s not much difference between serfdom then and employment today. Employees are hired and remain employed at the whim of the Lords of the organisation, and dismissed with as little thought – or maybe even less thought – than serfs.

The relationship between employer and employees remains predominantly one of power-over. And although a relationship, it’s hardly ever a humane relationship. And thus hardly ever a positive contributor to organisational effectiveness.


Whilst any kind of universal solution remains a long way off, and dependent on widespread social change, individual organisations can address the issue and consequences through deploying ideas like nonviolence, the Antimatter Principle, and redefining the collection of The Folks That Matter. Above all, though, progress depends on us recognising the medievalism implicit in the way our work works, and our relationships with that, and each other. Are you bovvered?

– Bob

Further Reading

Kahane, A. (2010). Power and Love: A Theory and Practice of Social Change. Berrett-Koehler Publishers, Inc.


The software industry is not the only domain in which dogma and conservatism combine to defeat effectiveness. Here’s an article on how the US Army (and USMC) are using Mission-type Tactics (Auftragstaktik) in name only (MTTINO).

Losing Small Wars:  Why US Military Culture Leads to Defeat

and a backgrounder on auftragstaktik:

How the Germans Defined Auftragstaktik: What Mission Command is – AND – is Not

And see also: Product Aikido for insight into (real) mission-type tactics for product development.

Psychological Safety – Oh! The Irony

The march of time seems to have judged “psychological safety” as a passing fad. Not that it’s an irrelevant idea – far from it. 

I suspect psychological safety gained some acclaim because everybody wanted it for themselves. “Yes, please. I feel anxious, exposed and at risk when I speak out, so I’d really appreciate some psychological safety, thank you.”

We’ll skip over the unlikely prospect of any managers being interested in providing an environment of psychological safety (why would they need to do that?) and get straight to the irony.

The Irony

I’ve spoken with some number of colleagues who all attest to feelings of anxiety, being exposed and being at risk of judgement by peers in the software community when they speak out about certain, possibly contentious or unpopular issues. 

Aside : I suspect it’s more often fear of the consequences of speaking out that’s at the root of these anxieties, rather that fear of being judged per se. 

The irony being, of course, that whereas individuals are fine with accepting psychology safety provided by others, they’re far less interested in extending psychological safety in turn.

What are you doing on a daily basis to extend psychological safety to others?

– Bob

Further Reading (1 June 2015). Tired of Being Judged? Try This. | Psychology Today. [online] Available at: [Accessed 13 Sep. 2021].

If you love books, and in particular books about business, organisations and software and product development, you’ll probably love Memeology. There’s more than 90 chapters, and almost every chapter has a host of references, in context.

(Aside: I’ve personally read almost every book and paper referenced in Memeology).

PS. I expect Memeology to reach 100% completion in just a few days now.


Do you feel under pressure to conform to conventions? To do things in accepted and established ways? Irrespective of the relative effectiveness of those conventions?

How do you handle that? 

  1. With good grace, understanding the need for consensus and conformity?
  2. With constructive criticism, attempting to spark discussions on the prevailing conventions and thereby change them?
  3. With surly compliance, resenting the stupidity of it all?
  4. With subterfuge and sabotage, attempting to illustrate the flaws in the conventions?
  5. Other?

I understand all the conventional approaches to software development. I can even reproduce them through teams and development organisations if asked. But why would I want to do that? Who might need me to do that?

Way Less Productive

The simple truth is that conventional approaches are more than five times less productive than unconventional approaches. (ISBSG data indicates that there can be a three orders of magnitude (that’s a thousand times) difference between conventional and unconventional approaches, at the project level).

Fear of the Unknown

Conventional approaches are all that organisations know, of course. Unconventional approaches, almost by definition, are unknown. Fear of the unknown is a strong buttress for the status quo. And so, convention wins out in most cases. 

But what about when organisations purposely try to overthrow a convention? Why is that scenario so problematic and likely to fail?

Maybe we can take a look at this scenario in more detail in a future post, given a demand.

– Bob

Industrialised Learned Helplessness

We often call something “industrialised” when we wish to suggest that it happens on a large scale, and has been dehumanised in some way. 

In many of my Organisational Psychotherapy gigs over the past decade I have seen learned helplessness writ large in individuals organisations, especially in development teams.

Curiosity Died

Ten or twenty years ago software folks seemed interested in new ways of doing things (in particular Agile software development). Curiosity was widespread and optimism too. There was a sweet scent of change for the better in the air. As far as I can tell, this has all but entirely disappeared now. 

Software folks seem more and more resigned to the fact that organisations – to wit, management – will just NOT do those things necessary to making software development successful. 


Is there any hope left in the software industry? Or are folks simply resigned to endless frustration and ineffectiveness?

– Bob

How Much Do You Care?

In recent times I have noted an upswing in the frequency of conversations about the ethical dimension of software development. Although still early days, many aspects of the social implications of software are beginning to receive more attention.

Effective Software Development

The dog’s breakfast that is Agile in the real world today exemplifies, for me, a key aspect of these ethical questions. Not that ethical questions are at all limited to the software industry.

What am I talking about? I’m talking about how people with a clear understanding of e.g. Agile software development (yes, there are some) tolerate, even support, a pallid, ineffective version in their workplace because their jobs and livelihoods depend on not rocking the boat. I’m talking about how folks go along with an ineffective and crippled approach for an easy life. Although how easy is it to stand by and watch project after project fail or limp along, with the consequent frustration and angst for all concerned?

With the oft-reported woefully low levels of employee engagement in most organisations, it’s hardly surprising that people just let such things slide by with little or no comment, complaint or action.


We might take a leaf out of Gandhi’s nonviolent campaign playbook. He placed the idea of satyagraha at the heart of his toolkit of civil resistance. What is satyagraha? Online references describe it as “truth-force” or “the force that is generated through adherence to truth”.

Note: In this context, I choose to regard “truth” as referring to ethical imperatives such as justice, fairness and righteousness, and not simply factual truth. And yes, everyone has their own “truths” a.k.a. assumptions and beliefs. As do groups, such as organisations.

At the core of satyagraha is the willingness to suffer for the truth. Spiritual, emotional and physical suffering, borne in public, serves to emphasise the degree to which the satyagrahi care about the issue upon which they are campaigning.

Do You Care Enough to Suffer?

In the case of Agile, as with other aspects of how organisations run themselves today, it’s fair for folks to ask:

“Is it any of my concern? Don’t senior people with much higher pay grades than me hold the responsibility for these things?”

How is this any different from the old defence “I was only following orders?” 

Do you care? Do you care enough to start to say “No.”? In a civil and polite way, of course.

Are you prepared to suffer to see things become better for all concerned?

– Bob


My latest book, “Memeology” is now 96% complete. All the memes are now completed. Some minor sections remain outstanding. Is it now time to buy? The Special Offer remains available to purchasers.

Why read this book? Memeology provides organisations with a raft of questions through which to surface and reflect on its collective assumptions and beliefs. Remember,

E = 𝑓(Mindset)

Organisational effectiveness is a function of the collective mindset of the organisation.

Who is responsible for the effectiveness of your organisation? And what tools do they have to work on that?

Lucky Thirteen

It’s been thirteen years now since I first published my work on Rightshifting. In that time, some select few folks have embraced the idea, and incorporated it into their practice.

The industry in general however remains blithely unaware of the idea, and continues to fail to deliver software effectively, on a regular basis. C’est la vie.

In case a recap might assist some folks in better understanding the relevance of the idea, here’s Rightshifting in a nutshell.

At Its Core

Rightshifting explains the factors which contribute to effective software development. If effective software development is not as issue for you, you can safely ignore the idea.

For those for whom effectiveness is of interest, Rightshifting introduces a variant of Lewin’s Equation for the software industry – and collaborative knowledge work in general:

E = 𝑓(Mindset)

Effectiveness is a function of the collective mindset of the organisation developing the software.

Addressing the Root Causes

Equipped with this explanation, those interested in effectiveness can focus of the root causes of the seemingly perennial Software Crisis.

I guess at least one reason folks ignore this explanation of software development effectiveness is that it’s much easier and more lucrative to sell patent medicines than sell an effective treatment of the root causes. 

– Bob

Further Reading

Ariely, D. (2009). Predictably Irrational: The Hidden Forces That Shape Our Decisions. Harper Perennial.
Rightshifting and the Marshall Model – Class 101. (2013, September 15). Think Different.

How To Predictably Deliver Great Software

What is “Great Software“?

Great software is software that meets the needs of the Folks that Matter™. The more needs met, and the more comprehensive the coverage of all the Folks That Matter, the “greater” the software.

Aside: I invite you to consider how the Needsscape plays into the above definition.

Ironically, when we dig into the needs of all the Folks That Matter, we find that great software often means no software. Strange?

Further, we regularly find that the needs of the developers and ancillary development staff trump the needs of the users and other customers. So we get software, even though users and other customers rarely need it.


Let’s assume for a moment that predictability (e.g. due date performance) is among the needs of some of the Folks That Matter. In this case, predictability is part of the “great” we were just talking about.

Predictability comes from anticipating and managing risks – actively, deliberately and competently. Formal approaches such as set-based concurrent engineering (SBCE) help manage the risk of finding oneself unable to bring a particular aspect of the solution to completion, for a variety of reasons. Identifying the Folks That Matter and their needs helps manage the risks involved in building the wrong thing, as does consideration of the Cost of Focus. Predictability demands we keep on top of all significant risks. (See: the All Holes in the Boat principle Cf. Gilb).


Know what needs you’re attending to. And whose.
This is not always possible, a priori. So identify as many of the Folks That Matter as you can (expect more to come to light as you proceed). Concurrently, investigate their needs through quickly delivering early exploratory things such as mock-ups, paper-prototypes, sketches of various kinds, and conversations. “Quickly” here means in a few hours, or days at most. Expect to have to iterate on this.

Many developers assume that someone else will be handing them a list of the Folks That Matter along with a definitive statement of the needs of those folks. If that other party is competent and sufficiently resourced, this can work. I’ve never seen it. I prefer to have the developers own this crucial information, and the gathering and updating thereof too. This is not popular in many organisations, shining a light as it does on the inadequacies of the way the work works, the management, the analysts, the product owner(s) and so on.

In parallel with these investigations, make a start on building the solution. In particular, those parts of the solutions which seem relatively stable, and where you feel the needs are relatively well understood. This can even involve writing some software – if you really must. Manage the risk of not knowing how to build certain things through e.g. “Spikes” and other risk mitigations.


“Surely there’s more to it that this?’ I hear you ask.
Well, actually, no. We’ve been hoodwinked into thinking that software development is “the most complex endeavour known to man” ~ Jim McCarthy

Actually, if tackled appropriately it’s quite a pussy cat. People make it much more difficult than it really is. Will the industry ever grow up?

– Bob

Further Reading

Waltzing With Bears ~ Tom Demarco and Tim Lister
Sketching User Experiences ~ Bill Buxton
Principles of Software Engineering Management ~ Tom GIlb
Beyond Command and Control ~ John Seddon

%d bloggers like this: