Archive

Dialogue

Tumbleweed

Tumbleweed: A dusty aggregation of plant matter rolling along the ground by the desert wind. A cliche of cowboy movies, emphasising silence or stillness, e.g. as the hero rides into an apparently deserted frontier town. Often used in connection with the death of a conversation.

Also, that sensation I get whenever I mention an idea of mine to peers and colleagues.

Meaningful Conversations

Over the course of more than twenty years, I guess I’ve had a meaningful conversation about my ideas (FlowChain, Marshall Model, Prod•gnosis, Flow•gnosis, Product Aikido, Antimatter Principle, etc.) maybe two or three times, total.

I’ve always wondered what it might take to up that count.

Reversing the tables for a moment, I sometimes find myself in the position of being invited to consider and discuss someone else’s idea. Reflecting, I’ve found it difficult to engage with such discussions. In retrospect, asking myself why that might be, I guess the following factors come into play:

  • I struggle to see the value or benefit of the idea. Absent some insight into same, a discussion can feel purely arbitrary, academic or theoretical.
  • I have some reluctance to discuss ideas in the abstract, finding it invites judgment (something I try to avoid) and icky ad hominem considerations.
  • My frame of reference is often way off from that of the originator of the idea. The prospect of getting onto the same page (or even close) seems like a mountain to climb, for little return.
  • We’re not best equipped to discuss ideas, preferring as flawed humans to stick to our comforting biases, assumptions and beliefs rather than engage in mutual exploration with the risk of discomforting changes.

I guess that having stimulating discussions on ideas generally relies on a normative situation. In other words, unless and until someone begins to implement an idea, begins to try it out in their context, to wrestle with making it concrete, there’s little chance of any deep and meaningful discussions.

– Bob

 

Six FAQs Explored

Recently, Adelbert Groebbens (@agroebbe) made an observation on Twitter to the effect that getting other people to understand what we’d like them to understand is a fool’s errand. He illuminated the point with a reference to my Six FAQs post. Al Shalloway expressed his disagreement with many of the points therein. This post explores the subject, via a dialogue between Al and myself, conducted over email recently, and in the context of the original Six FAQs post.

Note: the # numbers relate to the numbered points in Al’s original tweets.

The Dialogue

@alshalloway: (Opening): Thanks. but i disagree with most of the points there [in the original Six FAQs post].

@FlowchainSensei (response): Thanks Al for providing your take on this post. Maybe you’d be willing to enter into a mutual exploration of the subject of e.g. motivation? I guess your comments (provided via Twitter and copied, below) reflect your experiences when working with developers and teams? Likewise, my original post [link] reflects my experiences in similar environments (with a little borrowing from Bill Deming, Russell Ackoff, Marshall Rosenberg and Carl Rogers, to name but a few). It comes as no surprise to me that our experiences differ somewhat, and that our respective conclusions differ likewise. That’s not to say I’m right, or you’re right – we could both be right. Or wrong. Or somewhere in between.

The Annotated Original Post 

Questions I’m frequently asked about software and product development organisations.

Q1: How can we motivate our workers?

