Archive

Emotioneering

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

Automate All the Things!

Or not. I prefer not. 

As John Seddon states in his most recent book, it’s far more useful to fully understand customers’ needs, through e.g. simple physical means, like pin-boards, T-cards and spreadsheets, before considering any automation.

And even then, automation has at least two fundamental flaws:

Inability to Cater to Variation in Demand

Automation and automated systems, presently and for the foreseeable future, cannot encompass variety in demand. As we’ve come to relate to the Little Britain meme “ Computer says no”. Customer demand inherently has variation. Thus, automation leads to a poorer customer experience, as many customer needs are handled poorly, or not at all. I cite the British Gas website and customer experience as a particularly egregious example.

Employment 

Let’s also look at the bigger picture of social cohesion, of which people having jobs is a part. Jobs give people meaning, status, and something to do. As well as greasing the wheels of commerce – employed people have disposable income which contributes to companies’ revenues.

The idea of Basic Income is all very fine (I’m a fan) but that concept has some major wrinkles to iron out before it becomes a shoe-in.

In the meantime, how about we try to create businesses – and other organisations – that provide meaningful employment to more people, rather than fewer? Will that negatively impact profit margins? I doubt. And there’s always Deming’s First Theorem in any case.

More and more often, the Software Industry is being called upon to live up to its fine moral pronouncements. Automation is an item in the negative column on that balance sheet.

– Bob

Solutions Demand Problems

I’m obliged to Ben Simo (@QualityFrog) for a couple of recent tweets that prompted me to write this post:

BenSImoTweets

I very much concur that solutions disconnected from problems have little value or utility. It’s probably overdue to remind myself of the business problems which spurred me to create the various solutions I regularly blog about.

FlowChain

Problem

Continually managing projects (portfolios of projects, really) is a pain in the ass and a costly overhead (it doesn’t contribute to the work getting done, it causes continual scheduling and bottlenecking issues around key specialists, detracts from autonomy and shared purpose, and – from a flow-of-value-to-the-customer perspective – chops up the flow into mini-silos (not good for smooth flow). Typically, projects also leave little or no time, or infrastructure, for continually improving the way the work works. And the project approach is a bit like a lead overcoat, constraining management’s options, and making it difficult to make nimble re-adjustments to priorities on-the-fly.

Solution (in a Nutshell)

FlowChain proposes a single organisational backlog, to order all proposed new features and products, along with all proposed improvement actions (improvement to the way the work works). Guided by policies set by e.g. management, people in the pool of development specialists coalesce – in small groups, and in chunks of time of just a few days – around each suitable highest-priority work item to see it through to “done”.

Prod•gnosis

Problem

Speed to market for new products is held back and undermined by the conventional piecemeal, cross-silo approach to new product development. With multiple hands-offs, inter-silo queues, rework loops, and resource contentions, the conventional approach creates excessive delays (cf cost of delay), drives up the cost-of-quality (due to the propensity for errors), and the need for continual management  interventions (constant firefighting).

Solution (in a Nutshell)

Prod•gnosisproposes a holistic approach to New Product Development, seeing each product line or product family as an operational value stream (OVS), and the ongoing challenge as being the bringing of new operational value streams into existence. The Prod•gnosis approach stipulates an OVS-creating centre of excellence: a group of people with all the skills necessary to quickly and reliably creating new OVSs. Each new OVS, once created, is handed over to a dedicated OVS manager and team to run it under day-to-day BAU (Business as Usual).

Flow•gnosis

Problem

FlowChain was originally conceived as a solution for Analytic-minded organisations. In other words, an organisation with conventional functional silos, management, hierarchy, etc. In Synergistic-minded organisations, some adjustments can make FlowChain much more effective and better suited to that different kind of organisation.

Solution (in a Nutshell)

Flow•gnosis merges Prod•gnosis and FlowChain together, giving an organisation-wide, holistic solution which improves organisational effectiveness, reifies Continuous Improvement, speeds flowof new products into the market, provides an operational (value stream based) model for the whole business, and allows specialists from many functions to work together with a minimum of hand-offs, delays, mistakes and other wastes.

Rightshifting

Problem

Few organisations have a conscious idea of how relatively effective they are, and of the scope for them to become much more effective (and thus profitable, successful, etc.). Absent this awareness, there’s precious little incentive to lift one’s head up from the daily grind to imagine what could be.

Solution (in a Nutshell)

Rightshifting provides organisations with a context within which to consider their relative effectiveness, both with respect to other similar organisations, and more significantly, with respect to the organisation’s potential future self.

The Marshall Model

Problem

Few organisations have an explicit model for organisational effectiveness. Absence of such a model makes it difficult to have conversations around what actions the organisation needs to take to become more effective. And for change agents such as Consultants and Enterprise Coaches attempting to assist an organisation towards increased effectiveness, it can be difficult to choose the most effective kinds of interventions (these being contingent upon where the organisation is “at”, with regard to its set of collective assumptions and beliefs a.k.a. mindset).

Solution (in a Nutshell)

The Marshall Model provides an explanation of organisational effectiveness. The model provides a starting point for folks inside an organisation to begin discussing their own perspectives on what effectiveness means, what makes their own particular organisation effective, and what actions might be necessary to make the organisation more effective. Simultaneously, the Marshall Model (a.k.a. Dreyfus for Organisations) provides a framework for change agents to help select the kinds of interventions most likely to be successful.

Organisational Psychotherapy

Problem

Some organisations embrace the idea that the collective organisational mindset – what people, collectively believe about how organisations should work – is the prime determinant of organisational effectiveness, productivity, quality of life at work, profitability, and success. If so, how to “shift” the organisation’s mindset, its collective beliefs, assumptions and tropes, to a more healthy and effective place? Most organisations do not naturally have this skill set or capability. And it can take much time, and many costly missteps along the way, to acquire such a capability.

Solution (in a Nutshell)

Organisational Psychotherapy provides a means to accelerate the acquisition of the necessary skills and capabilities for an organisation to become competent in continually revising its collective set of assumptions and beliefs. Organisational Psychotherapists provide guidance and support to organisations in all stages of this journey.

Emotioneering

Problem

Research (cf Buy•ology ~ Martin Lindstrom) has shown conclusively that people buy things not on rational lines, but on emotional lines. Rationality, if it has a look-in at all, is reserved for post-hoc justification of buying decisions. However, most product development today is driven by rationality:

  • What are the customers’ pain points?
  • What are the user stories or customer journeys we need to address?
  • What features should we provide to ameliorate those pain points and meet those user needs?

Upshot: mediocre products which fail to appeal to the buyers’ emotions, excepting by accident. And thus less customer appeal, and so lower margins, lower demand, lower market share, and slower growth.

Solution (in a Nutshell)

Emotioneering proposes replacing the conventional requirements engineering process (whether that be big-design-up-front or incremental/iterative design) – focusing as it does on product features – with an *engineering* process focusing on ensuring our products creaate the emotional responses we wish to evoke in our customers and markets (and more broadly, in all the Folks That Matter).

The Antimatter Principle

Problem

How to create an environment where the relationships between people can thrive and flourish? An environment where engagement and morale is consistently through the roof? Where joy, passion and discretionary effort are palpable, ever-present and to-the-max?

Solution (in a Nutshell)

The Antimatter Principle proposes that putting the principle of “attending to folks’ needs” at front and centre of all of the organisation’s policies is by far the best way to create an environment where the relationships between people can thrive and flourish. Note: this includes policies governing the engineering disciplines of the organisation, i.e. attending to customers’ needs at least as much as to the needs of all the other Folks That Matter.

– Bob

Means and Ends

How often do we try to “improve” our product and services, and the revenue and profit therefrom (i.e. the ends), and how often do we try to improve the way the work works, the way we develop those products and services (i.e. the means)?

Folks have needs related to the way the work works, in many ways just as profound as the needs they have of the products and services (features, revenues, wages, …) resulting from that work.

To illustrate what I’m talking about, here’s a short list of some of the needs folks can have related to the way the (product development) work works:

  • Ongoing information (development schedules, quality levels, costs, plans, etc.)
  • Confidence (e.g. that milestones and Due Dates will be hit)
  • Growth
  • Learning
  • A sense of purpose (are we spending our time on stuff that matters?)
  • Integrity
  • Connection (e.g. human connections, relationships between people)
  • Appreciation
  • Harmony
  • Achievement
  • Etc. (and lots more possibilities in e.g. this Needs Inventory)

This post is an invitation to apply the same considerations to the explicit and intentional design of the way the work works, as we do to the way our products or services under development work.

In my previous post, “Antimatter Evo”, I explored the twelve principles associated with the Agile Manifesto, and proposed a way to radically simplify those twelve principle down to, essentially, one (“Attend to folks’ needs”).

May I invite you to consider the impact on your development efforts of applying the same principle – the Antimatter Principle?

Does your current approach – to defining and improving the way the work works – attend to the needs of the people that matter?

Blind Spot

In the typical product development situation, each new product (or service) that enters development is handled much like all those which have gone before. Outwith major revisions to the way the work works (say, adopting a revolutionary new approach such as Agile), incremental improvements to the means of development can occur, and occasionally do. Yet with both Kaikaku (revolutionary change) and Kaizen (incremental change), change is rarely connected to better serving the needs of the “folks that matter”. Put another way, change most often serves the product and its users, and rarely the folks impacted by the way the work works.

How blind is your organisation, presently, to the ability of its development efforts to meet the relevant needs of the people involved in those efforts?

What if we applied ourselves to understanding the needs of the people that matter, as they pertain to the way the work works? What effect might that have on the social dynamic, the relationships between different people and groups, on productivity, and on the general success of our development efforts?

– Bob

Antimatter Emotioneering

Well, that’s quite a mouthful. What does it mean?

The Antimatter Principle says “attend to folks’ needs”. Emotioneering says “design things specifically to evoke positive emotions, because that’s how people decide to buy – emotionally”.

Put these two together and we have a recipe for awesomely effective product development:

Appeal to folks’ emotions
by designing things (products, services) that
attend to their fundamental emotional needs.

Here, “folks” and “their” refer to everyone involved, not just buyers, customers or users.

  • Don’t get hung up on features or utility. It’s our emotional responses that rule our lives.
  • Don’t get hung up solely on the customers’ perspective. Everyone involved can find joy in attending to folks’ needs.
  • Be aware of the scope for attending to folks’ needs through the course, the activities of product development, and not just the end result.

– Bob

%d bloggers like this: