“Science is essentially an anarchic enterprise: theoretical anarchism is more humanitarian and more likely to encourage progress than its law-and-order alternatives.”
Quickie: Science is Anarchy
Leave a comment
Monthly Archives: August 2021
The Science of Memes
The Science of Memes
My new book, “Memeology” is grounded in the science of memes. A meme is replicator – a unit of cultural transmission, or a unit of imitation. The word is from a greek root – mimeme – abbreviated to “meme” so as to sound like “gene” – its genetic antecedent. Examples of memes include tunes, ideas, catch-phrases, clothes fashions, ways of making pots or software or of building arches.
The evolutionary biologist Richard Dawkins proposed the idea in his 1976 book “The Selfish Gene”, where he compared the ideas or information that flows from one individual to another with that of genetic traits conveyed by genes. By replication, mutation and natural selection, weak ideas die off while strong ideas survive, thrive and evolve.
“I think that a new kind of replicator has recently emerged. . . . It is staring us in the face. It is still in its infancy, still drifting clumsily about in its primeval soup, but already it is achieving evolutionary change at a rate which leaves the old gene panting far behind.
“The new soup is the soup of human [including business] culture. We need a name for the new replicator, a noun which conveys the idea of a unit of cultural transmission, or a unit of imitation. ‘Mimeme’ comes from a suitable Greek root, but I want a monosyllable that sounds a bit like ‘gene’. I hope my classicist friends will forgive me if I abbreviate mimeme to meme. If it is any consolation, it could alternatively be thought of as being related to ‘memory’, or to the French word même. It should be pronounced to rhyme with ‘cream’.
“Examples of memes are tunes, ideas, catch-phrases, clothes fashions, ways of making pots or of building arches. Just as genes propagate themselves in the gene pool by leaping from body to body via sperms or eggs, so memes propagate themselves in the meme pool by leaping from brain to brain, via a process which, in the broad sense, can be called imitation.”
~ Richard Dawkins
“The intriguing magic of memes has spread throughout the spaces occupied by digital technology and media. Behaviours and ideas copied from person to person by imitation – memes – may have forced human genes to make us what we are today.”
~ Susan Blackmore
Classical (Darwinian) evolutionary theory, which focuses on inheritable traits of organisms, cannot directly account for the riches of the human experience. Expressed in modern terms, Darwinian theory holds that genes control the traits of organisms; over the course of many generations, genes that give their bearers a survival advantage and that favour production of many offspring (who will inherit the genes) tend to proliferate at the expense of others. The genes, then, essentially compete against one another, and those that are most proficient at being passed to the next generation gradually prosper.
Human nature can be explained by evolutionary theory, but only when we consider evolving memes as well as genes.
The Challenge
The upshot of all the above points to the challenge in changing collective assumptions and beliefs – the memes – of an organisation. Which organisation has the time to wait on the vicissitudes of fate for memes to replicate and mutate, and for selection to kick in to weed out the weak mutations in favour of the strong ones? Indeed, can we rely on the “strong memes” to be of benefit to the organisation at all? There’s plenty of examples of “strong memes” being downright unhelpful to the host organisation. For example, stack ranking, or performance evaluations, or the power of extrinsic motivators (bonuses), or Theory-X. And yes, new memes can spread fast. It’s the excision of the old, oppositional memes locked in as they are to the prevailing memeplex that takes the time.
“Thinking memetically gives rise to a new vision of the world of organisations, one that, when you “get” it, transforms everything. From the meme’s-eye view, every human is a machine for making more memes—a vehicle for propagation, an opportunity for replication and a resource to compete for. We are neither the slaves of our genes nor rational free agents creating culture, art, science and technology for our own happiness. Instead we are part of a vast evolutionary process in which memes are the evolving replicators and we are the meme machines.”
~ Susan Blackmore
Are you aware of the memes swimming around inside your organisation? And the influence they have over every aspect of your working – and personal – lives?
– Bob
Further Reading
Marshall, R.W. (2021). Memeology: Surfacing the Memes of Your Organisation. Falling Blossoms.
Dawkins, R. (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/
Feyerabend, P. (2010). Against Method. Verso.
Quickie: HR Weenies
For the love of GOD why do companies place their futures in the hands of the HR weenies – the people least capable of appreciating talent, experience, ability, etc.?
Quickie: Educating People
Education is not something we do to people.
Quickie: Phil Crosby’s Four Absolutes of Quality
Phil’s 4 Absolutes are the building blocks or the foundation of any true quality improvement process that hopes to have a sustained improvement effort. These absolutes are very easy to understand and communicate compared to complex mathematical terms, and creating examples that relate to any industry—Service, Process, or Manufacturing—can be very easy. These 4 Absolutes are as follows:
1. The definition of quality is conformance to requirements, NOT “goodness”
This is a simple but specific way to define quality for everyone. It puts the onus on management to take the process of setting requirements seriously.
After setting requirements, management must insist they be met every time—not just most of the time! Phil’s point was that management had made employee and customer requirements negotiable, causing both employees and customers to wonder what they are working toward or buying. If, as an employer, you want employees to do “it” right the first time you have to tell them what “it” (the requirements) is. Some examples of requirements in service or manufacturing might be: a. Outfit a hotel room with one bar of soap and a bed made with clean sheets. b. Drill a hole 1 inch in diameter, plus or minus 1 ten thousandth of an inch. c. Land the airliner within the markings on the runway, plus or minus some variable. d. Build an automobile that will stop in about 80 feet, plus or minus some variable, when traveling at 40 miles per hour. e. Sell grocery items
2. The system that causes quality to happen is prevention, NOT inspection
Again, this is a simple but effective way to ensure that doing it right the first time happens every time. Usually, everyone understands the importance of prevention in their business and personal lives. In business, the primary method for ensuring quality used to be through inspection, which was not cost effective and allowed defective services and products to slip through to customers. Some personal and professional examples of prevention might be as follows: a. Get vaccinated to prevent getting the flu. b. Exercise to keep healthy and prevent many diseases. c. Attend school or training to qualify for a job. d. Conduct engineering design reviews to ensure that a part or an assembly can be successfully manufactured. e. Perform maintenance on aircraft to prevent failure.
3. The performance standard for quality is Zero Defects (ZD or ZeeDee), NOT “that’s close enough”
This simple standard encourages everyone to do it right the first time (DIRTFT)—or to change the requirements to what we and our customer can agree upon. Phil used the ZD standard to communicate the importance of requirements (even small ones) and to eliminate the idea that some number of errors is normal and acceptable. This does not mean perfection, because remember—most requirements have a tolerance of plus or minus the center of the requirement. ZD encourages a mindset of defect prevention instead of acceptable quality levels. Some examples of the performance standard of quality might be as follows:
a. When a pilot lands an airliner within all the requirements, he or she has achieved a ZD landing. Requirements include, among other things, having the correct flap settings and hitting the plus or minus spot on the marked runway, etc.
b. When a lawyer prepares for a case by reading enough data to develop and understand the needed strategy to defend his or her client, and then presents a winning defense, that is a ZD performance.
c. When an orthopedic surgeon torques the screws during a back fusion, and the variance can be no more than 12.2 plus or minus 5.0 kgf x cm, achieving that range is a ZD surgical process.
d. When police use radar guns that are correctly calibrated to plus or minus one mile per hour if the reader is stationary and plus or minus two miles per hour if the reader is moving, you get ZD performances.
e. When a machinist drills a hole for a component piece that might be 10 cm plus .015 cm and minus 0.0 cm, that means the piece can be larger by 10.015 cm, but not smaller. A ZD hole will be within that range.
4. The measurement of quality is the price of nonconformance (PONC), NOT indices
This measure looks for the cost of failure—when something is done incorrectly and does not meet the requirements. Typically, failure costs about 25 percent of your sales numbers! (PONC can also impact your personal life when you fail to comply with day-to-day requirements.) Most failure costs (PONC) are caused when management does not set achievable requirements and does not insist that all employees take requirements seriously. Some PONC examples might be as follows:
a. When an engine blows because you have failed to change the oil or perform other basic maintenance to insure smooth operation and high performance.
b. When a component must be reworked to the design requirements because the machinist has made an error.
c. When a hotel room is unclean, and the customer cancels his or her stay as a result.
d. When money is paid as the result of a lawsuit for noncompliance to an agreed-upon contract
e. When a builder or remodeler must redo work that does not meet the buyer’s requirements.
Excerpted from:
Merbler, K. (2021) The Entrepreneur Who Created A Business Camelot: Philip B. Crosby. Dominionhouse Publishing & Design, LLC. Kindle Edition.
Further Reading
Let’s be Honest
Let’s be Honest
Let’s be honest, honesty seems in pretty short supply in life, and especially in business.
Let’s be honest…
- It’s dangerous to speak one’s mind honestly.
- Most folks are more interested in holding down a job than in being honest about what’s going on.
- Being honest feels good, but has far more negative consequences than positive ones.
- The more senior the person, the more lip-service is paid to honesty.
- How often do you feel it necessary to hide what you’re doing, rather than honestly declaiming your actions?
- The smarter folks are, the more acute their capacity for self-deception.
- Character (as in “good character”) is lauded in public and ridiculed in private.
- You’re not going to risk commenting on this post, lest someone influential sees your honest opinon.
– Bob
Further Reading
Radical Candor ~ Kim Scott
Quickie: Personal Kanban
Person Kanban has two core principles:
- Make things visible.
- Limit work-in-progress (WIP).
What things might we best make visible? I’d suggest the Needsscape.
Quickie: Schein on Culture
“To discover the basic elements of a culture, one must either observe behavior for a very long time or get directly at the underlying values and assumptions that drive the perceptions and thoughts of the group members.”
~ Edgar Schein (1996)
Seen in: Emiliani, Bob. The Triumph of Classical Management Over Lean Management: How Tradition Prevails and What to Do About It (p. 30). Kindle Edition.
Note: Here, Schein supports the Organisational Psychotherapy view that culture is a (read-only) manifestation, or shadow, of an organisation’s collective assumptions, values and beliefs. See also: Hearts over Diamonds, Memeology.
Quickie: Womack on the Unacceptability of Lean
In a recent article, James P. Womack recounted the struggles that he experienced and admits that Lean has proven to be unacceptable to the leaders of large corporations (Womack, 2017):
“With regards to denial, we need to acknowledge that our efforts to dramatically transform large, mature organizations haven’t worked and aren’t going to work, even when these organizations encounter crises. I spent several years recently with CEOs of large enterprises and got them to sanction model lines for value streams to demonstrate what was possible. The results were strikingly positive, but the organizational immune reaction was immediate and crushing. Little lasting was achieved and I’ve moved on. I no longer expect ‘another Toyota’ to emerge in every mature industry.” (Bold in original)
This recognition is not unique to Womack and Jones.
From: Emiliani, Bob. The Triumph of Classical Management Over Lean Management: How Tradition Prevails and What to Do About It (p. 23). Kindle Edition.
Note: Much the same applies to Agile.
Quickie: Help
Most organisations are wayyy beyond help.
How To Predictably Deliver Great Software
How To Predictably Deliver Great Software
What is “Great Software“?
Great software is software that meets the needs of the Folks that Matter™. The more needs met, and the more comprehensive the coverage of all the Folks That Matter, the “greater” the software.
Aside: I invite you to consider how the Needsscape plays into the above definition.
Ironically, when we dig into the needs of all the Folks That Matter, we find that great software often means no software. Strange?
Further, we regularly find that the needs of the developers and ancillary development staff trump the needs of the users and other customers. So we get software, even though users and other customers rarely need it.
Predictability
Let’s assume for a moment that predictability (e.g. due date performance) is among the needs of some of the Folks That Matter. In this case, predictability is part of the “great” we were just talking about.
Predictability comes from anticipating and managing risks – actively, deliberately and competently. Formal approaches such as set-based concurrent engineering (SBCE) help manage the risk of finding oneself unable to bring a particular aspect of the solution to completion, for a variety of reasons. Identifying the Folks That Matter and their needs helps manage the risks involved in building the wrong thing, as does consideration of the Cost of Focus. Predictability demands we keep on top of all significant risks. (See: the All Holes in the Boat principle Cf. Gilb).
Approach
Know what needs you’re attending to. And whose.
This is not always possible, a priori. So identify as many of the Folks That Matter as you can (expect more to come to light as you proceed). Concurrently, investigate their needs through quickly delivering early exploratory things such as mock-ups, paper-prototypes, sketches of various kinds, and conversations. “Quickly” here means in a few hours, or days at most. Expect to have to iterate on this.
Many developers assume that someone else will be handing them a list of the Folks That Matter along with a definitive statement of the needs of those folks. If that other party is competent and sufficiently resourced, this can work. I’ve never seen it. I prefer to have the developers own this crucial information, and the gathering and updating thereof too. This is not popular in many organisations, shining a light as it does on the inadequacies of the way the work works, the management, the analysts, the product owner(s) and so on.
In parallel with these investigations, make a start on building the solution. In particular, those parts of the solutions which seem relatively stable, and where you feel the needs are relatively well understood. This can even involve writing some software – if you really must. Manage the risk of not knowing how to build certain things through e.g. “Spikes” and other risk mitigations.
Done
“Surely there’s more to it that this?’ I hear you ask.
Well, actually, no. We’ve been hoodwinked into thinking that software development is “the most complex endeavour known to man” ~ Jim McCarthy
Actually, if tackled appropriately it’s quite a pussy cat. People make it much more difficult than it really is. Will the industry ever grow up?
– Bob
Further Reading
Waltzing With Bears ~ Tom Demarco and Tim Lister
Sketching User Experiences ~ Bill Buxton
Principles of Software Engineering Management ~ Tom GIlb
Beyond Command and Control ~ John Seddon
First Think Different Weekly Tuesday Drop-in
First Think Different Weekly Tuesday Drop-in
For our first Think Different Tuesday drop-in, we covered the following topics:
Next Week
Next week, amongst other things, we might be looking at ways of setting salaries and salary ranges.
Feedback
For those who attended today: Would you be willing to answer two questions?:
1. How well did the Drop-in meet your needs today?
2. What might we change for next time to better attend to your needs?
Thanks for dropping-in! 🙂
– Bob
Quickie: Jobsworth?
What’s more important to you – doing your job or meeting folks’ needs?
Memeology For Developers
Memeology For Developers
“The greatest determinant of organisational performance is the way we think about the design and management of work.”
~ John Seddon
And, therefore, the greatest determinant of the performance of self-organising software development teams is the way those teams think about the design and management of their work.
Aside: For teams and individuals that are not self-organising, the original quotation pertains.
Memeology is For Whole Organisations, not Teams
I suspect many developers and development teams might see “Memeology” (my new book) as irrelevant to them. As a book that lists memes of little interest, and as a book that surfaces assumptions and beliefs more relevant to senior management – which, to be fair, is the books primary audience.
And yet, as organisational psychotherapy speaks to an organisation’s collective psyche, “Memeology” invites addressing of the collective assumptions and beliefs of everyone in the organisation. So, as far as involving people in the discussions around “Memeology”, I’d suggest encouraging everyone to become involved.
In most organisations, however, local rules apply. Different groups may well be interested in memes specific to their own specialisms. For example: Finance, Operations, Logistics, HR, and yes, Product and Software Development.
I’m chary of promoting local optimisations – for example, the improvement of software development practices in isolation from the rest of the organisation. But developers in Analytic-minded organisations outnumber by far those in Synergistic-minded organisations (the latter being more prone to taking system-wide issues into consideration). Are we to deny a self-help book such as “Memeology for Developers” on the grounds that discussing development-specific memes in isolation might perpetuate specialisms and concomitant local optimisations confined to the “development silo”?
Prospective Content
Here’s just a few of the many memes that “Memeology for Developers” might cover:
- Requirements (when to capture them, who’s responsible for such capture, formalisms and representations, etc.)
- Code ownership (individual, group, other, and the trade-offs and consequences)
- Defect tracking
- Performance (of the software when in production)
I have a long list of such memes. I’m sure you can suggest memes for such a list, too.
Question
Does the idea of “Memeology for Developers” pique your interest? Would it be a useful book, promoting as it would not only the surfacing and reflection on the assumptions and beliefs developers hold in common, but also promoting experimentation to improve self-organising software teams and the way they work?
I’d love to hear your thoughts.
– Bob
Quickie: Pay for Performance?
“The idea of removing ratings drives many HR executives a little crazy because companies love to quantify and analyze almost everything. The thought of getting rid of a metric is almost heretical. Executives who contacted us after reading our research often assumed that removing ratings was an anomaly, perhaps driven by smaller companies who don’t realize how important pay-for-performance is.”
Source: “Why More and More Companies Are Ditching Performance Ratings“.
Might benefit from understanding Deming’s 95:5?
The Rightshifting Cause
The Rightshifting Cause
[Here’s a post that’s been languishing in my “Drafts” folders for ten years now. It dates back to the time when I was just beginning to make my way into Organisational Psychotherapy, as a therapist. Not that I knew it then…]
The Agile Coaching Agenda
I used to to introduce myself to people as an Agile coach. Not anymore. Nowadays, I don’t really know what to introduce myself as. Here’s why.
The term ‘coaching’ is overloaded. There’s sports coaching, agile coaching, life coaching, business coaching and many others. All of them have things in common, but they’re not the same. As well as coaching, there’s mentoring, consulting, advising and whatnot. These terms are sometimes used interchangeably and sometimes they seem to overlap. I’m guessing I’m not the only one who’s had trouble differentiating between them.
Lately I’ve studied coaching with Results Coaching Systems. They have a very strict definition for coaching, which says coaching does not have an agenda. In coaching, according to their definition, the goals are always set by the person being coached. I’ve grown to like their definition of coaching.
However, this does raise a conflict. How can anyone (myself included) call themselves an agile coach if coaching shouldn’t have an agenda? Agile is an agenda. Agile is a solution that I – or my clients – are proposing. And coaching shouldn’t have an agenda. Calling anyone an agile coach actually starts to sound very contradictory if you see coaching as not having an agenda.
So I’ve started introducing myself as a software development coach. That’s more honest. Right? Well…
John Seddon has recently thrown more fuel into my existential fire with his talks. John is the father of Vanguard, a systems thinking approach for service organizations. One of his key points is that if the organization as a whole is doing the wrong things the significance of the method(s) used in its software development efforts is very small. He says “Agile is about doing the wrong things faster”. And I think I’m sure he has a point.
The fact that Agile revolves so much around software development has started to feel like a constraint. Like a sub-optimization. I’ve had this feeling for quite a while, but John seems to have reinforced it. This is also a discussion that has been on going in the Agile community for quite a while.
I would like to see myself as someone who looks at the whole. The whole organisation. The whole business. And of that whole, software development is only a small – mostly inconsequential – part. I want to help organizations do the right things with the right methods. Focusing on software development is not enough.
Thanks to John, even ‘software development coach’ feels weird. So what am I suppose to call myself now?
[Spoiler: As you may have noticed, I’ve come to describe myself as an Organisational Psychotherapist.]
– Bob
First Principles
First Principles
I was reading the other day about how Elon Musk “reasons from first principles“. And I was thinking, “Well, d’oh! Doesn’t everyone do that? I know I do.” And then, upon reflection, I thought, “Hmm, maybe most folks don’t do that.” I certainly have seen little evidence of it, compare to the evidence of folks reasoning by extension, and analogy. And failing to reason at all.
Now, allowing for journalistic hyperbole and the cult of the celebrity, there may just still be something in it.
So, in case you were wondering, and to remind myself, here’s some first principles underpinning the various things in my own portfolio of ideas and experiences:
The Antimatter Principle
The Antimatter Principle emerges from the following basic principles about us as people:
- All our actions and behaviours are simply consequent on trying to get our needs met.
- We are social animals and are driven to see other folks’ needs met, often even before our own.
- We humans have an innate sense of fairness which influences our every decision and action.
Flowchain
Flowchain emerges from the following basic principles concerning work and business:
- All commercial organisations – excepting, maybe, those busy milking their cash cows – are in the business of continually bringing new products, or at least new product features and upgrades, to market.
- When Cost of Delay is non-trivial, the speed of bringing new products and feature to market is significant.
- Flow (of value – not the Mihaly Csikszentmihaly kind of flow, here) offers the most likely means to minimise concept-to-cash time.
- Autonomy, mastery and shared purpose affords a means for people to find the intrinsic motivation to improve things (like flow).
- Building improvement into the way the work works increases the likelihood of having sufficient resources available to see improvement happen.
Prod•gnosis
Prod•gnosis emerges from the following basic principles concerning business operations:
- All commercial organisations – excepting, maybe, those busy milking their cash cows – are in the business of continually bringing new products, or at least new product features and upgrades, to market.
- Most new products are cobbled together via disjointed efforts crossing multiple organisational (silo) boundaries, and consequently incurring avoidable waste, rework, confusion and delays.
- The people with domain expertise in a particular product or service area are rarely, if ever, experts in building the operational value streams necessary to develop, sell and support those products and services.
Emotioneering
Emotioneering emerges from the following basic principles concerning products and product development:
- People buy things based on how they feel (their emotional responses to the things they’re considering buying). See: Buy•ology by Martin Lindstrøm.
- Product uptake (revenues, margins, etc.) can be improved by deliberately designing and building products for maximum positive emotional responses.
- Quantification serves to explicitly identify and clarify the emotional responses we wish to see our products and service evoke (Cf. “Competitive Engineeering” ~ Gilb).
Rightshifting
Rightshifting emerges from the following basic principles concerning work in organisations:
- The effectiveness of an organisation is a direct function of its collective assumptions and beliefs.
- Effectiveness is a general attribute, spanning all aspects of an organisation’s operations (i.e. not just applicable to product development).
The Marshall Model
The Marshall Model emerges from the following basic principles concerning work in organisations:
- Different organisations demonstrable hold widely differing shared assumptions and beliefs about the world of work and how work should work – one organisation from another.
- Understanding which collection of shared assumptions and beliefs is in play in a given organisation helps interventionists select the most effective form(s) of intervention. (Cf. The Dreyfus Model of Skills Acquisition).
Organisational Psychotherapy
Organisation psychotherapy emerges from the following basic principles concerning people and organisations:
- The effectiveness (performance, productivity, revenues, profitability, success, etc.) of any organisation is a direct function of its collective assumptions and beliefs about the world of work and how work should work.
- Organisations fall short of the ideal in being (un)able to shift their collective assumptions and beliefs to better align with their objectives (both explicit and implicit).
- Having support available – either by engaging organisational therapists, or via facilitated self-help – increases the likelihood of an organisation engaging in the surfacing, reflecting upon, and ultimately changing its collective assumptions and beliefs.
– Bob
Quickie: Why Agile is Irrelevant
The production process alone, the production system alone is not going to make a company successful, long term.
~ Bob Emiliani
Multiple Discovery
Multiple Discovery
It often seems that folks automatically assume that all useful software development innovations come out of the United States. And innovations (and innovators) from places other than the US have little merit. Yet specific innovations have a tendency to pop up, more or less simultaneously, in various places:
“The concept of multiple discovery (also known as simultaneous invention) is the hypothesis that most scientific discoveries and inventions are made independently and more or less simultaneously by multiple scientists and inventors. The concept of multiple discovery opposes a traditional view—the “heroic theory” of invention and discovery.”
~ Wikipedia
I rarely bother to mention Familiar’s independently inventing something very much like Scrum (we called it Jerid, now Javelin) back in the 1994-1996 time frame. Not inspired by Nonaka and Takeuchi’s New New Product Development Game, nevertheless Jerid featured:
- Two-week interations
- Time-boxing
- Sprint planning and sprint retrospectives
- Self-organising teams
- Focus (through e.g. quantification of objectives)
- A risk-based approach
- (Later on) Flow
I have no wish to tarnish or undermine Jeff and Ken’s achievements with Scrum. Nor the somewhat later accomplishments of the Snowbird folks. Just putting down a marker for us Brits. And other nations too.
Aside: The Lean manufacturing community has largely forgotten about Frank George Woolard, a Brit whose work preceded and some say inspired the Japanese, notably Eizi Toyoda.
– Bob
Further Reading
Don’t Look For Inventions Before Their Time ~ Matt Ridley
The Back Story – Finding a Lost Classic ~ Bob Emiliani
If Coaches Were More Like Therapists
If Coaches Were More Like Therapists
In retrospect, back when I was an Agile Coach, my style was always towards the therapy end of the stance spectrum (see table, below):
This did tend to rile management, most of whom seemed to think that a coach should be directive, more like a manager or project manager than anything else.
I guess many experienced Agile coaches would recognise part of their roles as working with the organisation as a whole, rather than their immediate team(s) and people.
Nowadays, in the role of Organisational Psychotherapist, I monitor my interactions for any signs of non-therapeutic coaching, and nip such things in the bud. When I can.
It’s pretty obvious I believe there’s more value in therapy than coaching, both other for my clients and myself. Put another way, in working with tech people, tech teams and tech organisations, I find Organisational Psychotherapy attends to folks’ needs better than coaching.
So, if coaching were more like therapy, what differences might we see?
- Less advising and guidance, and creating more opportunities for people to discover their own answers.
- Increased belief and trust that people are capable of taking responsibility for their work.
- A shift of focus away from technical skills and processes, towards quality of interactions and interpersonal, interdepartmental relationships.
- A change in practitioner:player ratios (therapists can serve more folks concurrently) with concomitant reduction in costs.
- A more enjoyable experience at work.
- Increased initiative-taking and innovation.
What difference might you expect to see if coaching were more like therapy? And would you expect to see any advantages in that?
– Bob
Think Different