A1: You can’t. [see: Al’s #1 follow-up comment, below] Oh, you can dream up incentive schemes, bonus packages, and so on, but there’s plenty of research – and experience – to show that such attempts at extrinsic motivation of knowledge workers only make folks’ performance on the job worse. On the other hand, intrinsic motivation is very powerful – but that comes from the workers themselves. The only thing you can do is to work on creating an environment where maybe, just maybe, some folks feel a little better about themselves, their colleagues, and the common purpose. And hope – yes hope – that some intrinsic motivation emerges, here and there. You can’t change someone else’s intrinsic motivation – only they can do that.

@alshalloway: #1:  Pretty much agree but don’t like tone. Most workers will respond to not being de-motivated. the “maybe, just maybe” is what i don’t like.

@alshalloway: #1: (Follow-up): you can’t motivate, you can only stop demotivating. In other words, you can’t motivate them, but you can do other things that are useful. 

@FlowchainSensei: #1: I guess your assessment of the “tone” here differs from mine. How often do e.g. managers or others responsible for the workplace “environment”, when attempting to cultivate a climate conducive to intrinsic motivation, succeed in those attempts? My experiences suggest “occasionally”. I guess you concur on the main point here: that intrinsic motivation can only come from the folks themselves (the emergence of same being aided by efforts to reduce or remove demotivators – shades of Drucker, Herzberg)? 

@alshalloway: Agreed that most managers don’t do this [attempt to cultivate a climate conducive to intrinsic motivation]. But much of that is because it’s never been explained to them [as] a new role they can fill.

@FlowchainSensei: Explaining presupposes they’re motivated to listen to explanations. I’m minded of the following quotations:

“Most of what we call management consists of making it difficult for people to get their work done.”

~ Peter Drucker 

“If you want people to do a good job, give them a good job to do.”

~ Frederick Herzberg

Q2: How can we change the organisation’s culture?

A2: You can’t. [see: Al’s #2 follow-up comment, below] Culture is read-only. A manifestation and a reflection of the underlying, collective assumptions and beliefs of all the folks working in the organisation. To see any cultural changes, you have to work on – by which I mean work towards a wholesale replacement of – this underlying collective memeplex. And that involves working with peoples’ heads, and in particular, collective headspaces. You can’t change other people’s assumptions and beliefs – only they can do that. 

@alshalloway: #2: you can’t change an org’s culture directly, but you can change it indirectly. See my post “Improving Your Company’s Culture”. 

@alshalloway: #2: (Follow-up): you can’t change culture directly, but there are ways to do it indirectly. You can’t change it directly since culture is a result of many things in your company.

@FlowchainSensei: #2: I totally agree that “culture” can be changed indirectly (but not directly). To elaborate on this question, I propose that changing culture through examining assumptions and beliefs (more specifically, supporting folks who are interested in getting together to examine their own *collective* assumptions and beliefs) offers a way forward. For which see: Organisational Psychotherapy.

@allshalloway: I don’t think you need to change minds directly. Rather change how they [people] work.  It’s consistent with the idea “it’s easier to work your way into a new way of thinking than to think you’re way into a new way of working.”

@FlowchainSensei: I’d clarify that as “I don’t think you can change minds directly. Rather enable and encourage change to how the people doing the work choose to work. (See also:The People vs System Conundrum).

Q3: How can we change the mindset of managers?

A3: You can’t. Managers – anyone, really – will only change their mindset when they see how their present mindset is ineffective at getting their needs – and the needs of others – met. Change (of mindset) is a normative process – it emerges from direct personal experiences of e.g. the way the work works now – and the problems inherent therein. You can’t change someone else’s mindset – only they can do that.

@alshalloway: #3: I’ve changed mindsets by guiding people through their beliefs and showing them better ones. I’ve had special training in this.

@alshalloway: #3: (Follow-up): changing mindset is only possible when people are open to it.

@FlowchainSensei: #3: I agree with your follow-up statement. It’s been my experience that folks have difficulties when left on their own in this regard, even when open to the idea of “changing mindsets”. I have found that help, or support, or (your term) guidance can be valuable here. Hence, btw, Organisational Psychotherapy (support-for-changing-assumptions-and-beliefs-as-a-service).

@AlShalloway: Changing mindsets is difficult, and even when possible, takes a long time. It is important to show managers new opportunities and new ways they can interact with the people they work with.

@FlowchainSensei: When and if these managers are motivated to see and learn – see Q1. 

Q4: How can we get teams to take responsibility?

A4: You can’t. You can threaten, cajole, plead, bribe, appeal to folks’ better nature, etc. But again, research and experience both show these only serve to undermine folks’ goodwill and commitment. If you need folks to take more responsibility, maybe the best way is to just be honest about that, explain your need, and make a refusable request? What would you like the reason to be for them doing as you request? You can’t change someone else’s willingness to take responsibility – only they can do that.

@alshalloway: #4. Pretty much agree. But again, it’s the skeptic’s tone i object to. Many are ready to take responsibility, but like motivation, we’re de-motivating them to do so.  You could argue we agree – but it’s not clear.

@alshalloway: #4: (Follow-up): You can’t get people to take responsibility, but for those that are willing, you can remove the barriers to it.

@FlowchainSensei: #4: I guess our experiences differ here. I wonder how much that difference has to do with geographies and national cultures (I.e. UK vs USA)? In my experience (UK, and Europe too), many are not ready/willing to take responsibility, often through long experience of being punished or sanctioned for attempting to do so, or even for simply suggesting it. Is “Learned helpless” more prevalent in the UK, I wonder? I agree wholeheartedly with your follow-up statement.

Q5: How can we get managers to trust their teams?

A5: You can’t. Managers will only choose to trust their teams – or anyone else – if they find they have a need to do so. And that need only becomes obvious enough to spur action when managers come to understand just how trust helps them get some of their other needs met better. You can’t change someone else’s willingness to trust others – only they can do that.

@alshalloway: #5 Building trust is not easy but it’s possible. Most of the way Agile does it doesn’t work. You can’t presuppose it [trust] or blame people for not having it. Lean management can be helpful here.

@alshalloway: #5: (Followup): You have to build trust, and not everyone is willing to have this built.

@FlowchainSensei: #5: Agreed, especially with your observation that there are some folks who are, on the face of it, unwilling to participate in trust-building. I would love to hear more about the aspects of Lean management which you have in mind. For myself, I have found the Antimatter Principle and Nonviolent Communication both useful in trust-building efforts.

@alshalloway: Trust grows over time as people work together. An expectation that managers will all of a sudden trust their teams is doomed for disappointment. But we can teach managers how to work with people to build trust. Why am I not trusting their [the manager’s people] judgement? What is it that people need to know?

@FlowchainSensei: Agreed. Again, allowing for managers being willing (or unwilling) to be “taught”.

Q6: How can we develop people’s competencies?

A6: You can’t. You can, however, create conditions where those folks who want to develop their own competencies can do so more easily. So the question then becomes, how can we get folks to want to develop their own competencies? Which is Q1 (see above). You can’t change someone else’s willingness to learn – only they can do that.

@alshalloway: #6. Your title is inconsistent with what you say. You admit to being able to change competency if they are willing to learn. So it’s not possible.

@alshalloway: #6: (Follow-up): You can only improve people’s competencies when they are already willing to learn. 

@FlowchainSensei: #6: I’m unsure as to the meaning of your original comment. If your follow-up comment serves as a clarification, then I agree entirely. 

In a nutshell, the direct answer to all the above questions is: you can’t. But you can do at least one thing to make progress on all these questions: consider the Antimatter Principle.

Are you willing to be that radical? For that is what it boils down to. 

“We can’t solve problems by using the same kind of thinking we used when we created them.”

~ Albert Einstein

– Bob

Closing

@alshalloway: (Closing) I object mostly to the skeptic curmudgeonly style of the posts – the absolutism of it.  

@FlowchainSensei: (Closing): I guess I’m well-known and loved for my skeptical, curmudgeonly style. :}

Three Questions

There are three questions I like to ask my clients upon our first meeting. You might find them equally useful in your own dialogues within your particular organisation. Here are the three questions:

1. Is anyone in your organisation at all interested in productivity (or quality, or effectiveness)?

Note: Many folks will express an interest in productivity, quality or effectiveness, but not act congruent with this espoused interest. You might like to look into the work of Chris Argyris to learn more about this phenomenon (see: espoused theories vs theories-in-use). You may also care to look at what’s really happening within the organisation for evidence of actual interest in e.g. productivity.

If your true answer to question 1 is “no”, then there’s not much point proceeding to the next question.

But if there are folks in your organisation at all interested in productivity (or quality, or effectiveness), then question 2 is:

2. Do all interested parties agree that folks’ collective assumptions and beliefs about work, the world of work, and how work should work is at the root of effectiveness a.k.a. productivity?

If your answer to question 2 is “no”, then I propose you might like to look elsewhere for your answers, rather than proceed to question 3.

But if there are enough folks in your organisation who can agree that collective assumptions and beliefs about work, the world of work, and how work should work is at the root of organisational effectiveness a.k.a. productivity, then question 3 is:

3. How will you go about affecting this collection of shared assumptions and beliefs – in ways which translate to meeting folks’ needs for increased productivity (or quality, or effectiveness)?

Note: In some organisations, maybe there are already some initiatives or actions in train intended to bring about such a change in shared assumption and beliefs.

I’d be very interested to hear your answers.

– Bob

Your REAL Job

Students of Ackoff and Deming will be aware of Deming’s First Theorem:

“Nobody gives a hoot about profit.”

W. E. Deming

This reminds us that senior executives are demonstrably less interested in the welfare of the organisations they serve than in their own well being.

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

~ Russell L. Ackoff

Of course, it can be career-limiting to bring this issue to general attention. As the well-known psychiatrist R D Laing said:

“They are playing a game. They are playing at not playing a game. If I show them I see they are, I shall break the rules and they will punish me. I must play their game, of not seeing I see the game.”

~ R. D. Laing

And yet, if we look at the implications for “doing a good job” – a preoccupation of many in employment, we can draw the following conclusion:

We’re doing a good job when we’re maximising our executives’ (our bosses’) well being. We’re not doing a good job when we ignore that in favour of focussing on e.g. making the company successful or profitable. This probably rings true with you if you but think about it, in your own context, for a few moments.

This underscores a hidden reality for many: our declared job is a FAUX job. Our REAL job is undeclared, unexamined, unspecified – and being good at THAT is therefore a matter of pure dumb luck and random chance. How often do you have a conversation with your senior executives about how you might contribute to maximising their well being? How can we attend to their needs – as folks that matter – without such a dialogue?

– Bob

Further Reading

Nobody Gives a Hoot About Profit ~ The W. Edwards Deming Institute Blog post

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

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

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.

Random Walks

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

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

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

Quality Demands Requirements

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

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

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

Aside: In Javelin, we identify all stakeholders (a.k.a. all the Folks That Matter), discuss their needs (“Stakeholders’ Needs”, in Javelin parlance) and quantify them (a la Gilb – see: Competitive Engineering) in the form of Quantified Quality Objectives. Although:

  • This all generally proceeds incrementally, rather than in a big batch up front.
  • The information is always to hand by the time someone gets around to building the relevant part of the thing in question.
  • The requirements come from dialogue(s) with the relevant Folks That Matter.
  • The requirements need not get written down (documented) unless there are some Folks That Matter that need them to be.

People work from the requirements. Always.

Random Walks are not Our Bag

Random walks are not our bag.

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

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

– Bob

Excolat in Pace

There’s a common idea which has been doing the rounds, ever since development (coding) first became a thing. We might sum it up as:

“Developers just want to develop in peace.”

As someone who spent more than a decade in the development trenches (and still does development today, occasionally), I can instantly relate to this issue. Indeed, focus is the key question. Any kind of interruption or distraction whilst reading or writing code can suddenly evaporate the evolving mental model of the inner workings of that code, a model built up painstakingly, with deep concentration, over twenty minutes or more. So three for four interruptions or distractions, however trivial, can wipe out an hour of otherwise productive effort. And that’s before we get to the question of frustration, the impact of frustration-induced stress on the individual, and the stress-related impairment of cognitive function more generally.

On the other hand, having developers separated from the folks that matter introduces other productivity-sapping dysfunctions, such as misunderstanding folks’ needs, building the wrong things, and reducing the joy of getting to see how the developers’ efforts make a difference to others.

Conundrum

So, how to ensure developers have the peace they need to focus intently on their coding efforts, whilst also ensuring they have sufficient interactions with the folks that matter – sufficient to ensure that needs are understood and the right solutions get built?

In the past, specialist intermediaries a.k.a. Business Analysts and Project Managers have served to address this conundrum. And solutions (including the role of specialists, and the workplace environment) have been imposed on developers without much consultation. Rarely have developers, or the folks that matter, been involved in finding a way forward together.

Personally, and in the context of self-managing teams in particular, I’m all for the teams and their customers (both internal and external) getting together and thrashing out a way forward. And then having regular check-ins to improve those ways of working together.

As an example, BDD (Behaviour-deriven development) is a current set of practices that offers one such way forward. Customers and suppliers sitting down regularly (as often as several times a day, for maybe twenty minutes at a time) and working through a User Story, Scenario, or Use Case, together.

And let’s not forget that the other folks involved, aside from the developers, also have their day jobs – jobs which require them to focus and spend time on things other than working with the developers.

How do you, your teams, and their folks that matter, propose to tackle this conundrum? How are you handling it at the
moment?

– Bob

Postscript

Another option that comes to mind is mob programming a.k.a. mobbing, particularly with the involvement of folks having in-depth domain knowledge (i.e. customers and users).

Please Don’t Irk Me with Fast Arguments

I love Twitter for its ability to facilitate conversations over time and space. Recently, I have found myself feeling irked by a style of conversation which I could describe – and have described – as “cargo-culted argument”. In other words, arguments attempting to promote a position based on widely-held existing beliefs and ideas (and where the arguer appears have not thought through that belief).

“A great many people think they are thinking when they are merely rearranging their prejudices.”

~ William James

Socratic Questions

I find Socratic questioning to be useful when mutually exploring a topic or question (my preferred mode of conversation). In using Socratic questioning I seek to invite parties to the conversation to reflect on and think about the issue afresh. Occasionally, however, one party will choose to repeat “conventional wisdom” on the topic, without, seemingly, pausing for said reflection. I say “choose”, but I wonder how much of a conscious choice it is. We humans are creatures of habit, not least when it comes to thinking.

I feel saddened on such occasions, when we miss the opportunity for deeper mutual exploration of a topic (and thereby a deepening of our relationship or Twitter connection).

“No problem can withstand the assault of sustained thinking.”

~ Voltaire

Fast Arguments – or Slow?

Kahneman writes about this phenomenon in his book “Thinking, Fast and Slow”. He describes Slow (system 2) thinking as the kind of reflective, conscious, consider-things-afresh thinking Socratic questions invite, whereas we all prefer to default to what he labels as Fast (system 1) thinking, which so often, in this context, leads to a simple regurgitation of conventional wisdom.

Would you be willing to set aside your Fast arguments in favour of a more Slow exploration of topics of conversation?

– Bob

Further Reading

Thinking, Fast and Slow ~ Daniel Kahneman

 

The Folks That Matter™

Stakeholders, team members, the Big Team, customers, users – call them what you will, they’re the people that we’re doing the work for. They’re the people to whom we deliver the fruits of our efforts. They’re the people whose reactions – and emotional responses – decide the success or failure of our endeavours.

Personally I like to call them The Folks That Matter™.

By way of example, Here’s a partial list of the groups and individuals that are candidates for inclusion in the set of The Folks That Matter™.

  • Your organisation’s Core Group
  • Your manager
  • Your project manager
  • Senior managers and executives
  • Your dev team
  • Other dev teams
  • Ops people
  • The PMO
  • Testers (when separate from the dev team)
  • QA folks (when present)
  • The Process Group (when separate from the dev teams)
  • Your business sponsor(s)
  • Other people across your organisation
  • Your (end) customer(s) (and their purchasing departments)
  • Commercial partners
  • Regulators
  • Wider Society
  • The Planet (Gaia)

The Interesting Angle

For me, when I’m involved building stuff, I have a need know who we’re trying to please, delight, satisfy, or otherwise engage with and deliver to. I need to know what folks need, and who to ask about the details of those needs, if and when the detail moves to front of mind. I need to know whose needs we can successfully discount when the inevitable resource (time, money, effort) crunches come. Whose needs we can reasonably consider as outside the scope of the endeavour in which we’re involved? And I need some heuristics to guide us in decisions on including, excluding and prioritising folks and their needs.

But there’s something much more interesting than who’s on and who’s off the list of The Folks That Matter™, at any given time. The much more interesting question for me, as an Organisational Psychotherapist, is: What governs the choices? How do folks get added to or removed from the set of The Folks That Matter™? Are the means the product of rational thought, discussion and evolution, or maybe they’ve just happened, or been cargo-culted. And what are the consequences of the prevailing means? What impact do those means have on the success or failure of our endeavours? And therefore on our bottom line?

By way of example, here’s some common means for tackling the question of means:

  • Consensus
  • The Advice Process
  • Autocracy
  • Dictatorship
  • HiPPO
  • Cost of Focus

(Aside: Each collective mindset in the Marshall Model has its own popular choice for these “means”: Autocracy for the Ad-hoc, Dictatorship or HiPPO for the Analytic, Consensus or the Advice Process for the Synergistic, and e.g. Cost of Focus for the Chaordic).

Is it helpful for folks on the dev team to be involved in some way in maintaining or keeping the list of the The Folks That Matter™? Is that possible, in any given organisation? Is the question even discussable?

When Resources Are Limited, Some Folks, Needs, HAVE To Not Matter

And what about the folks that don’t matter (that don’t appear in the set of The Folks That Matter™? I know many readers will baulk at the idea that some folks and their needs don’t matter. But, please, get over yourselves. In any situation where resources are constrained (i.e finite, not infinite), choice HAVE to be made. Lines drawn. Resources committed to some areas and held back or withdrawn from others. How could it be otherwise? Inevitably then, in this particular frame, there must be Folks Who Don’t Matter™.

Cost of Focus

Don Reinertsen states that the Cost of Delay – the financial or economic cost of prioritising one feature over another – is rarely considered in most organisations. Put another way, the way in which delivery priorities are selected and adjusted, the frequency and means of such adjustments, etc., are rarely discussed, and rarely even discussable.

I propose that Cost of Delay is a subset of the wider question stated above. The question of Cost of Focus.

By definition, we are not meeting some needs when we choose to or otherwise exclude certain folks with their particular needs from the set of The Folks That Matter™.

Maybe those excluded folks and their needs are indeed irrelevant, or their exclusion has little impact – financial or otherwise – on the success of our endeavour. But maybe, contrariwise, some of those excluded needs are in fact critical to our “success”. How would we know? The arguments for Cost of Focus are much the same as for its golden child, Cost of Delay.

FWIW, I’ve seen countless projects stumble and “fail” because they inadvertently omitted, or chose to omit, some crucial folks and their needs from the their list of The Folks That Matter™. Get Cost of Delay wrong, and we lose some money. Sometime a little, sometime a lot. Get Cost of Focus wrong, and we more often lose big time. Cost of Focus often has a much more binary impact.

What is Cost of Focus?

Cost of Focus is a way of communicating the impact, on the outcomes we hope to achieve, arising from excluding or including specific folks and their needs. More formally, it is the partial derivative of the total expected value with respect to whose needs we focus on.

“Cost of Delay is the golden key that unlocks many doors. It has an astonishing power to totally transform the mind-set of a development organisation.”

– Donald G. Reinertsen

Similarly, I’d say that unless and until we have a handle on Cost of Focus, the golden key of Cost Of Delay remains firmly beyond our grasp.

Put another way, until we have a means for deciding whose needs to attend to, the particular order in which we attend to those needs (cf. priority, Cost of Delay) is moot.

– Bob

Further Reading

Who Really Matters ~ Art Kleiner

The Marshall Plan

I guess most people, when they start a new job or client engagement, have in mind the things they want to do and see happen. Most likely, things they’ve seen or made happen in previous jobs or engagements. Along with, maybe, some things they’ve read or heard about and are minded to try out, given the opportunity. (And what better opportunity than the honeymoon period of a new job or client?)

We might choose to call this an agenda.

My Agenda

I’m no different, excepting perhaps the items that feature on my agenda:

  • Invite participation in discussing “who matters?” (with respect to i.e. the work and the way it works)
  • Empathise with the emergent community of “folks that matter” (not exclusively, but as a priority)
  • Invite folks to listen to each other’s volunteered observations, hear each other’s feelings, and explore each other’s needs.
  • Invite folks to solicit and then begin attending to each other’s requests (explicit and implicit)
  • Offer and provide support to folks and communities in their journeys

Note: I’ve not included on my agenda anything about specific actions that I myself might want to do and see happen, beyond the items listed. Specifically, although I’ve written often about strategies such as Flowchain, Prod•gnosis, Rightshifting, the Marshall Model, self-organising/managing teams, the quality of interpersonal relationships and interactions, etc., I don’t bring these into my agenda. If folks discover these strategies for themselves, they’re much more likely to understand their fundamentals, and maybe come up with even more effective strategies.

The Antimatter Principle is the only strategy I’ve regularly written about that recognisably features on my prospective agenda, and then only by extending invitations to participate in that strategy. (Note: Attentive readers may just notice the tip of the Organisational Psychotherapy iceberg peeking out from the above agenda).

I’ve reached a point in my journey where, keen as my ego is to see all my ideas (strategies) made manifest, my experience tells me that’s not the way to go for the best outcomes for the community as a whole.

As for the Marshall Plan, I believe it’s best, in the longer run, to have the folks involved (in particular, the people that matter) do their own discovery and learning. Discovering for themselves, over time – through means they also discover for themselves – effective strategies for attending to folks’ needs (often including the principles underlying those strategies). I see my role in this Plan as supporting – in whichever ways folks request, or say they need – this collective endeavour. Such support quite possibly to include actively helping the discovery and learning, whenever there’s an explicit (albeit refusable) request for me to do so.

– Bob

Further Reading

The Benefits of Self-directed Learning

Difficult Conversations

Before this turns into a mini-series, I’d just like to add one observation to my previous two posts.

Setting aside the outcomes sought by the people that matter, outcomes related to the business and its needs, there’s the not inconsequential matter of the unexpressed outcomes sought by these folks with respect to their own personal needs. Often, these needs are not discussed, shared or even registered at a conscious level by the individuals concerned. And often, then, explicit outcomes have yet to be identified – both by them and by us.

There’s not much point addressing the needs of the organisation (see my previous post) without also attempting, at least, to address the needs of the individual people that matter. This asks of us more effort, because we’re likely to be starting “further back”, before these folks have even expressed their personal sought outcomes. And because they may be reluctant to get into these kinds of conversations, being unusual in a workplace context. And then there’s the difficulty involved in “speaking to power” or at least empathising with people in positions of power.

Examples

Some examples may help clarify this observation.

Senior managers and executives, in articulating the sought outcomes listed previously, may also want to control the solutions chosen, hence their providing solutions in the form of wants. Often there’s an underlying need to feel “in control”, driven by some need, such as their need for order, or personal safety, or kudos.

Similarly, articulating their sought outcomes may, in part, derive from their need for tangible progress, or a need to be seen as the driver of that progress.

Summary

Entering into, and sharing the exploration of these often intensely personal topics is certainly difficult. But that difficulty can ease when we have the right conditions – such as trust, friendship, skill, and safety. And without such conversations, we’re that much more likely to spend much time and effort on delivering outcomes that no one really needs, or worse – that actively work against folks’ needs.

– Bob

Further Reading

Crucial Conversations ~ Patterson & Grenny
Difficult Conversations: How to Discuss What Matters Most ~ Patton, Stone, Heen & Fisher
Discussing the Undiscussable ~ Bill Noonan
Feelings Inventory ~ List at the Centre For Nonviolent Communication
Needs Inventory ~ List at the Centre For Nonviolent Communication

Wants, Needs

My previous post seems to have struck a chord, judging by the number of retweets on Twitter. It also presents an opportunity to explore a perennial challenge of building things for other people: teasing out real needs from expressed wants.

Have you ever worked with business folks who articulate their wants in the form of solutions, rather than as solution-free “requirements”? As means rather than ends?

Let’s take another look at the list of desired outcomes (wants) appearing in the aforementioned post:

  • A more coherent, disciplined approach to software development
  • Improved governance and oversight
  • Improved estimates
  • Better due-date performance (reliable on-time delivery)
  • More visibility into project roadmaps
  • Common standards
  • Better project organisation
  • People working “in sync”
  • Senior management confidence (in e.g. the teams’ ability to deliver)
  • Higher staff motivation and engagement

Business Analysis for the Way the Work Works

From my days as a Business Analyst, I’ve learned that uncovering needs means having an ongoing dialogue with the people that matter. A dialogue in which we dig down, together, into the things they say they want, so as to uncover their real needs. Once we’ve teased apart the wants from the needs, we’re in a better place to choose effective strategies (solutions) for addressing those needs. Going with the superficial wants tends to box us in to the strategies (means) they provide. Strategies which often fall short of being effective.

I suspect what I’m talking about will become clearer as we examine in turn each item from the above list…

Item: A more coherent, disciplined approach to software development

This looks to me like a solution masquerading as a need. That’s to say “a more coherent, disciplined approach” seems like more like means to other ends, than and end in itself. What might those ends be? What might be the underlying needs driving this proposed solution? A dialogue with the people that matter seems in order here. A dialogue that could prove challenging, absent a degree of trust and willing collaboration. And even assuming we are all able to dig down towards the underlying needs, just as in building software there’s no guarantee we’ve identified those needs accurately, until we’ve built and delivered something and seen it “in production” long enough to gather some feedback. Active feedback, which also implies iteration and evolution: “Is this really meeting the needs of everyone that matters? Is it good enough yet? What else do we need to do to improve it further?” etc..

For illustration, I’ll take a stab at the needs which might underlie this want. Maybe some folks suppose that “a more coherent, disciplined approach” will bring order to the present chaos (a need for order). Maybe some folks suppose that “a more coherent, disciplined approach” will make delivery of e.g. features or product increments more predictable (a need for predictability).

Maybe productive and effective dialogue will uncover other latent needs implicit in this want.

Item: Improved governance and oversight

This also looks to me like a solution masquerading as a need.

Maybe some folks choose “Improved governance and oversight” as their automatic, default solution (strategy) for bring order to the present chaos (a need for order).

Item: Improved estimates

This again looks to me like a solution masquerading as a need.The No Estimates movement and debate has just about done this one to death. What might the supposed need for “improved estimates” imply. What’s really need here?

Item: Better due-date performance (reliable on-time delivery)

Whilst we could imagine this as yet another solution masquerading as a need, in this case I find this want more interesting, maybe closer to a real need than the previous two items.

I suspect some folks that matter may suppose that “better due date performance” is the obvious means to improve (external) customer satisfaction, and thereby revenue, repeat business, profit, market demand, market share, and other business metrics. Maybe those involved in the way the work works, armed with an explicit, agreed need to satisfy one or more specific business metrics, would be able to come up with ways of working which effectively address those metrics. In other words, valuable innovations.

Item: More visibility into project roadmaps

This again looks to me like a solution masquerading as a need. What might be the underlying need here? Maybe it’s something born of a feeling of powerlessness in the absence of information about what’s happening. Maybe it comes from a sense of frustration or embarrassment when having to face customers and investors expecting information about product release schedules, feature sets, and road maps. Whatever the case, an effective, productive dialogue may flush out some of those underlying feelings, and thereby lead to a better understanding of the needs we’re all trying to address.

Item: Common standards

Yet again this looks to me like a solution masquerading as a need. I’ve heard this want many times in numerous companies. This looks to me like an implicit solution to the question “how do we become more flexible, how can we cost-effectively deploy and redeploy our developers between projects and project teams as business priorities change?” I guess the people that matter suppose that “common standards” is the obvious answer. But it’s our job to understand the underlying need and come up with the most effective solution (strategy) for addressing it, not just the most common solution.

But I could be barking up the wrong tree about the presumed underlying need here, so I’d want to have conversations with the people that matter so as to really understand what they might be trying to achieve through addressing this want.

Item: Better project organisation

Another solution masquerading as a need. What might “better project organisation” bring us? Better due date performance? More visibility into project roadmaps and current status? See explanations, above, for the needs which might underlie *those* wants.

Item: People working “in sync”

Solution masquerading as a need. What might “people working in sync” bring us? Reduction in friction and waste? Improved flow (of products and features into the market)? Better due date performance? By digging down, though dialogue, we may uncover candidates for the underlying needs, which we can proceed to validate through delivering a way the work works, and getting feedback on the degree to which that way of working effectively addresses folks’ real needs.

Item: Senior management confidence (in e.g. the teams’ ability to deliver)

This is probably the one item in our list of sought outcomes that’s closest to a real need. We can intuit the scale of the problem (shortfall in senior management confidence) by looking at all the solutions they’re helpfully trying to provide us with, via the other items here. Solutions (masquerading as needs) that they believe will improve things and thereby deliver the boost in confidence they seek (and need). Ironically, the solutions they provide – being very much less effective solutions than those we can come up with for them, as experts – often undermine the very outcomes they seek.

Item: Higher staff motivation and engagement

Very laudable. But let’s not let the humanity of this want blind us to its nature as (yet another) solution masquerading as a need. What’s the end in mind? Why might the people that matter seek “higher staff motivation and engagement”?

So they can feel better about the culture for which they they feel responsible? As a means to increased throughput and thus improved revenues and profits? Again, until we know what they really need, any solutions we provide will likely fall well short of the mark. In other words, wasted effort.

Summary

So, we can see that taking “sought outcomes” at face value can lead us into sleepwalking into addressing superficial wants, and adopting other people’s (non-expert, relatively ineffective) solutions. Solutions which rate poorly on the effectiveness scale, and which in any case may well be addressing the wrong needs. I find it ironic just how much non-expert interference and micromanagement goes unnoticed, unchallenged and unlamented. Plenty of time for lamentation a year or two later.

Bottom line: When building software, the biggest risk lies in building the wrong thing (getting the requirements wrong), and it’s not any less of a risk when “building” – we might choose to call it “evolving” or even “engineering” – the way the work works.

– Bob

A Hiding To Nothing

Most large companies are on a hiding to nothing if and when they decide they’re “going Agile” for software development. “Going Agile” can only ever deliver the outcomes these companies seek if the whole organisation is prepared to change some of its fundamental beliefs about how organisations should be run.

Sought Outcomes

What outcomes do larger compares typically seek from “going Agile” in their software development teams? Here’s a partial list:

  • A more coherent, disciplined approach to software development
  • Improved governance and oversight
  • Improved estimates
  • Better due-date performance (reliable on-time delivery)
  • More visibility into project roadmaps
  • Common standards
  • Better project organisation
  • People working “in sync”
  • Senior management confidence (in e.g. the teams’ ability to deliver)
  • Higher staff motivation and engagement
  • Shorter timescales (i.e. “from concept to cash”)

Why These Outcomes Are Unrealisable

What’s not to like in the outcomes these companies seek by “going Agile”? Although maybe not comprehensive – they lack, for example, outcomes like “joy in work”, “folks getting their needs met”, “improved flow” and “customer delight” – there’s a bunch of stuff here I could get behind.

Setting aside the observation that some of the above “outcomes” – such as “common standards” and “people working in sync” – are more solutions than needs, “going Agile”, per se, is not the answer for delivering these outcomes. At least, not within the Analytic mindset world view.

Why the Analytic Mindset is the Blocker

With an implicit Theory-X, local optima (manage the parts separately) perspective, any and all solutions attempting to deiver these outcomes through “going Agile” are doomed to undermine the very outcomes sought.

It’s likely to start well, with much interest and hope expressed by the staff. After all, who wouldn’t want more autonomy, more mastery, more purpose in their work? But as things progress, existing company policies, rules, attitudes, etc. will begin to assert themselves. To the detriment of staff morale, motivation and engagement. Pretty soon, staff will begin to question the sincerity of the management in their support for “going Agile”. Pretty soon, it will start to become apparent to anyone who’s paying attention that existing policies, rules, etc., have to change fundamentally to see the outcomes sought begin to happen.

And with declining staff engagement in “going Agile”, and reducing enthusiasm for understanding the principles necessary for making Agile successful, progress will slow to a crawl. At this point, middle-management, who have to carry the burden of making “going Agile” happen will also begin, quietly, to question the wisdom of the senior management direction. This will lead to their more often reverting to orthodox, “tried and tested” (and less personally burdensome) ways of working. And more often baulking at the effort needed to push through adoption of more Agile practices.

What To Do?

So, what’s a company to do? Most companies will not realise, or want to hear, that the Analytic mindset is fundamentally incompatible with successfully “going Agile”. So, another Agile adoption failure is in the making.

Personally, having helped various companies face up to this challenge, I’d say:

“It’s extremely unlikely that you’ll want – or even be able – to give up your existing world view. At least in the short term. So something’s got to give. And it’s probably better that you give up on “going Agile”. But DON’T give up on wanting things to be better. Park your Agile aspirations, and try another path, another solution. After all, it’s the OUTCOMES you seek that matter, not some specific – and cargo-culted – solution.”

So what might that alternative solution look like? What can an unrepentantly Analytic-minded organisation do to improve its software development outcomes?

My recommendation would be to focus on the interpersonal relationships within and between departments. Help developers understand and relate to customers (both internal and external) better. Help other folks within the organisation better understand and relate to developers.

Leveraging these improving relationships, encourage multi-party, cross-function dialogue about the outcomes sought, and what folks of every stripe can do, every day, to begin to shift the organisation’s rules, policies, structures and assumptions.

In a nutshell, be less autocratic, directive and strategic, and more democratic, collegiate and opportunistic.

And remember, I’m here to help.

– Bob

Beyond the Pale

Digital transformations, Agile adoptions, shifts in collective mindset, Marshall Model transitions and the like general proceed slowly, if at all. Why might this be? What slows or blocks the implementation of more effective ways working, more effective ways of meeting folks needs?

I have found that one of the biggest drags on implementing more effective strategies for getting folks’ needs met is the sheer inconceivability of the new strategies. Literally. unthinkable. And not only are these prospective, more effective ways of doing things inconceivable, they’re often also unmentionable, undiscussable and taboo, too.

Some Examples

Here’s a list of some of the kinds of new strategies I’m talking about:

  • Using throughput accounting rather than cost accounting
  • Delivering value as defined by the customer, rather than the supplier
  • Defect prevention as a preferred alternative to testing
  • Favouring slack and flow over utilisation and busywork
  • Recruiting with humanity (conversations) rather than relying on CVs
  • Funding new product initiatives incrementally rather than with a one-off budget allocation
  • Incrementally trialling new product ideas in the market rather than one time “big launch”
  • Attending to folks’ needs rather than acting as if we know what’s best for others
  • Self-managing and self-organising teams
  • Having teams “own” the product they’re working on, rather than a separate Product Owner
  • Reducing or eliminating the command & control aspects of middle management roles
  • Theory Y over theory X
  • Adopting team-wide measures rather than measuring individuals
  • Seeing people as emotional and social rather than logical and rational
  • Eliminating extrinsic motivators in favour of cultivating intrinsic motivations
  • Adopting whole systems measures rather than local measures
  • Managing and optimising the whole business rather than managing and optimising each part
  • Having folks set their own salaries and bonuses, rather than have remuneration decided by others

And so on…

Promise Unrealised

Each of the above strategies promises to contribute to a more effective business, yet each of them is in itself often inconceivable, unacceptable, unthinkable and even undiscussable. In short, such new strategies are, at a given point in time, considered as beyond the pale.

The First Challenge

When considering Digital transformations, Agile adoptions, Marshall Model transitions and the like, our collective challenge, then, is to progressively broaden and deepen our tolerance and enthusiasm for discussing and embracing these new strategies.To move ourselves to a point where one, some or all of these new strategies is conceivable, discussable and acceptable. Only then can we begin to think about build a true consensus on a specific way forward.

And maybe organisational psychotherapy has a role to play in helping the organisation open itself up and start thinking and then talking about these “tough topics”.

– Bob

Further Reading

Discussing the Undiscussable ~ Bill Noonan
Crucial Conversations ~ Kerry Patterson et al.
Six Ways To Open Up and Talk in Therapy ~ John M. Grohol Psy.D. (article)

Obstacles to True Consensus – Summary

[Tl;Dr: Major improvements in the effectiveness of any organisation go begging, because the skills and experience for reaching the necessary True Consensus are almost always absent.]

This is the final post in my recent mini-series about obstacles to True Consensus.

The Big Picture

Let’s step back and try to take in the big picture for a moment.

I most often label this big picture “Organisational Effectiveness”. You might prefer to call it “improving the bottom-line”, “productivity”, or simply “success”.

Why does this big picture matter to me? Because of the impact ineffective organisations have on the people who work in them, on the people who depend on their products and services, and on society as a whole.

Employees

I’m a software engineer at heart. I have so many times worked with software engineers and other folks wanting to make a difference in the world, and being unable to do so because of the ineffectiveness of the organisations within which they work. Sooner or later, these folks simply give up on their dreams and “check out” (remaining employed but disengaged) or quit. Having been in the same boat myself on any number of occasions, I feel like I can relate. And, BTW, that’s why I now serve organisations in the role of Organisational Psychotherapist, actually doing things – albeit non-software engineering things – to “make a difference”.

Customers

I’m a customer of these organisations, too. We all are. Not out of choice, let me add. I have in mind the various organs of state, in which we have no say regarding the shoddy services and lame products they foist on us. Not that most private corporations are much better.

Society

How do ineffective organisations impact society? Apart from the waste of public money (many are in the public sector) that could be put to better use elsewhere, the sheer number of ineffective organisations lead us all to believe that ineffectiveness is normal and unavoidable. We seem to have lost the belief that we can ever expect to see things become better.

The Key to Improved Effectiveness

It’s pretty much accepted that the ability to transcend paradigms (an organisation’s beliefs, assumptions and rules about work) is the greatest lever to improve effectiveness. And by effectiveness, I mean reducing or eliminating things that should not have been done but nevertheless were done. See my recent post: Reliability and Effectiveness for details and objective measures of this.

In other words, the prevailing paradigm, or mindset or memeplex governing an organisation determines its effectiveness. And so, it’s obvious that to improve effectiveness, we must “shift” this paradigm. This is where most organisations falter and fail. They have no experience or capability in achieving a True Consensus. Such a thing looks like an impossibility.

Aside: Agile

In case you’re wondering if there’s any relevance to tech companies and their employees and customers: All flavours of Agile are essentially forms of local optima. Local optima, in that Agile initiatives are almost always limited to one silo (the “development” or “IT” silo) in the organisation. Most people in organisations doing software development are obliged to place their faith in systems of local optima. This is because the prospect of building a True Consensus across the whole organisation seems so daunting, so impossible, so contrary to prevailing behaviours, as to never receive serious consideration or discussion. And so, systemic ineffectiveness is locked in.

True Consensus

A “True Consensus” is when ALL top managers agree on the exact SAME action plan, with each and every top manager regarding his or her components of the joint action plan as his or her own baby.

Whether in a single organisation, or society as a whole, True Consensus is a prerequisite for concerted action to make things better, to make things more effective. On the path towards effective organisations, progress will only come about if the top teams, and eventually their whole organisations, can agree on their core problems and find coherent, holistic ways forward, together. True Consensus is the necessary prerequisite for Rightshifting any organisation.

This mini-series and its precursors has described one path to arrive at such a True Consensus, including describing the obstacles we can expect to encounter along the way, and ways of overcoming those obstacles.

In brief, the described path consists of repeatedly practicing, as a group and emergent leadership team, these steps:

  • understanding the core conflict in a problem by discovering the inherent flawed assumption
  • agreeing on a direction for a solution
  • elaborating that direction into a full (holistic, company-wide) solution or plan of action
  • agreeing on how to implement that full solution
  • enacting the implementation

You can find more details in the posts of this mini-series:

Obstacles to True Consensus – The Dominant Impatient Visionary

Obstacles to True Consensus – The Smart Conservative

Obstacles to True Consensus – Extrapolating From the Past

Obstacles to True Consensus – Solutioneering

Obstacles to True Consensus – Summary (this post)

and in the four posts prior to the mini-series itself:

Organisational Psychotherapy and the Bottom Line

Pillars

Innovation ALWAYS Demands We Change the Rules

Reliability and Effectiveness

And you can find even more in-depth elaboration of these ideas in e.g. Goldratt’s audiobook “Beyond The Goal”.

– Bob

Further Reading

Beyond the Goal ~ Eliyahu M. Goldratt (Audiobook only)
Leverage Points: Places to Intervene in a System ~ Donella Meadows
The Asch Conformity Experiment (Video)

Obstacles to True Consensus – Solutioneering

Following on from the third post in this mini-series, today I’ll describe another obstacle to True Consensus. Again, it’s about the behaviour of certain key people. And again, in line with our belief that “People are Good”, the behaviours we’re discussing are not dysfunctional behaviours, but the outstanding, positive behaviours that have brought the company to its present success.

The term “solutioneering” describes our natural tendency to jump to a solution, and elaborating that solution, even implementing something, before we fully understand the problem at hand.

Obstacle: Solutioneering

If we think about solutions while we are analysing a core problem, we will distort reality to fit the solution we have in our mind.

And at the time we’re creating the solution, any time we spend on thinking about how we’ll implement it will distort the solution, too.

In other words, we’ll come up with better solutions, and implement them better, when we tackle any candidate idea in clearly delineated and separated steps:

  1. Analyse the core problem. Simply understand the problem, and the underlying core conflict.
  2. Find the solution
  3. Decide how to implement the solution

You may recognise this approach as the Three Fundamental Questions of Theory of Constraints.

1. What to change?
2. What to change to?
3. How to effect the change?

At each step, we forbid ourselves from considerations better reserved to the other steps. Given the risk of confusion, delusion, distortion, and ineffective conversations, we must maintain the separation between these steps. Absent such separation, the risks of conflating these concerns means we will be that much less likely to achieve our essential True Consensus.

Next time: Summary – Summarising this mini-series.

– Bob

Further Reading

Beyond the Goal ~ Eliyahu M. Goldratt (Audiobook only)
Theory of Constraints: What to Change ~ Dave Lane (blog post)

Obstacles to True Consensus – Extrapolating From the Past

Following on from the second post in this mini-series, today I’ll describe another obstacle to True Consensus. Again, it’s about the behaviour of certain key people. And again, in line with our belief that “People are Good”, the behaviours we’re discussing are not dysfunctional behaviours, but the outstanding, positive behaviours that have brought the company to its present success.

Extrapolating from the past is not something negative, it’s something positive. If we don’t extrapolate from the past, if we start every time from a clean slate, what are the chances we’ll do anything sensible? Pretty close to zero. Experienced people are, by definition, people that extrapolate from the past. Otherwise we have no intuition, no insights into a subject.

Here, we’re going to look at two different aspects of this obstacle.

Obstacle: Extrapolating From the Past Into What We Might Do In the Future

This is the first aspect of extrapolating from the past. Extrapolating from the past works in our favour. So what’s the problem with it? When we come to build the change, to build the new strategy based on our new rules, to really embrace the power of the synergistic approach, our past contains what? Yup. The old rules. And if we extrapolate from the old rules, what do we get? We get the same strategy we already have – maybe in slightly different words only – and nothing happens.

Remediation: Exclude the old rules

So, how can we make sure we extrapolate from the past, building everything on past experience, except for the old rules. How can we exclude these old rules? By examining each conflict, by identifying our flawed assumptions- rooted in the old rules – and removing these flawed assumption. In this way, we make our past experience more homogeneous, and everything makes much more sense. We’re not abandoning the past. We’re not erasing our past experience. Exactly the opposite. We’ve removed the one thing that causes our experience to be inconsistent. And we’re reshaping our past experience. Making it much clearer and more palatable. Folks love this.

So what we have to do is take a number of key ideas in turn, and apply the same process:

  • Do the analysis
  • Discover the conflict via the flawed assumption
  • Remove the conflict

By doing this, we reshape our past experience. And the minute we do this, we still extrapolate from our past experience, but based on the new rules, rather than the old rules.

And by the way, did you notice how, for this aspect of the obstacle, remediation is much the same approach as we take with the Dominant Impatient Visionary and the Smart Conservative obstacles?

Obstacle: Extrapolating From Past Experience of Each Other

This is the second aspect of extrapolating from the past. Given our experience of the folks we work with, will they collaborate now? Do they really mean yes when they say yes? Can we rely on them? In most companies, extrapolating from the past in this context leads to less than positive feelings, because what we extrapolate from the past is not exactly flattering.

Remediation: Explore, Reflect and Change as a Group

How to remediate? We have to ensure that we reflect on the past, on our past interactions, on our extrapolations of folks’ behaviours, as a group, rather than in one-to-one conversations. In this way, each person will see how everyone else is also going through the same kind of change. This means, by the way, that all the previous remediations we have mentioned in this series also have to be done in a group, not one-to-one.

Aside: This excludes people learning this stuff from books. People have lost the art of reading together in groups.

Next time: Solutioneering – the final obstacle to True Consensus, explored.

– Bob

Further Reading

Beyond the Goal ~ Eliyahu M. Goldratt (Audiobook only)

Obstacles to True Consensus – The Smart Conservative

Following on from the first post in this mini-series, today I’ll describe another obstacle to True Consensus. Again, it’s about the behaviour of certain key people.  And again, in line with our belief that “People are Good”, the behaviours we’re discussing are not dysfunctional behaviours, but the outstanding, positive behaviours, the virtues, that have taken the company to its present success.

Obstacle: The (Smart) Conservative

Usually, these are people with an enormous amount of experience, very well respected. But somehow, given any suggestion of what to improve, they immediately find ways to prove to you it should not be done. It’s as if they’re going out of their way to maintain the status quo. Do you know anyone like this? What can we do?

As long as these people are in the crowd – and they’re always in the management crowd – what chance do we have of reaching a true consensus on some idea, or way forward, that is beyond the expectation of almost anyone in the group? It’s not that these conservative people are stupid. Definitely not. Do you think that they’re out of touch with reality? That they don’t know the situation of the company? Of course they know. And very well.

And now if we talk with them and ask them “What do you think? Do you think that if the company fails to embark on a process of ongoing improvement, it will survive in the future? What do you think their answer might be? They thoroughly believe that if we DON’T improve, we’re going to be out of business. So how come that these people – with so much experience, with such strong convictions that the company must improve – block any suggestion for improvement? What are they, imbeciles? How it is that this happens?

Here’s the explanation: These smart conservative people have the gift of being able to see both sides of a conflict. Very clearly. As a matter of fact, when we, through analysis, cause them at last to see the core problem, they will tell us “We already know that. We have already spoken out about it, more than once.” And they really believe the problem exists, and the analysis is correct. They have seen both sides of the conflict. They are keenly aware of both sides of the conflict. But do you see what’s happening? Most suggestions for improvement that they have seen in their careers, the vast majority, anyway, are not solutions or improvements that remove the conflict, they are solutions based on movement on the conflict arrow. To give an example of what we mean by “movement on the conflict arrow” consider the bi-annual flip-flop in many companies; from centralisation, to decentralisation, and back again to centralisation. Each time this movement was presented as “THE thing that will save the company” So many huge and expensive reorganisations. Each time, these smart conservative people oppose such initiatives.

Why? They’ve already seen solutions based on movement on the conflict arrow. They have learned from experience that the ONLY thing that will happen in such cases is the substituting one set of undesirable effects for another set of equally undesirable effects. And if that’s what people want to do, better not to do anything. ”Thank you – we have seen it before, we’ve been there already, why should we try the same thing again?”

Remediation: Block Movement on the Conflict Arrow, Identify and Remove the Flawed Assumption

How then do we cause these conservative folks to move towards our true consensus? Let’s present some new ideas, and for each one show the core problem, the conflict. To begin with they will not be surprised. They know the problems already. But then we show them that we have no intention whatsoever to move on the conflict arrow. More than that, we show that we propose blocking any movement on the conflict arrow, because it would be just substituting one set of undesirable effects with another.

Instead, we highlight the flawed assumption within the conflict. We don’t say ”we have a solution”, but rather “we have a direction for a solution”. In other words, our direction is based on the knowledge that we have found one (or more) flawed assumptions. So now we proceed to the next step: creating the full solution. In Theory of Constraints, the full solution emerges from the creation of a Future Reality Tree.

Yes, But

The Future Reality Tree leverages the remarkable ability of people, especial smart, conservative people, to say “Yes, but…”. Usually, a small yes, and a big BUT…

So, rather than attacking these “yes, but” reservations, we embrace the gift within every “yes, but”: “Yes, I understand the solution, yes, it will remove the conflict, BUT it will create another issue…”.

We help as much as we can to meticulously document the cause and effect of the “but”. We go out of our way to do this, to clarify their reservation. Once we have articulated really clearly what’s bothering someone, their reservation will augment our solution by removing the “but”. In this way we arrive at a full solution. With each reservation making that solution simpler, more powerful, and more intense.

And we ourselves learn the value of taking the time to listen to and clarify folks’ reservations.

Repeating this approach three or four time with a smart conservative person, they begin to realise that we are even more paranoid than they are. In a good way.

As soon as these folks understand our intentions, our rigour in dealing with risks, they become our champions and biggest supporters. In most cases the biggest supporter of True Consensus and all the changes it implies is the CFO.

This is how to remediate the obstacle of the smart conservative.

And by the way, did you notice how it’s much the same approach as we take with the Dominant Impatient Visionary?

Next time: Extrapolating From the Past – another obstacle to True Consensus explored.

– Bob

Further Reading

Beyond the Goal ~ Eliyahu M. Goldratt (Audiobook only)

 

%d bloggers like this: