Kent Beck’s Paint Drip People

PaintDrip22

I repeat Kent Beck’s “Paint Drip People” article here for the benefit of all those having trouble finding or accessing it, or just hate having anything to do with Faceberks.

Keith Adams worked on kernels at VM Ware. Then virtual machines. Then search performance at Facebook. Then the HHVM implementation of PHP. Then machine learning. Now he’s Chief Architect at Slack. In between he worked on hundreds of little projects that lasted hours or days or weeks. Keith is a Paint Drip Person.

I was a big fan of the T model of skills, introduced by David Guest in 1991: know about a lot of things, be really good at one. The more I taught it, the more unhappy I got with the metaphor:

  • Skilled people are good at several things.
  • Skilled people’s interests develop over time.
  • Skilled people don’t plan their next focus area. Sometimes it seems completely unrelated to their previous focus area.
  • Skilled people are always exploring, just for the sake of curiosity.
  • Skilled people resurrect interests sometimes.

All of these metaphor fails led me to the paint drip model of skills.

  • You draw a brush across the top of the canvas.
  • Sometimes enough paint accumulates that a drip starts to roll.
  • Once a drip starts to roll, it’s not clear how far it will go.
  • You keep drawing the brush across the canvas, regardless.

“Moving the brush” is the curious exploration. Keith reports that he tries a project a week or so, but that most “don’t go anywhere” (I beg to differ). The drip rolling down is an area of specialization. Once it starts rolling, it’s not clear how far it will go. In any case, the brush keeps moving. Eventually the last drip stops and a new one starts.

Lost Business

At Familiar (1996-2000) we regularly “lost” work to other companies making lower bids than us. Like many suppliers we were initially both angry, frustrated and disappointed when this happened.

Over time, we studied the phenomenon, saw a pattern emerge, and came to understand these scenarios.

Years later, I wrote a blog post – The Inductive Deductive Schism – explaining the phenomenon of clients commissioning software development work with suppliers who were clearly going to screw up and cost the client much more over the full duration of the commission.

The Schism Summarised

In summary, non-technical, non-engineering clients approach decision-making – i.e. who to commission – in entirely the reverse order to how technical, engineering people might approach the same decision. The follow chart illustrates the order in which clients might approach the question:

 

Note how trust (actually credibility of the supplier) takes first place, followed by solution fit, and then details of the solution. “Will the proposed solution work?” comes a poor fourth.

Compare with the approach favoured by “technical” people:

Here, the viability of the proposed solution takes first place, and “trust” a.k.a. credibility of the supplier comes fourth.

Bottom Line

So we see that technical suppliers who fail to understand the decision order of their prospective (non-technical) clients will inevitable fail to understand why the commissions go to suppliers who appear inept and likely to produce inappropriate and/or non-viable solutions.

If you’re a “technical” supplier pitching for business with non-technical clients, you might like to focus on your credibility, followed by the “fit” of your proposed solution to the client’s needs – and downplay the details and viability of your proposed solution.

– Bob

Two Suits, No Hoots

Two suits stood in the aisle of the busy open-plan office.

“These people really are dumb,” John said, “even whisper ‘the bottom line’ and they all jump to it.”

“Yup. No one realises that us managers are in it for ourselves, not the bottom line,” Ralph said.

John smiled. “Sure thing. Wouldn’t do to have them find out, though.”

“No problem. They’ve been so brainwashed by life that even if we shouted our self-interest, they’d not believe it.”

John raised his thumb. “Safe, then.”

Ralph grinned.

Where’s the flaw in John and Ralph’s assumptions and beliefs?

– Bob

Further Reading

Your REAL Job ~ Think Different blog post

Changing Culture

Let’s say you’re driving along in your car, and you want to change your speed. Would you grab hold of the speedo needle and bend it, expecting the car to change speed accordingly?

Of course not. Yet this is how organisations often attempt to change their “culture”. Grab hold of the culture “needle”, bend it and expect the culture to change.

Like the car speedometer, culture is just a visual indicator instrument, a read-only device.

To actually change the speed of the car requires an understanding of how the throttle pedal controls the amount of air/fuel mixture entering the engine, how the engine is connected via the transmission to the wheels, and how the rotational speed of the wheels (minus tyre/road slip) dictates the speed of the vehicle. More simply, an understanding of how one’s right foot on the throttle controls the speed of the car, not the needle on the speedo.

Similarly with organisations, controlling the culture invites an understanding of how changing assumptions and beliefs (gas pedal) changes the culture, not bending the culture “needle”.

– Bob

Awesomely Powerful New Ideas

Most organisations are very closed to new ideas about management (amongst other topics). Tech organisations are no exception in this regard.

Ideas that are new, or alien, come with a price tag of uncertainty and fear.

Uncertainty – will these ideas work for us?
And fear – what long-established rules will we have to change to make them work for us?

The ideas themselves are often as old as the hills. But for various reasons don’t make it past the motte and bailey of the organisations that could benefit from them.

BTW Through organisational psychotherapy, I help tech organisations open themselves up to awesomely powerful new ideas.

Here are just a few of the ideas with awesome potential benefits to adopting organisations:

  • Agile Software Development ~ Beck, Gilb, et al.
  • Compassionomics ~ Trzeciak
  • Idealized Design ~ Ackoff
  • Interactive Planning ~ Ackoff
  • Lean ~ Ohno, Liker, Ward, Kennedy, Rother, et al. Incl Lean product development, lean software development
  • Learning Organisations ~ Senge, Kleiner
  • Metrics ~ Fenton, Gilb, et al.
  • Organisational Excellence ~ Shingo, Juran, Peters
  • Psychology ~ Deming, Schwartz, Ohno
  • Quantification ~ Gilb
  • Risk Management ~ DeMarco, Lister, et al.
  • Statistical Process Control ~ Shewhart, Deming, Juran
  • Systems Thinking ~ Ackoff, Deming, Seddon
  • Tameflow ~ Tendon
  • Theory of Constraints ~ Goldratt
  • Throughput Accounting ~ Goldratt, Corbett
  • Value Streams ~ Rother, Shook, et al.
  • Variation ~ Deming, Tribus
  • OODA Loop ~ Boyd
  • Auftragstaktik ~ von Clausewitz
  • Toyota TPS and TPDS ~ Ohno, Shingo, Toyota et al.

And some of mine:

  • Rightshifting
  • The Marshall Model
  • FlowChain
  • Product Aikido
  • Prod•gnosis
  • Flow•gnosis
  • Emotioneering
  • The Antimatter Principle
  • Organisational Psychotherapy
  • Covalence
  • Javelin

Adoption is all.

How are YOU going about opening up YOUR organisation to awesomely powerful new ideas?

– Bob

5x Productivity

People ask me where does the 5x uplift in productivity come from when software development is done right. It’s not one factor, but a combination of a bunch of factors that together cause the uplift.

These factors include:

  • Motivated people. As we now know, forget extrinsic motivators – these only serve to reduce productivity in collaborative knowledge work. Intrinsic motivation’s the thing.
  • The social dynamic. This delivers the environment for employee wellbeing and organisational health – the environment in which joy emerges and intrinsic motivation can let rip.
  • Teaming.
  • Defect prevention. It’s more productive to prevent defects before they happen, than to find them after they have.
  • Change. Making experiments and finding new, better ways of doing things, on a regular basis.
  • Skilled dialogue. Understanding emergent problems and collaborating on quickly finding neat solutions requires people to talk with each other. Skilled dialogue has a part to play here.
  • Courage. Courage to attempt novel approaches. Courage to buck trends. Courage to speak up and tackle thorny issues.
  • Attending to folks’ needs. (Key impact: improved social dynamic).
  • Identifying all key Folks That Matter, and their critical needs. And then attending to those needs (and no others). “Maximising the amount of work NOT done.”
  • #NoSoftware. Writing as little software as possible. And minimising the cost of each component of a solution by intelligently selecting the appropriate solution tech (often, not software).
  • Quantification. Bringing clarity to all aspects of work by elimination confusion of qualitative terms by using quantification.
  • Structure. Uplift morale, engagement and discretionary effort with organisational structures – such as self-organising, self-managing teams and flat organisations – suited to collaborative knowledge work.
  • Physical environment. Having available a range of workspaces suited to the modalities of collaborative knowledge work.
  • Tooling. Provide tooling best suited to the work style and preferences of each individual.
  • Hiring for what matters. You know what matters, don’t you?
  • Relationships. See: Social dynamic.
  • Remuneration. Pay people enough that their living expenses are no issue for them. Don’t pay so much that you attract mercenaries. Ideally, give people agency to each decide their own personal wages, hours, places of work, terms and conditions, etc.
  • Treating people like trusted adults. See also: Social dynamic.
  • Flow. Focus on economies of flow, rather than e.g. economies of scale.
  • Failure demand. Reduce and then eliminate failure demand.
  • Shared purpose. Allow folks a real say in the purpose of the organisation. To invite buy-in and a sense of personal ownership.
  • Whole-systems thinking. Steer the organisation as a whole, not as compartmentalised subunits.
  • Monitor variation, uncover the causes and reduce or eliminate.
  • Learning. Invite people to develop themselves (and others). Provide support of all kinds for this.
  • Replacing “work” with “play” (Cf Schrage ~ Serious Play).
  • Building eustress, reducing or eliminating distress.
  • Identifying and managing risks, actively and continuously .
  • Reducing and eliminating conflicts – and the inevitable waste – caused by differing assumptions and beliefs about how work should work.
  • Technical skills and competencies. Yes, there is a place for having folks that know what they’re doing.
  • Working fewer hours. The Rule of Four: Four day weeks or 4 hour days.
  • Obliquity: Don’t chase productivity. 5x productivity comes from chasing the things that result in productivity. In fact, better to forget the notion of productivity entirely.
  • Measuring. By all means measure. But never measure individuals nor teams. Invite folks to identify what matters to the Folks That Matter, and invite them to come up with measures for those things.

What did I miss?

A long list, to be sure. But then, software development always has been a complex adaptive system. If you want simpler: just attend to folks’ needs.

– Bob

 

Culture Shift

Red hot volcano

The Power of Culture

Giants of industry swear by the power of organisational culture. They could all be mistaken, of course. But the sheer numbers suggest maybe they’re not.

Assuming they’re right, there’s two cases to consider:

Case One: Your organisation has exactly the culture it wants and needs to be totally awesome.

Case Two: Your organisation needs a shift in its culture to become totally awesome.

If case one applies, you’re good. Done and dusted. At least, until the environment (markets, customer demand, technology, society) changes. 

If case two applies, you can continue with that suboptimal culture, or do something about it. If you decide you need to do something, what will that be? How will you shift your culture?

– Bob

The Naming of Familiar

Familiar Limited was a Reading-based software house/consultancy that I started with a colleague in early 1997.

One question I regularly get asked is “How did the name ‘Familiar’ come about?”

I had thought I’d already answered this question, but upon looking for that explanation can’t find it. So here it is (for the record):

I’ve long favoured ambiguous or multi-meaning words (homonyms). We chose the name “Familiar” on that basis. Here’s the three meanings we sought to present:

Familiar as in: well-known, easily recognised.

Our approach to software development was way different to what clients had come to expect from software house suppliers. We were decidedly unfamiliar in our approach, but took pains to appear familiar and comforting from the point of view of our clients interacting and doing business with us.

Familiar as in: Of the Family

We used the family as the metaphor for structuring the company. “Family” were close-knit, and each had equity and a say in the running of the company. “Friends” were (only) a little less invested.

Familiar as in: Witch’s Familiar

What we did for our clients was, for them, largely indistinguishable from magic. Or at least, that was our aim. Our “magic”, our technology, was how we did things. In other words, channelling the Arthur C. Clarke quote:

“Any sufficiently advanced technology is indistinguishable from magic.”

~ Arthur C. Clarke

Note also the coquettish reverse “F” in the name, intended to evoke a quizzical, playful spirit (looking a bit like a question mark).

You might like to read my other posts about Familiar too, if this post has piqued your interest.

– Bob

That’s a Great Idea But…

We’ve all experienced it. Someone comes up with a great idea for doing something different, and better. Everyone agrees it’s a great idea, and better. And yet nothing happens. Nada. Zip.

How to explain this near-universal phenomenon?

Loss Aversion

I choose to looks at the phenomenon in terms of loss aversion (and its kissing cousin, the status quo bias).

We human beings have an outrageous number of cognitive biases. One of the most powerful of these biases is loss aversion. 

Loss Aversion and the Status Quo

“In a nutshell, loss aversion is an important aspect of everyday life. The idea suggests that people have a tendency to stick with what they have unless there is a good reason to switch. Loss aversion is a reflection of a general bias in human psychology (status quo bias) that make people resistant to change. So when we think about change we focus more on what we might lose rather than on what we might get.”

~ Shahram Heshmat Ph.D., Psychology Today 

The notion that losses loom larger than gains, originally formalised by Kahneman and Tversky (1979; Tversky & Kahneman, 1991; cf. Markowitz, 1952, p. 155), has proven to have tremendous explanatory power.

In addition to basic examples, loss aversion can help to explain a wide range of phenomena, including the sunk cost fallacy, the attraction effect, the compromise effect, anticipated and experienced regret, and the status quo bias.

Needs and Relatively Ineffective Strategies

In my work as an Organisational Psychotherapist, I see, daily, folks’ reluctance to give up on their “established” strategies for getting their needs met in favour of new strategies offering more effective means for seeing those needs met. Often, MUCH more effective means.

Where does loss aversion come into it? Loss aversion explains the hold these “established” strategies have over people. The promising new strategy may look attractive, but the fear of not getting their needs met (in case the new strategy doesn’t pan out) hugely outweighs the promise of the uplift in effectiveness from the new strategy, if adopted.

“One implication of loss aversion is that individuals have a strong tendency to remain at the status quo, because the disadvantages of leaving it loom larger than advantages.”

~ Daniel Kahneman (Kahneman 1991)

Conclusions

We fallible humans cling to our established strategies for seeing our needs met for fear of losing out if we choose a different strategy, almost no matter how attractive that new strategy may be.

For me, this goes a long way to explain “resistance to change” – which may more usefully be called “attachment to the status quo”.

Psychology and neuroscience offers some suggestions how to remediate loss aversion and status quo bias. I may explore these suggestions in a future post (given demand).

– Bob

Further Reading

Kahneman, D. (2011). Thinking, Fast and Slow. Farrar, Straus And Giroux.

Rick, S. (2011). Losses, Gains, and Brains: Neuroeconomics can help to answer open questions about loss aversion. Journal of Consumer Psychology, 21(4), 453–463. https://doi.org/10.1016/j.jcps.2010.04.004

Kahneman, D., Knetsch, J. L., & Thaler, R. H. (1991). Anomalies: The Endowment Effect, Loss Aversion, and Status Quo Bias. Journal of Economic Perspectives, 5(1), 193–206. https://doi.org/10.1257/jep.5.1.193

Rosenberg, M. B. (2015). Nonviolent Communication: A Language of Life. Puddledancer Press.

Memeology – Halfway Mark

My new organisational psychotherapy self-help book “Memeology – Surfacing And Reflecting on the Organisation’s Collective Assumptions and Beliefs” has now crested the halfway mark (52% complete)!

It’s definitely been a labour of love, but completion is now in sight.

The thing is, I first published way early (18% complete) both to give me an incentive to push along with it, and to open it up to feedback from readers.

I was thinking that while it was still relatively incomplete, folks would have more opportunity to help shape and form the contents (and structure too, maybe).

Incentive-wise, publishing early has been a boon. But feedback has been conspicuous by its absence. Hey ho.

Window of Opportunity

Just to let you know, I expect the book to be essentially complete in the next few weeks, so if you were intending to provide some actionable feedback, the window of opportunity is rapidly closing.

Feedback Requested

The kind of feedback I had, and have, in mind includes:

Memes

Do you see any missing memes? Ones that might beneficially augment the existing list?
Do you see any extraneous memes? Ones that could usefully be dropped?

Questions

For any given meme, do you note any additional question or questions that might contribute to an organisations’ discussions on that meme?
Have you come across any questions which seem unclear, ambiguous or partisan and might benefit from being reworded?

Structure

Does the structure of the book serve its purpose, or have you thought of a better structure?

Other

Any other things you’d add, drop, or change?

Testimonials

One other way you could really help me out is to send me a line or two that I can use as a testimonial, either on the LeanPub page or the back cover. Would you be willing to do that?

– Bob

Designing the Memeology Cover

I enjoy designing my own artwork and graphics for my blog posts, papers, articles, and books.

This is a short post about my design for the cover of my latest book “Memeology

The general style (size, fonts, layout, colours) follows that of my previous Organisational Psychotherapy book “Hearts over Diamonds”:

(Note: the gradient fills to the left and right margins helps the cover stand out from white backgrounds on sites like Leanpub.)

The cover for Memeology differs from Hearts Over Diamonds mainly in the central image.

The image is inspired by the ancient mystical diagrams (yantra) used in the Shri Vidya school of Hinduism. A yantra consists of nine interlocking triangles that surround a central point known as a bindu. These triangles represent the cosmos and the human body. Devotees of the Shri Yantra believe the symbol enables achieving of a higher level of consciousness, and that it confers the ability to create one’s own reality. Devotees also believe the Sri Yantra brings peace, harmony and good fortune.

I’ve adopted this image – created by myself – to stand for the natural beauty, harmony and love that I feel in regard to Organisational Psychotherapy. There’s also research suggesting the yantra helps “to bring its viewers to a more meditative state”. Appropriate, I think, for the idea of surfacing and reflecting on beliefs and assumptions.

In Sanskrit, the word “yantra” comes from the root word “yam,” which means “instrument” or “support,” and “tra,” derived from “trana,” meaning “release from bondage.” A yantra is an instrument or tool, for meditation and contemplation and supports spiritual liberation.

Shri Yantra

The Shri Yantra, called the “queen of yantras,” (rajayantra) is the symbol of the great divine mother principle, the source of all energy, power, and creativity.

The Triangles

In the Hindu tradition, the triangles of the yantra have specific associations:

Starting at the lowermost outer triangle and moving in a counterclockwise circle, these associations are: agitation, pursuit, attraction, delight, delusion, immobility, release, control, pleasure, intoxication, an accomplishment of desire, luxury, mantra, and the destruction of duality.

The next circle has the same sequence and direction, starting from the lowest triangle and moving counterclockwise. The first triangle is the giver of all accomplishments. Next is the giver of wealth. The third is the energy of activities that please all. Fourth is the bringer of all blessings. The fifth is the granter of all desires. Next is the remover of all suffering. The seventh is considered the appeaser of death. Eighth is the overcomer of all obstacles. Ninth is the bringer of beauty, and the tenth is the giver of all good fortune.

The ten smaller triangles in the third circle represent, beginning at the same, lowermost triangle and moving counterclockwise: omniscience, omnipotence, sovereignty, knowledge, destruction of all disease, unconditional support, vanquishment of all evils, protection, and the attainment of all desires. The fourth circle of triangles, again starting at the same point and moving counterclockwise, represent: sustaining, creating, dissolution, pleasure, pain, cold, heat, and the ability to choose action.

In the final inner space, the yogi or yogini visualises five arrows representing the world of the senses, a bow, representing the mind, a noose, representing attachment, and a stick, representing aversion. The central triangle is the giver of all perfection. In the middle of the central triangle is a Bindu, representing pure consciousness and the original state of being.

– Bob

 

The Path to Organisational Psychotherapy

Lots of people ask me a question about Organisational Psychotherapy along the following lines:

“Bob, you’re smart, insightful, brilliant, and with decades of experience in software development. How come you’ve ended up in the tiny corner of the world which you call Organisational Psychotherapy?”

Which is a very fair question. I’d like to explain…

Background

But first a little background.

I started my lifelong involvement with software development by teaching myself programming. I used to sneak into the CS classes at school, and sit at the back writing BASIC, COBOL and FORTRAN programs on the school’s dial-up equipment, whilst the rest of the class “learned” about word processing, spreadsheets and the like. In the holidays I’d tramp across London and sneak into the computer rooms at Queen Many Collage (University) and hack my way into their mainframe to teach myself more esoteric programming languages.

My early career involved much hands-on development, programming, analysis, design, etc.. I did a lot of work writing compilers, interpreters and the like.

After a few years I found people were more interested in me sharing my knowledge of how to write software, than in writing software for them.

Flip-flopping between delivering software and delivering advice on how best to write software suited me well. I allowed me to keep close to the gemba, yet get involved with the challenges of a wide range of developers and their managers.

The years passed. I set up a few businesses of my own along the way. Selling compilers. Supporting companies’ commercial software products. Doing the independent consulting thang. Providing software development management consulting. Starting and running a software house.

By the time I got to Sun Microsystems’ UK Java Center, I had seen the software development pain points of many different organisations. From both a technical and a management perspective. Indeed, these two perspectives had come to seem indivisibly intertwingled.

I spent more and more of my time looking into the whole-system phenomena I was seeing. Embracing and applying whole-system techniques such as Theory of Constraints, Systems Thinking, Lean Thinking, Deming, Gilb, etc..

Slowly it became apparent to me that the pain points of my clients were rarely if ever caused by lack of technical competencies. And almost exclusively caused by the way people interacted. (I never saw a project fail for lack of technical skills. I often saw projects fail because people couldn’t get along.)

By the early 2000s I had arrived at the working idea that it was the collective assumptions and beliefs of my clients that were causing the interpersonal rifts and dysfunctions, and the most direct source of their pain.

So to My Answer

Returning to the headline question. It became ever clearer to me that to address my clients’ software development pains, there would have to be some (major) shift in their collective assumptions and beliefs. I coined the term “Rightshifting” and built a bunch of collateral to illustrate the idea. Out of that seed grew the Marshall Model.

And yet the key question – how to shift an organisation’s collective assumptions and beliefs – remained.

Through conversations with friends and peers (thanks to all, you know who you are) I was able to focus on that key question. My starting point: were there any known fields addressing the idea of changing assumptions and beliefs? Of course there were. Primarily the field of psychotherapy. I embraced the notion and began studying psychotherapy. After a short while it seemed eminently feasible to leverage and repurpose the extensive research, and the many tools, of individual psychotherapy, to the domain of organisations and their collective assumptions and beliefs.

Summing Up

Organisational Psychotherapy provides an approach (the only approach I know of) to culture change in organisations – and to the surfacing of and reflecting on the memes of the collective mindset – the organisational psyche. And because I see the dire need for it, I continue.

– Bob

Further Reading

Marshall, R. W. (2019). Hearts over Diamonds. Falling Blossoms.
Marshall, R. W. (2021). Memeology. Falling Blossoms.
Richard Dawkins. (1976). The Selfish Gene. Oxford University Press.
Blackmore, S. J. (2000). The Meme Machine. Oxford University Press.
The Power of Memes. (2002, March 25). Dr Susan Blackmore. https://www.susanblackmore.uk/articles/the-power-of-memes/

 

Software Development at Scale

Scaled Agile – or scaling agile – seems like a hot potato at the moment. Here’s a few
thoughts:

Scaled Agile? Don’t. Just don’t. For GOD’S sake don’t.

Agile even at a small scale doesn’t work and scaling something that doesn’t work just leads to an even bigger mess that doesn’t work. Take a look at SAFe if you don’t believe it. Or just listen to Ackoff:

“The righter we do the wrong thing, the wronger we become. When we make a mistake doing the wrong thing and correct it, we become wronger. When we make a mistake doing the right thing and correct it, we become righter. Therefore, it is better to do the right thing wrong than the wrong thing right.”

Mindset (Obvs.)

Mindset (a.k.a. culture, memeplex) over methods, tools, etc.. What an organisation, collectively, believes and assumes has far more impact on e.g. productivity, quality, etc. than any methods or tools. See: Organisational Psychotherapy, the Marshall Model, and my new book, “Memeology“.

The only thing of real importance that leaders do is to create and manage culture. 

~ Edgar Schein

The thing I have learned at IBM is that culture is everything. It took me to age fifty-five to figure that out.

~ Lou Gerstner, CEO, IBM

If you get the culture right, most of the other stuff will just take care of itself.

~Tony Hsieh, CEO, Zappos.com

And Schein also provides us with a definition for “the culture of an organisation”:

Culture is the deeper level of basic assumptions and beliefs that are shared by members of an organisation, that operate unconsciously and define in a basic ‘taken for granted’ fashion an organisation’s view of its self and its environment…

It’s a pattern of shared basic assumptions invented, discovered, or developed by a given group.

~ Edgar Schein

Flow Efficiency

Goldratt wrote the book on Flow Efficiency (see “The Goal”, in case you’re interested).

Flow efficiency is miles better than resource efficiency (a.k.a. utilisation). What is flow efficiency? I’m sure you can look it up. But for the lazy: Flow efficiency suggest a focus on keeping work moving through its various value-adding steps, with minimal or zero queues and wait times, thereby attending to folks’ needs (value to the Folks That Matter) – and prompting feedback – as quickly as possible.

Formalise Innovation

Formalise innovation, evolve into continuous organisational transformation.

What do I mean by “innovation”?
In the context of organisations, here are a few possible definitions of “innovation”:

  •  A process by which a method, a product, or a service is renewed and refreshed by applying new ideas or introducing new techniques to create new value.
  • Turning an idea into a solution that adds value from the perspective of the folks that matter
  • A new strategy (means) for attending to the needs of the folks that matter.
  • The application of ideas that are novel and useful.
  • Staying relevant – keeping pace with changes to the (business) environment.
  • The implementation of something new – until it’s implemented it’s just an idea.
  • Stop talking about innovation. Focus on organisational transformation.

Here’s my preferred definition:

Innovation: Delivering against an idea which meets a specific set of needs, for all the Folks That Matter.

And “formalise”? What the hell does that mean, exactly? In effect, institute trainings, standard work, measures, etc., around the whole innovation (and, a.s.a.p., organisational transformation) piece.

I’ve been brief here to avoid a rant. Do get in touch if you’d like me to elaborate on some of these themes.

– Bob

Memeology First Look

Memeologyv1.1-FrontCover

You may be interested to hear that I just published the first release of my new book entitled “Memeology”, today, on LeanPub.

Foreword by John Seddon

I am indebted to John Seddon both for his support and for his kind contribution to the book in the form of its foreword.

Overview

Following on from my foundational Organisational Psychotherapy book “Hearts over Diamonds”, available as an ebook at both LeanPub and Apple Books, and in dead tree format via Lulu.com, I’m writing “Memeology” as a self-help book for organisations who may be chary of engaging with an organisational psychotherapist directly.

Organisational Psychotherapy promises a major uplift in organisational performance, and my idea with Memeology is that supporting a self-help approach makes Organisational Psychotherapy accessible to a wider range of organisations, and promises similar tangible and bottom-line benefits to the therapist-assisted approach.

Organisational “Culture” and Organisational Psychotherapy

Many people seem confused about the idea of “Organisational Culture”. Even to the extend of asserting that an organisation’s “culture” is not amenable to intervention and explicit, intentional change.

Organisational Psychotherapy’s perspective is that “culture” is a read-only shadow, or reflection, of an organisation’s collective assumptions and beliefs. Thusly, even though an organisation’s culture is not directly amenable to change, its collective assumptions and beliefs are amenable to change, and Organisational Psychotherapy offers the means to do so.

Origins and Content

I’ve been a practicing organisational psychotherapist for more than a decade now. Organisational Psychotherapy arose from my discontent with more established ways of intervening in organisations, for example consulting, and coaching. During my years as consultant and coach, I never felt the client was getting much value for money, nor were they likely to sustain the changes I introduced, beyond the close of my association with the organisation.

Memeology is my attempt to package my decade-plus experience as an organisational psychotherapist in a form that organisations can use on their own. Only time will tell whether a self-help approach will find favour and gain traction.

Incidentally, I guess Memeology might also serve aspiring organisational psychotherapists as a reference work.

Administrivia

Early Release

I’ve chosen to publish the first release at a heart-stopping 18% (rough guesstimate) complete, both to solicit feedback, allow readers to steer the evolution of the books, and encourage myself to continue working on it.

Free Sample

As with many LeanPub books, there’s a free sample containing much of the early chapters of Memeology. You might like to take a look before committing to buy. To access the free sample just go to the Memeology LeanPub page and click on the “Read Free Sample” button to the lower right of the book cover image.

Free Updates

In line with the ethos of LeanPub, I’m publishing with the book significantly incomplete. But it’s worth remembering that Leanpub offers free updates for the lifetime of the book. So every time I update the book you can download the updated version.

Please Tell Your Friends

I’m grateful to everyone who might be willing to put the word about about this book. And the icing on the cake would be a review on your blog or social media feed. Thanks in advance for that. 🙂

Pricing

I’ve priced the book at GBP £39.99, which at current exchange rates works out at USD $56.59. I’ve chosen this price to reflect the value the book delivers to its intended audience (executives, senior managers, middle managers and employees all). Organisational Psychotherapy promises a major uplift in organisational performance, and a self-help version – this book – promises similar tangible and bottom-line benefits. It’s less a book to read from cover to cover, and more a reference work, guide, or set of coursework/exercises, akin to e.g. the Fifth Discipline Fieldbook.

Some dear readers will not begrudge the price even for the first release, and even though there is, as yet, precious little “meat” on the bones (the Memes of Part III). For those more undecided, I’ll just remind you of the Leanpub 45-day 100% happiness guarantee.

I believe the book, even as-is (i.e. the first release), provides good value for money, with its seventy-plus memes (note: the free sample, available via a button on the Leanpub Memeology page, only lists some nine of the full set of memes).

Future Releases

I intend to continue working on the incomplete sections of the book, and making interim release as Memeology continues to evolve and grow. You can help me immensely both by providing feedback, and by requesting new content you’d like to see included in the book. You can also help, of course, by supporting my work through purchasing a copy of the book. 🙂

The most valuable kind of feedback will be from folks that get to use the book in the manner intended, either as part of their practice or with their peers in the workplace.

Formats

The LeanPub version of Memeology offers pdf and epub formats at present, and these formats will continue in future releases. When the book is significantly closer to completion, I’ll take a look at providing e.g. Apple Books (ebook) and Lulu (dead tree) versions. Maybe even a MOBI format, too (useful to you?). I’d be happy to publish sooner in these additional formats if there’s sufficient demand. Let me know!

I hope you find some inspiration and utility in the book, and in Organisational Psychotherapy more generally.

– Bob

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

 

Ambitious

Ever since I can remember, it’s been my ambition to make a difference to the software industry at large. And not just do a good job for individual clients or employers.

I work with clients – and occasionally, employers – to help them, of course. But my main focus is on better understanding the domain of software development at the organisational and industry level, and to share that understanding with as many folks as are interested.

Don Quixote

I accept it’s a largely – if not entirely – quixotic ambition. And yet individuals have occasionally made a difference in other domains.

“Never doubt that a small group of thoughtful, committed citizens can change the world; indeed, it’s the only thing that ever has.”

~ Margaret Mead

Self-aggrandisement, kudos or fame is not my aim. Rather, even early in my career, I saw the frustration and suffering of fellow developers in positions of powerlessness, writing software that rarely if ever saw the light of day, rarely if ever making it into the hands of users, rarely if ever pleasing the folks for whom the software was intended. And having to cope with endless, senseless handicaps to getting anything done.

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

~ Peter Drucker

Even back then I was determined to do what I could to alleviate folks’ frustrations. To increase the likelihood of the fruits of their labours making it into “production”. Most developers I’ve ever met have shown a strong urge – we might say need, even – to make a positive difference in the world, albeit mostly through software features or products.

What could be more quixotic than wanting to help developers (and more recently, other software folks, such as managers and executives) who seem to not want to help themselves?

– Bob

Oblivious

It’s long been my belief that the whole software industry could be doing so much better than it is doing, and so much better than it has been doing for the past fifty years and more.

In that belief is where my work on Rightshifting, and the Marshall Model, originated, some fifteen years ago now.And continues today.

In my travels I’ve seen countless organisations, groups and individuals demonstrate an oblivious disregard for the potential for significant improvement. I say oblivious because there’s almost no one in the industry with knowledge of or even a vision for how great things could be.

Oblivious

According to the Merriam Webster dictionary, “oblivious” originally meant “characterised by forgetfulness”. Perhaps those in the software industry today have forgotten what previous generations, long since retired, once knew about effective software development. Or perhaps folks have just never known.

I hear some readers wonder: “is it obliviousness, or just ignorance?”. Given current usage “lacking active conscious knowledge or awareness”, I myself wonder about the roots of the phenomenon.

Through my work, in particular at Familiar, and through study of the positive deviants (outliers) in the industry, I have come to see the scope of possible improvement, and the means thereto, too.

Aside: Positive deviants include SSE (Denmark), Forward Engineering (London, UK), Lockheed Martin, and in slightly different spaces, Toyota, Semco, and Buurtzorg. ISBSG also has much confirming data.

Scope

Data (e.g. ISBSG) shows there’s a x2, x3, x4, even x5 scope for improvement in organisation-wide effectiveness of software-led organisations.

I’m regularly struck by the obliviousness of folks to this scope for improvement. To misquote R Buckminster Fuller:

“You cannot question an oversight you do not know you have made”

Causes

Whether the Software Crisis is a thing – or even was ever a thing – or not, it’s clear to me that software organisations woefully underdeliver vs their potential.

Why is this? I largely attribute it to folks of all stripes being oblivious to the scope for improvement. Whence this obliviousness? I’m guessing now, but I guess it’s down to either a lack of curiosity, or to fear of the wholesale changes to organisational assumptions and beliefs necessary to realise the potential on offer.

Fear

It’s become clear to me over the years that management has to fundamentally change, or even disappear – in the form we have known it – before we see the untapped potential of software businesses begin to be realised. And folks in the industry who may be in a position to effect such change fear for their jobs and careers. As Machiavelli, oft-quoted, wrote:

“It must be remembered that there is nothing more difficult to plan, more doubtful of success, nor more dangerous to manage than a new system. For the initiator has the enmity of all who would profit by the preservation of the old institution and merely lukewarm defenders in those who gain by the new ones.”

Paradigms

Thomas Kuhn, in his book “The Structure of Scientific Revolutions” asserts that science advances vis “paradigm shifts”. Donella Meadows makes much the same assertion with her “12 leverage points of change”.

I posit we’ll not see a widespread uptick in the effectiveness of software organisations, nor in the effectiveness of the software industry as a whole, unless and until the existing paradigm (primarily the prevailing management paradigm) changes.

Interested readers may wonder how, if, and when this might happen. I have some ideas on this, which I’ve set down in numerous posts here on this blog.

– Bob

Postscript

I know that neither data, nor rational argument convinces, nor moves the needle on action. With this post, I only hope to invite some few folks in a position to take action to become a little curious.

Further Reading

The Power of Positive Deviance: How Unlikely Innovators Solve the World’s Toughest Problems ~ Pascale, Sternin and Sternin
All Executives Are Unethical ~ FlowchainSensei (Falling Blossoms White Paper)
The Structure of Scientific Revolutions ~ Thomas Kuhn

An Overabundance of Planning

“The minimum you can get away with is always far less than you think you need.”

~ @FlowchainSensei

A Common Objection

“We’d be inundated if we attended to even a fraction of all the needs of all the Folks that Matter” is one common objection I regularly hear to the Antimatter Principle.

And yet, in most software development projects, the team is inundated with things to do, based on “the Plan” – regardless of whether that’s a big up-front plan, or an incremental plan (running backlog) assembled by degrees over time. A mountain of work (features, tasks, etc.) stretching out to the misty blue horizon, and back to the dawn of (project) time.

Research (see, for example, Capers Jones’ book “Assessment and Control of Software Risks”) highlights that much of what gets planned, and thus gets done, is pointless and proves unnecessary when (finally) made available to users. This reality is also reflected in the now highly controversial series of CHAOS reports from the Standish Group.

Specious

So, I regard the aforementioned objection as specious. Not intentionally so, most often. But specious never the less.

For me, “Attending to Folks Needs” means doing the least (responsibly) possible, and then seeing if the need (or a need) of the folks in question has been met. Most often those need(s) will not have been entirely met – and maybe not even partially – but the team then has the option to have another go – based on some solid information.

This approach has at least two benefits:

  • The person (customer, user, etc.) in question will feel that they matter, that their opinion counts, and that the team is focussed on them as a human being.
  • The team will have solid information upon which to validate or invalidate their earlier guesses (and yes, they will always be guesses until so validated).

At some point, it’s likely all the critical needs of all the Folks That Matter will have been met. And that point will like have arrived much earlier that with more traditional approaches. And with reduced costs and effort.

– Bob

Afterword

Some readers may argue that the above approach looks a lot like Agile. In practice (sic) I see enough differences to reject that comparison. For a deeper insight into why, may I invite you to consider #NoSoftware.

Organisational Self-Therapy

[Note: I regard this post as incomplete. I’m publishing it now in the hope that getting some feedback will encourage me to finish it.]

For some years, DIY seemed all the rage. I’m not so sure that’s true in home decorating any more, but it does seem to be increasing in popularity in the therapy domain. Individual self-therapy seems like it’s become more popular and more acceptable, both.

I have for some time been thinking whether self-therapy for organisations might be possible, beneficial even. Maybe self-therapy would be a viable alternative to engaging a therapist?

In my Organisational Psychotherapy assignments to date, most of my engagement time with client organisations has been spent sitting in with them during their Business As Usual (BAU – meetings, conversations, lunches, etc.), observing their social dynamic and modes of interaction. Such observations lead me – as therapist – to find questions that I can share with the organisation, questions which invite reflection and discussion on e.g. unsurfaced assumptions and beliefs. (This being the essential practice of therapy, both organisational and other kinds). 

The Challenge

For any organisation, making space and time for group reflection can be problematic. In most organisations, folks struggle to find time for all their scheduled responsibilities, let alone more esoteric activities like reflection and discussion of assumptions and beliefs. On the face of it, where’s the point – where’s the value – in spending any time on such “esoteric” things?

Anyone who’s been following this blog for any length of time may know of my focus on organisational effectiveness. And my explanation for organisational effectiveness in terms of Rightshifting and the Marshall Model. [links] 

Observing clients during their BAU is all very well. It doesn’t take up any of their time and, aside from the marginal financial cost of having a therapist present, doesn’t detract from folks’ day jobs or the work of the organisation. 

But when it comes round to the therapist finding and putting questions to the organisation, there’s at least a couple of issues we face:

  1. Finding the time to get together (Organisational Psychotherapy invites group discussions) to listen to the questions and reflect and discuss them as a group.
  1. The disconnect (in time, attention) between the point of observation and the point of reflection and discussion.

So, I’m presently focused on ways to ameliorate the impact of these issues.

Addressing the Issues of Having a Therapist

Improvements on each of the above issues: 

  1. Integrating the asking of therapist’s questions into BAU (having the folks in the organisation ask themselves questions).
  2. Reducing or elimination the disconnect in time and attention between the point of observation and the point of reflection and discussion (integrating Organisational Psychotherapy into BAU whilst promoting useful group discussions and reflections).

It’s Good To Talk

As BT were wont to tell us: “It’s good to talk”.

But many organisations believe (or at least, assume) they don’t have time to talk. And certainly not the time for “talking for the sake of talking” (which is what many might regard talking in order to surface collective assumptions and beliefs – and then reflect on and discuss). That’s why Organisational Psychotherapy in practice takes place amongst the daily ebb and flow of regular meetings and conversations happening in the course of the organisation’s business-as-usual. No need to shoehorn off-sites or special meetings for the necessary conversations happen. Although off-sites and dedicated meetings can help, too. 

Leveraging Valuable Discussions

So, recently I’ve been thinking about means to stimulate group reflections and discussions, in the course of doing things that clearly have immediate business value. For example, many organisations spend (an inordinate, perhaps) amount of time and management attention on coming up with mission statements, visions statements, and the like.

In decreasing order of “unarguable value”:

Purpose

Most organisations spend at least some time, effort and management attention considering and communicating the “shared purpose” of the organisation. Indeed, the Mission Statement is a favoured format for this effort. This then feeds into PR, marketing, branding, positioning and other such MarComms activities. Aside: Simon Sinek describes this kind of thing in terms of the “Golden Circle”. https://www.youtube.com/watch?v=Jeg3lIK8lro

I’ve been involved in many such initiatives over the years, both with clients and my own companies. I’ve not, however, seen the agendas for such initiatives include time for examination and reflection on the organisations assumptions and beliefs. It’s almost as if the purpose existing in glorious isolation. “Here we are, this is our purpose, handed down from God (or the CEO)”. There’s obviously scope for reflecting on the assumptions and beliefs that underpin the announced Purpose, or Mission Statement. 

Effectiveness 

Most organisations spend at least some time, effort and management attention on becoming more effective. Most often, this resolves to question like “How to cut costs?”, “How to improve quality?”, “How can we increase our market share?” and so on.  Rarely, though, do such discussions “go meta” and delve into the roots of organisational effectiveness. If they did, though, we could imagine questions such as “What makes for an effective organisation?”, “What kinds of effectiveness are we seeking?“ and “Is effectiveness more than just a WIBNI?”

Agility

Generally, little time is spent on the question of “Let’s go Agile” and even less on what “Agile” means. Most often, the decision is a de facto edict from a HiPPO, handed down to the software folks as a fait accompli. 

Doctrine

[TBD]

Others

[TBD]

– Bob

Artefact Driven Delivery

My preference when approaching solution delivery (I use that term in preference to software delivery, because #NoSoftware) has for the past 25 years centred on artefacts as opposed to tasks. I’m not going to retread here the arguments in favour of the artefact as the unit of progress. This post covers the use of artefacts in incremental development environments, and lists the core artefacts we use in our approach to solution delivery.

Incremental Delivery

Delaying work on implementing and delivering a solution until we have fully defined the requirements, designs, etc., for that solution magnifies the Cost of Delay, defers feedback significantly, and inflates other risks too. Yet we don’t want to skip having clear requirements and designs, either.

The approach we adopted starting circa 1994 is to establish a set of standard artefacts, at the outset of work on each new solution. From Day One, these artefacts will be empty scaffolds, based on standard templates, each artefact being elaborated just-in-time, immediately in advance of their contents being needed for implementation and delivery purposes.

In this way, we avoid B*UF (e.g. Big Design Up Front, Big Requirements Up Front, etc.) and the delays and risks associated with a Big Bang approach.

Standard Artefacts

The following is a list of all the standard artefacts we create on Day One of the inception of each new solution on which we embark. Note that each artefact is based on a standard template, with, from the outset, little or no solution-specific content (i.e. empty).

  • Control Document
  • Articles of Understanding
  • Glossary of Terms
  • Statement of Purpose
  • Case for Action
  • Vision
  • Folks That Matter™ and their Needs
  • Risk Parade
  • Top Risks
  • Functional Requirements
  • Non-functional Requirements aka QQOs
  • Critical Success Factors
  • Feature Schedule
  • Quality Plan
  • Test Plan
  • Change Control
  • Cycle Plans
  • Cycle Reviews

Artefacts and Deliverables

We share some or all of the above artefacts with our clients (the folks on whose behalf we are developing solutions) continually, and at their request. These artefacts are available for sharing throughout the duration of the development. And serve as a running history of the endeavour, too. The deliverables of any solution (code, data, policies, documentation, configs, databases, etc.) augment these standard, evolving artefacts. Typically, a set of deliverables will fall out of the work according to some cadence or rhythm (for example, weekly or every two weeks).

Javelin

For a fuller (if rather dated) explanation of each particular artefact (some now carry slightly different names), see the Javelin white paper.

In a following post I’ll be showing how you might insinuate the Antimatter Principle into your existing approach to developing solutions, using the Artefact Driven Delivery approach.

– Bob

%d bloggers like this: