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

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 operational effectiveness of any knowledge work organisation is a function of its collective assumptions and beliefs about work. Significant improvements to organisational effectiveness 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 effectiveness of any and all knowledge work organisations is a function of the collective mindset of the organisation. For significant improvements in the effectiveness of the organisation, the collective mindset has to undergo a step-change.

E = ƒ(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 effectiveness. For the fewer number of organisations that do seek to improve their effectiveness, questions such as “what makes for increased effectiveness” and “what could we do to improve our effectiveness as an organisation” 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 effectiveness in the desired direction(s).

Some yet fewer number of organisations may come to understand the connection between their collective mindset and their effectiveness – 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 effectiveness?”

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 effectiveness, 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 effectiveness, 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, therapy enabling reflection and leading to possible shifts in assumptions and beliefs, 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.

– Bob

Beyond Command and Control – A Book Review

BeyondCommand&ControlCover

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 that approach is 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 looking 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

What Orgs Want

Offices

Or, more accurately, what organisations need. (Wants and needs are very rarely the same thing).

First off, does it make any sense to talk about what an organisation might need? Sure, we can discuss the needs of the various groups within an organisation – the Core Group, the shareholders, the employees, and so on. And the needs of the individuals involved – not that the subject of individual needs get much airtime in the typical organisation.

NB I recently wrote a post about the needs of some of these groups in “Damn Outcomes!”.

Back at the main theme of this post: what might be the needs of a given organisation?

Well, like individuals, we make sweeping generalisations at our own risk. At least for individuals, we have some guidance in the form of Maslow’s hierarchy of needs.

From the perspective of Organisational Psychotherapy, an organisation’s needs, whilst fundamental, rarely receive much overt attention. In the course of the therapeutic relationship, the organisation itself may come to a clearer awareness of its own (collective) needs. Those needs may even change and morph as they emerge, become more explicit, and become a valid topic for dialogue and discussion (i.e. ”discussable”).

But we have some basic options for consideration re: the possible needs of an organisation. I wrote about these options some time ago now, in a post entitled “Business Doctrine”. Extrapolating from that post, here’s some possible business (organisational) needs:

  • The need to create and keep customers (Drucker)
  • The need to supply goods and services to customers (serve the needs of the customer) (Drucker)
  • The need to provide a service (Burnett)
  • The need to provide a product or service that people need and do it so well that it’s profitable (Rouse)
  • The need to act as a nexus for a set of contracting relationships among individuals (Jensen and Meckling)
  • The need to optimise transaction costs when coordinating production through market exchange (Coase)
  • The need to serve society (McLaughlin et al)
  • The need to maximise the medium-term earning per share for shareholders (US business schools)
  • The need to make a profit so as to continue to do things or make things for people (Handy)
  • The need to make money (Slater)
  • The need to make a profit (Watkinson Committee)

Given the Rightshifting perspective that the purpose of any given business is more or less unique to a time, a place, and the people involved, we might reasonable say that the needs of any given organisation are also more or less unique to a time, a place, and the people involved.

Summary

To sum up: I choose to believe that organisations, collectively, do have needs. Each organisation is different – it has its own, different and sometime unique needs. The dialogue involved in surfacing any given organisation’s needs brings benefits in and of itself. Absent clarity on those needs, how can the organisation decide on its priorities, on what matters?

– Bob

Further Reading

The Future Of Software-Intensive Product Development – Think Different blog post

 

My Work

My work of the past ten+ years tells executives, managers and employees:

  1. What is the root of the problems in their organisation
  2. What to do about it (how to fix it)
  3. Why they won’t do anything about it

The Root of the Problems

The root of the problems in your organisation is the collective assumptions and beliefs (I generally refer to these as the collective mindset) held in common by all people within the organisation. Most significant (in the conventional hierarchical organisation) are the assumptions and beliefs held in common by the senior executives. In the Marshall Model I refer to the most frequently occurring set of collective assumptions and beliefs as the Analytic Mindset.

In knowledge-work organisations in particular, the Analytic Mindset is at the root of most, if not all, major organisational dysfunctions and “problems”.

What to Do About It

The way forward, leaving the dysfunctions of the Analytic Mindset behind, is to set about revising and replacing the prevailing set of collective assumptions and beliefs in your organisation with a new set of collective assumptions and beliefs. A collective mindset less dysfunctional re: knowledge work, one more suited to (collaborative) knowledge work. In the Marshall Model I refer to this new, more effective set of collective assumptions and beliefs as the Synergistic Mindset. Yes, as an (occasionally) rational, intentional herd, we can change our common thinking, our set of collective assumptions and beliefs – if we so choose.

Why You Won’t Do Anything

You may be forgiven for thinking that changing a collective mindset is difficult, maybe impossibly so. But that’s not the reason you won’t do anything.

The real reason is that the current situation (the dysfunctional, ineffective, lame behaviours driven by the Analytic Mindset) is good enough for those in power to get their needs met. Never mind that employees are disengaged and stressed out. Never mind that customers are tearing their hair out when using your byzantine software products and screaming for better quality and service. Never mind that shareholders are seeing meagre returns on their investments. Those in charge are all right, Jack. And any suggestion of change threatens their relatively comfortable situation.

So, what are you going to do? Just ignore this post and carry on as usual, most likely.

– Bob

Damn Outcomes!

It seems in vogue to extol the praises of “outcomes” when discussing e.g. software and product development. Setting aside the challenges of defining what we might mean by “outcomes” (I dislike getting into rabbit-hole discussions of semantics), there’s one key aspect of this debate that seems to escape folks’ attention. W Edwards Deming nailed it decades ago with his First Theorem:

“Nobody gives a hoot about profits.”

Even so, Deming said little about what folks (managers, in his frame) DO give a hoot about. We can turn to Russell L. Ackoff for an insight into that:

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

As Dr. Ackoff says, a secondary focus on profits is just the cost executives must pay in order to maximize their rewards. The actions taken would be different if the well being of the organization was primary and the well being of senior executives subservient to that aim.

Outcomes

So, to outcomes. The outcomes that delight will be those that maximise the executives’ (and other folks’) well being. When developing a piece of software, how often do the specifics of the well being of the Folks That Matter get discussed? Indeed, is the subject even discussable? Or is it taboo? In your organisation?

How unsurprising then, that software as delivered is so often lacklustre and uninspiring. That it fails to address the core issues of the well being of the Folks That Matter? That it’s the wrong software.

As a developer or team, do you ever afford your customers (a.k.a. the Folks That Matter) the opportunity to talk about their well being? And how what you’re doing for them might contribute to that well being?

So, might I invite you to stop talking about specious and illusory “outcomes”. And start asking the difficult questions of your customers (and yourselves)?

Here’s a possible opener:

“Would you be willing to discuss what it is you need for your own well being?”

– Bob

Further Reading

Nobody Gives a Hoot About Profit ~ The W. Edwards Deming Institute Blog post
Agile Competency Is A Crock ~ Think Different blog post

The Aspiration Gap

Some years ago I wrote a post entitled “Delivering Software is Easy“. As a postscript I included a chart illustrating where all the jobs are in the software / tech industries, compared to the organisations (and jobs) that folks would like to work in. It’s probably overdue to add a little more explanations to that chart.

Here’s the chart, repeated from that earlier post for ease of reference:

Chart illustrating the gap between available jobs and jobs folks would like to have.

The blue curve is the standard Rightshifting curve, explained in several of my posts over the years – for example “Rightshifting in a Nutshell“.

The green curve is the topic of this post.

The Green Curve

The green curve illustrates the distribution of jobs that e.g. developers, testers, coaches, managers, etc. would like to have. In other words, jobs that are most likely to best meet their needs (different folks have different needs, of course).

Down around the horizontal zero index position (way over to the left), some folks might like to work in these (Adhoc) organisations, for the freedom (and autonomy) they offer (some Adhoc organisations can be very laissez-faire). These jobs are no so desirable, though, for the raft of dysfunctions present in Adhoc organisations generally (lack of things like structure, discipline, focus, competence, and so on).

The green curve moves to a minimum around the 1.0 index position. Jobs here are the least desirable, coinciding as they do with the maximum number of Analytic organisations (median peak of the blue curve). Very few indeed are the folks that enjoy working for these kinds of organisations, with their extrinsic (imposed) discipline, Theory-X approach to staff relations and motivations, strict management hierarchies, disconnected silos, poor sense of purpose, institutionalised violence, and all the other trappings of the Analytic mindset. Note that this is where almost all the jobs are today, though. No wonder there’s a raging epidemic of disengagement across the vast swathe of such organisations.

The green curve then begins to rise from its minimum, to reach a maximum (peak) coinciding with jobs in those organisations having a “Mature Synergistic” mindset (circa horizontal index of 2.8 to 3). These are great places to work for most folks, although due to the very limited number of such organisations (and thus jobs), few people will ever get to experience the joys of autonomy, support for mastery, strong shared common purpose, intrinsic motivation, a predominantly Theory-Y approach to staff relations, minimal hierarchy, and so on.

Finally (past horizontal index 3.0) the green curve begins to fall again, mainly because working in Chaordic organisations can be disconcerting, scary (although in a good way), and is so far from most folks’ common work experiences and mental image of a “job” that despite the attractions, it’s definitely not everyone’s cup off tea.

Summary

The (vertical) gap at any point along the horizontal axis signifies the aspiration gap: the gap between the number of jobs available (blue curve) and the level of demand for those jobs (green curve) – i.e. the kind of jobs folks aspire to.

If you’re running an organisation, where would you need it to be (on the horizontal axis) to best attract the talent you want?

– Bob

Footnote

For explanations of Adhoc, Analytic, Synergistic and Chaordic mindsets, see e.g. the Marshall Model.

 

Obduracy

I tweeted recently:

“The things organisations have to do to make software development successful are well known. And equally well known is the fact that organisations will absolutely not do these things.”

Here’s a table comparing some of the things we know are necessary for success, alongside the things organisations do instead.

Necessary for Success What Organisations Do Instead
Teamwork Heroic individualism
Primacy of people skills Primacy of tech skills
Self-organisation, self-management Managers managing the work(ers)
Systems view of the organisation Partition the organisation into discrete silos
Manage the organisation/system as an integral whole Manage each silo separately
Use systemic measures to steer by Use silo-local measures to steer by 
Relationships matter most (quality of the social dynamic) The code’s the thing (e.g. velocity)
Effectiveness (do the right things) Efficiency (do things right)
Zero defects (quality is free) (defect prevention) Testing and inspections
The workers own the way the work works Mandated processes and methods (management owns the way the work works)
Workers are generalists Workers are specialists 
Trust Rules, policies
Theory Y Theory X
Intrinsic motivation, discipline Extrinsic (imposed) motivation, discipline 
Everyone’s needs matter (everyone’s a customer and a supplier) Only the bosses’ needs matter (your boss is your only customer)
Explicit requirements, negotiated and renegotiated with each customer, just in time No explicit requirements, or Big Requirements Up Front
Incremental delivery against the needs of all the Folks That Matter, short feedback loops  Big Bang delivery, some or all constituencies overlooked or ignored, long or no feedback loops
Kaikaku and kaizen, to serve business goals Kaizen only, by rote
No estimates, flexible schedules Estimates, fixed schedules
Smooth flow (a regular cadence of repeatably and predictably meeting folks’ needs) “Lumpy” or constipated flow 
Work is collaborative knowledge work Work is work
People bring their whole selves to work People limit themselves to their “work face”.

Do you have any more entries for this table? I’d love to hear from you.

– Bob

The Big Shift

Let’s get real for a moment. Why would ANYONE set about disrupting the fundamental beliefs and assumptions of their whole organisation just to make their software and product development more effective?

It’s not for the sake of increased profit – Deming’s First Theorem states:

“Nobody gives a hoot about profits”.

If we believe Russell Ackoff, executives’ motivation primarily stems from maximising their own personal well being a.k.a. their own quality of work life.

Is There a Connection?

Is there any connection between increased software and product development effectiveness, and increased quality of work life for executives? Between the needs of ALL the Folks That Matter and the smaller subset of those Folks That Matter that we label “executives”? Absent such a connection, it seems unrealistic (understatement!) to expect executives to diminish their own quality of work life for little or no gain (to them personally).

Note: Goldratt suggests that for the idea of effectiveness to gain traction, it’s necessary for the executives of an organisation to build a True Consensus – a jointly agreed and shared action plan for change (shift).

Is Disruption Avoidable?

So, the question becomes:

Can we see major improvements in the effectiveness (performance, cost, quality, predictability, etc.) of our organisation, without disrupting the fundamental beliefs and assumptions of our whole organisation?

My studies and experiences both suggest the answer is “No”. That collaborative knowledge work (as in software and product development) is sufficiently different from the forms of work for which (Analytic-minded) organisations have been built as to necessitate a fundamentally different set of beliefs and assumptions about how work must work (the Synergistic memeplex). If the work is to be effective, that is.

In support of this assertion I cite the widely reported failure rates in Agile adoptions (greater than 80%), Lean Manufacturing transformations (at least 90%) and in Digital Transformations (at least 95%).

I’d love to hear your viewpoint.

– Bob

Further Reading

Organisational Cognitive Dissonance ~ Think Different blog post

Gratitude

Joy, for me, is helping folks in ways that they have a need to be helped. So I feel appreciative, moved and thankful when someone takes the time to let me know how my help has made a positive contribution to their lives.

I regularly have folks quietly letting me know about how I’ve made some contribution to their journey. Most recently, Andy Tabberer (@ConsultantMicro on Twitter) has been kind enough to share his experiences, and with his permission, share with you.

In this case, it’s particularly pleasing, both because he’s representative of my primary audience (tech management) and because my chosen style has resonated with him. Here’s his unexpurgated words:

I first heard of Bob Marshall – @flowchainsensei – through Twitter. I cannot remember how exactly, but I guess it was a question, the type of searching question that comes easilyi to Bob, that piqued my interest. Since then, Bob has taken me, indirectly, on a journey of self-improvement through his questioning and prompting on Twitter and through his blog.

Why am I telling you this? Well, a while ago, Bob asked his followers if anything he had tweeted or blogged had been of any use, had anything he’d produced been used to do something good.

This is my reply to that question.

My examples are:

The blog that encouraged me to challenge the status quo in my work was What are Non-Obvious Systemic Constraints?. Among other constraints listed, the ‘Business As Usual’, ‘Mandatory optimism’ and ‘Fear of conflict’ examples really resonated with me. It felt like I was able to hold my company up to the light for the first time and see its true colours.

I felt compelled to reconsider the role of the management team, of which I was a part. Bob’s examples helped me to show others how our company was failing in ways we could not see. It emboldened me to challenge our conventional thinking and our hierarchy and its “remarkable impact on the ability of the organisation to evolve, improve, and raise its effectiveness”.

Bob’s blog also introduced me to Eli Goldratt. After a quick google search, I landed on a review of a graphic novel of the Goal, an easy to read version of Goldratt’s seminal work. It was quickly added to my Christmas list. This book changed my view of the workplace and in particular how bottlenecks impact our productivity. So many of my former colleagues have Bob to thank for being branded bottlenecks, a few of them would even thank him.

Finally, I have Bob to thank for an introduction to Deming. This name kept popping up again and again. I eventually went off in search of material to read – I have Four Days with Deming lined up to read next – and I alighted at the Deming Institute blog. After a little browsing, I settled down to watch the following video by David Lanford -> blog.deming.org/2013/08/attrib. The impact of this video was so profound that it eventually led to a programme of organisation-wide quality goal setting – that I instigated – and, ultimately, my resignation and my decision to move onto pastures new.

I’d like to finish by saying that Bob makesii me think every day. Sometimes I find him frustrating because he answers with a question, never giving advice. This, however, leads me to what I suppose is Bob’s biggest impact on me, which is the path to improvement is forged through questioning. I guess I’ve never encountered anyone who sought only to help others improve rather than dispense self-serving advice designed to reinforce one’s own view of one’s worth or to confirm one’s place in the hierarchy. I’m grateful for that, Bob.

Notes:

i) These questions may seem to come easily, but often they take time, effort and consideration. Not to mention empathy.

ii) I’d be happier to say “invites” rather than “makes” (might be misinterpreted as compulsion or obligation).

In closing, I’d like to thank Andy again, and invite others to contribute their experiences, too.

– Bob

Something’s Gotta Give

 

“The things businesses have to do to make software development successful are well known. And equally well known is the fact that businesses will absolutely not do these things.”

This reality puts us in a bind. We find ourselves in a position where we have to trade off successful development against conforming to organisational norms. We can have one – or the other. It’s not a binary trade-off, we can for example relax some norms and gain some (small) improvements in success. But by and large it’s a zero sum game. At least from the perspective of those folks that find value in everyone conforming to preexisting norms.

I don’t think many business folks realise this trade-off exists. Almost all the business folks I have met over the years seem unaware that their norms are what’s holding back their success in software (and product) development. I put this down to the absence of any real understanding of the fundamentally different nature of collaborative knowledge work (different to their experiences and assumptions).

Some of the Things

By way of illustration, here’s just a few of the things that are necessary for successful software (and product) development, that businesses just won’t do:

De-stressing

Removing stressors (things that create distress) from the workplace. These things include: job insecurity; being directed and controlled; being told where, when and how to work; etc..

Stressors serve to negatively impact cognitive function (amongst other things).

Trusting

Placing trust in the folks actually doing the work. We might refer to this a a Theory-Y posture.

Experimenting

Finding out through disciplined and systematic experimentation what works and what doesn’t. See: the Toyota Improvement Kata.

Being Human

Embracing what it means to be human; seeing employees as infinitely different, fully-rounded human beings with a broad range emotions, needs and foibles (as opposed to e.g. interchangeable cogs in a machine).

Intrinsic Discipline

Relying on intrinsic motivation to encourage and support a disciplined approach to work.

Meaningful Dialogue

Talking about what’s happening, the common purpose, and what the problems are.

Eschewing Numbers

Realising the limitations with numbers, dashboards, KPIs and the like and finding other ways to know whether things are moving in the “right direction”.

Prioritising Interpersonal Relationships

In collaborative knowledge work (especially teamwork), it’s the quality of the interpersonal relationships that’s by far the greatest factor in success.

Summary

If your organisation needs to see more success in its software (and product) development efforts, then something’s gotta give. Specifically, some of its prevailing norms, assumption and beliefs have gotta give. And given that these norms come as a self-reinforcing memeplex (a.k.a. the Analytic Mindset), a piecemeal approach is highly unlikely to afford much in the way of progress.

– Bob

Hearts over Diamonds Preface

In case you’re undecided as to whether my recently published book on Organisational Psychotherapy will be worth some of your hard-earned spons, here’s the text of the preface to the current edition (full book available in various ebook formats via Leanpub and in paperback via Lulu.


Will This Book be Worth Your Time?

To my knowledge, this is the first book ever written about Organisational Psychotherapy. Thanks for taking the time to have a look. This is a short book. And intentionally so. It’s not that Organisational Psychotherapy is a shallow domain. But this book just lays down the basics. Understanding of the deeper aspects and nuances best emerges during practice, I find.

This book aims to inform three distinct groups of people:

  • Senior managers and executives who might find advantage in hiring and engaging with an Organisational Psychotherapist.
  • Folks who might have an interest in becoming Organisational Psychotherapists themselves, either within their organisations or as e.g. freelancers.
  • Folks within organisations who might find themselves involved in some way in their organisation’s engagement with one or more organisational psychotherapists.

We’re all busy people, so I guess you may be curious, or even a little concerned, as to whether this book will provide a good return on the time you might spend reading it. I’ve tried to arrange things so that you can quickly answer that question.

I intend this book to be easy to understand, and to that end I’ve used as much plain English as I can muster. I guess some folks find the whole idea of Organisational Psychotherapy somewhat intimi‐ dating, and fear the ideas here will “go over their heads”. Let me reassure you that I’ve tried to make this book common-sensical, friendly and down-to-earth.

Foundational

“Out beyond ideas of wrongdoing and rightdoing there is a field. I’ll meet you there.”

~ Rumi

In writing this book, I’ve set out to define the emerging discipline – or field – of Organisational Psychotherapy.

In a nutshell, Organisational Psychotherapy is a response to the growing realisation in business circles that it’s the collective mindset of an organisation (often mistakenly referred-to as culture) that determines an organisation’s overall effectiveness, productivity and degree of success. By “collective mindset” I mean the beliefs, assumptions and attitudes that an organisation as a whole holds in common about work and how the world of work should work.

Roots

Organisational Psychotherapy leverages over a hundred years of research and experience in the field of personal psychotherapy, a field which has evolved from its roots in the Middle East in the ninth century, and later, in the West, through the works of Wilhelm Wundt (1879) and Sigmund Freud (1896). Research and experience which, in large part, can usefully be repurposed from the individual psyche to the collective psyche (i.e. the organisation).

In my career of over thirty years in the software business, I’ve run the whole gamut of approaches in search of organisational effectiveness, in search of approaches that actually work. It’s been a long and tortuous journey in many respects, but I have come to believe, absolutely, that success resides mostly in the relationships between people working together, in the web of informal customer- supplier relationships within and between businesses. And I’ve come to believe that organisational effectiveness mostly comes from the assumptions all these folks hold in common.

Given that, I ask the question:

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

The answer I’ve arrived at is Organisational Psychotherapy. And so, when I’m working with clients these days, Organisational Psychotherapy is my default mode of practice.

But this book does not attempt to make the case for my beliefs. It’s not going to try to persuade you to see things my way. Organisational Psychotherapy may pique your interest, but I’m pretty sure you’ll stick with what you already believe.

So, if you have an open mind, or generally share my perspective already, this book may serve you in getting deeper into the practicalities and benefits of Organisational Psychotherapy, whether that’s as:

  • a decision-maker sponsoring an intervention
  • a potential recruit to the ranks of organisational psychotherapists
  • an individual participating in an Organisational Psychotherapy intervention in your organisation

Relationships Govern Dialogue

A central tenet of Organisational Psychotherapy is that it’s the quality of the relationships within and across an organisation that moderates the organisation’s capacity for meaningful dialogue. As we shall see in more detail later, fragmented and fractious relation‐ ships impair an organisation’s ability to surface, discuss and recon‐ sider its shared beliefs.

Effective Organisational Psychotherapy needs a certain capacity for skilful dialogue within and across an organisation. Absent this capacity, folks have a slow, laborious and uncomfortable time trying to surface and discuss their commonly-held beliefs and assumptions.

In practice, then, any Organisational Psychotherapy, in its early stages at least, must attend to improving relationships in the workplace, and thus the capacity for meaningful dialogue. This helps the organisation have more open and productive dialogues – should it wish to – about its core beliefs and implicit assumptions, about its ambitions and goals, about the quality of its relationships and dialogues, and about its strategies for success. I wholeheartedly believe that:

People are NOT our greatest asset. In collaborative knowledge work particularly, it’s the relationships BETWEEN people that are our greatest asset.

Whether and how the organisation might wish to develop those relationships and dialogues in pursuit of its goals is a matter for the organisation itself. Without Organisational Psychotherapy, I’ve rarely seen such dialogues emerge and thrive.

The Goal

Improving relationships in the workplace, and thereby helping the emergence of productive dialogues, are the means to an end, rather than the end itself. The goal of all Organisational Psychotherapy interventions is to support the client organisation in its journey towards being more – more like the organisation it needs to be. Closer to its own, ever-evolving definition of its ideal self.

We’ll explore what that means in later chapters.

References

Lencioni, P. (2012). The Advantage: Why organizational health trumps everything else in business. San Francisco: Jossey-Bass.

Patterson, K. (2012). Crucial Conversations: Tools for talking when stakes are high. Place of publication not identified: McGraw Hill.

Schein, E. H. (2014). Humble Inquiry: The gentle art of asking instead of telling. San Francisco: Berrett-Koehler.

Red Lines

There’s been a lot of talk about Theresa May’s “Red Lines” in the media recently.

Every organisation I’ve ever known has had their own Red Lines – ideas, principles, practices and policies which are deemed unacceptable, beyond the pale. Many of these latter would make the organisation markedly more effective, efficient or profitable, yet are ruled out.

Here’s a list of such ideas, in roughly increasing order of benefit and unacceptability both:

Transparency of salaries
Attending to folks’ needs
Nonviolence
Restorative justice (vs Retributive justice)
Self-organising / self-managing teams
No estimates
No projects
No tools
No software
Defect prevention (ZeeDee) approach to Quality (vs Testing / Inspection)
Employees choosing their own tools, languages and development hardware
Employees designing / owning their own physical workspace(s)
(colour schemes, lighting, furniture, floor plans, drinks machines, games etc.) 
Employees choosing their own ways of working (methods, processes)
Organising to optimise Flow (vs costs)
Employees choosing their own working locations (office, cafe, remote, etc.)
Employees choosing their own working hours (incl. hours per day / week)
Employees forming their own teams
Employees guiding their own training and career, skills development
Employees hiring their own peers (and coaches)
Paramountcy of interpersonal relationships and social skills (vs tech skills)
Organisational Psychotherapy
Teams appointing their direct managers
Teams appointing their senior managers
“Open book” financials
Employees choosing their own salaries and terms of employment
Teams awarding themselves their own bonuses
No managers (alternatives to control hierarchies)
Fellowship (No positional leadership)
Do nothing that is not play

Where does your organisation draw its red lines – and how much more effective could it be if it redrew them?

– Bob

 

Standard Work and Collaboration

[Tl;Dr: Ad-hoc and impromptu collaboration is a signal – that our standard work is incomplete or insufficient, and that we don’t understand as much about what we’re doing and how, as we’d like to think.]

Standard Work

Standard work (also known as Standardized Work) is an operational definition of how the work works today. Best written and maintained (studied, updated) by the folks actually doing the work. Toyota defines Standard Work as ”the steps one needs to walk in order to complete a process”. Mike Rother defines Standard Work as the “Target Condition” in the Improvement Kata. This seems to me to make some sense.

“There is something called standard work, but standards should be changed constantly.”

~ Taiichi Ohno, Workplace Management

5W+1H

In slightly more detail: “Standardized work answers the 5W+1H of a process – the who, what, when, where, why, and how. Who operates the process, and how many people does it take? What does the final product look like, what are the quality check points, what are the tools required to complete the job? When is a part completed and ready for the next step (how long should the cycle time and takt time be)? Where is this process completed and what does this location look like (standardized work cell, point of use storage of tools, etc)? Why is this step necessary or value-adding, or why is this a quality check point?”

“When there is no standard [work], there is no Kaizen (continual improvement).”

~ Taiichi Ohno

In other words, when a process is performed unsystematically in different ways, then:

  1. There can be no basis for comparison (before/after)
  2. One cannot objectively tell if there was a difference or change
  3. No improvement is possible in regards to Time, Quality, Quantity, Cost, etc.

Collaboration is Waste

So, where does collaboration come into the picture? If the standard work specifies “collaborate here” (with 5W+1H or an operation definition for the collaboration) for a particular step, then all is fine and dandy.

But often, in software development particularly, there is no standard work, or the standard work lacks the detail which might suggest the 5W+1H of the collaboration. Exceptions which come to mind are: the daily standup (Scrum), sprint planning (Scrum) and sprint retrospectives (Scrum) (i.e. the various Scrum ceremonies – for which teams rapidly find their own work standards or de facto operational definitions).

Consequently, collaboration in software development is most often ad-hoc. Someone might run into a problem or challenge, and ask a colleague e.g. “Hey, can you help me with this?” or “Can we pair on this for half an hour?” or “Let’s get together and figure out what to do here”.

If we had clearly defined standard work, the specifics of what to do and who to call on when a problem arises would already be defined. Without such standard work, the coordination (set-up, figuring-out) of the necessary collaboration is waste, and interrupts the flow (both of value, and in the Mihaly Csikszentmihalyi sense of the word).

Do I hear you rail against this idea? Do you believe it’s impossible to foresee where and when collaboration might be necessary? Do you enjoy collaborating so much that you’re prepared to dismiss its negatives? May I put it to you that in such circumstances, you don’t actually know what y’all are doing? That you have little or no clear idea how to get from the start of sprint (or longer term) to the end, to the delivery of value? That you’re making much of it (“the way the work works”) up as y’all go along?

“…this model of ‘standards’ as something for compliance is a cancer that is holding us back in our quest to establish a new level of understanding around what ‘continuous improvement’ really means.”

~ Mark Rosenthal

The Bottom Line

This may all seem rather esoteric. How much can it matter whether collaboration costs us a few dollars or hours? For me, ad-hoc and impromptu collaboration is a signal – that our standard work is incomplete or insufficient, and that we don’t understand as much about what we’re doing and how, as we’d like to think.

Does it matter? I leave that to y’all to decide.

– Bob

Further Reading

What Is Standardized Work (And What Is It Not)? ~ LeanBlitz article
Mike Rother: Time to Retire the Wedge ~ Mark Rosenthal

 

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 ( corresponding, BTW, to the twelve principles of the Agile Manifesto). 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 only 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

%d bloggers like this: