Push or pull? – two views of enterprise
For digital-transformation, what’s the difference between ‘push’ and ‘pull’? And where and how does enterprise-story come into the picture?
At first, these questions might seem more about marketing and suchlike than about ‘digital’ as such – yet the reality is that our digital-transformation will only work if we understand what these questions actually imply, and get the answers right for our own context.
For most organisations, the classic approach is ‘push’ – the emphasis is all on What and How, as we push our products and services onto others. The organisation is the centre of the world – more, the centre of everyone’s world, with others viewed merely as inputs to our processes:
We might accept a need to pay some attention further along the supply-chain:
And perhaps some attention to ‘the market’ – the prospects, the competition, the regulators and so on:
But otherwise it’s all about us, looking inside-out, pushing our products or services outward onto others:
In this type of context, the only kind of ‘digital transformation’ we could do successfully would be the same as that for the past forty years or so: internal-only, such as process-automation, data-matching and the like, as in classic IT-centric ‘enterprise’-architecture:
Even this kind of internal-only ‘digital-transformation’ is rarely as successful as we’d like. For a start, we can only make this work if everything is under our ‘control’ – which it rarely is, even within the organisation itself.
Beyond the organisation? – not a chance… Few organisations yet seem to have grasped even the core fundamentals such as privacy-issues – and without those, loss of trust or loss of effectiveness is all but certain. Far too often, clients and others in effect have to become enterprise-architects, to connect across the Conway’s Law chaos of the organisation’s disparate, disconnected silos, just to get anything done. This is bad enough when it’s just the one organisation we need to deal with as customers: but if we need to connect across multiple organisations, our chances of getting the results we need can drop like a brick – and yet would-be ‘digital-transformation’ can often make this worse.
In short, yeah, it’s a mess. That’s what an organisation-centric ‘push’-based approach always does. Oh well…
Yet there is a way out of that mess. A first hint here might come from Chris Potts’ all-important dictum:
Customers do not appear on our processes – we appear in their experiences.
And for us to appear in our customers’ experiences, we need to start not from ‘push’, but from ‘pull’.
The concept of ‘pull-marketing’ was probably first popularised by John Seely Brown et al, in their 2010 book ‘The Power of Pull‘. The crucial distinction between ‘push’ and ‘pull’ centres around the difference between organisation and enterprise – or, in effect, the difference between ‘How’ and ‘Why’.
In ‘push’, we believe that everything centres around our own organisation: we have a product or service, we push it out to the market, and, to gain people’s possible interest in what we have to offer, first try to force their attention towards us. (That’s the literal meaning of ‘advert’, by the way: ‘toward-turn’.) It no doubt seems the obvious thing to do, yet the reality is that it’s hugely expensive, in every possible sense, and it doesn’t even work well at all.
By contrast, ‘pull’ is enterprise-centric – an ‘enterprise’ in this context meaning a ‘bold endeavour’, a story or storyworld that is shared with others. For example, when I want to mend a broken chair, I am at that point within the storyworld of ‘How to mend a broken chair’ – which gives me a reason, a ‘Why’, to look for other players in that storyworld who can help me satisfy that need. A provider doesn’t need to push anything at me, because I’m already looking: the pull towards the provider is already there. But what it does mean is that the provider needs to see itself as a player in the shared-story – and be able to under the customer-needs, the view ‘outside-in’, as much as it understands its own more conventional view looking ‘inside-out’ from itself:
In this sense, a digital-transformation that actually works is one that engages from both sides of the interaction-journey – again, balancing inside-out and outside-in.
This also warns us that the term ‘digital-transformation’ is actually a bit misleading. Yes, digital-technologies can act as a key enabler here: but I explained in a recent video on this theme, any transformation is always about people – with any discussions about technology always being a secondary to the people-needs.
In short, for successful digital-transformation, we always need to think story-first, not technology-first.
To make sense of ‘pull’, we’d often model the respective enterprise with our organisation at the centre, much as for ‘push’ – yet we need to remember that this is just a way to show how we position ourselves within that broader shared-enterprise:
From the customer’s perspective, though, the same shared-enterprise will likely look very different, with various players categorised according to the customer’s own likely needs:
The storyworld of the enterprise is made up of a vision – such as mended chairs, or business-travel, in our two examples above – and a set of values and principles that help to define what ‘good outcomes’ and ‘not-good outcomes’ would look like. Note that all players in the storyworld agree to adhere to these – otherwise they’re literally not in the same enterprise. This point is crucial to understanding how an enterprise actually works, because the vision, values and principles are the metaphoric glue that hold the enterprise together as a single shared-story:
Each player – such as our organisation – selects a role via which it can place itself somewhere within that storyworld, that shared enterprise. In effect, by doing so, it selects the scenes and storylines within which it will play some part. Connecting scenes together provides the respective storylines – otherwise known as processes and the like.
Note that players may well take on multiple roles within the same shared-enterprise – hence a partner, for example, who might take on roles of both provider and customer relative to our organisation.
In much the same way, our customers may well interact with many other shared-enterprises, even during a single day – yet we need to keep our focus on this shared-enterprise, and if necessary remind them of our own understanding of the shared-vision and shared-values that underpin the enterprise we expect to share with them. For the latter, it can be useful to understand how the shared-story provides values and suchlike to identify factors for trust, across the inside-outside boundary. To put it at its simplest, if we don’t have trust, we don’t have a business…
Note, though, that one of the probable key requirements to make sense of the interaction-journeys in a ‘pull’-model is a minimum maturity-level for the organisation’s enterprise-architecture. A classic IT-centric enterprise-architecture will not be sufficient for this, as it will not be able to reach much above a level-2 maturity, as per the diagram below. This in itself is a common cause of failure for the respective attempted digital-transformation:
Again unlike a classic IT-centric EA, this enterprise-architecture needs a solid grasp of the entire enterprise-context, and the entire organisation-context too – all the way out, and all the way in:
And as per the base of that diagram above, much of what we need for digital-transformation isn’t ‘digital’ at all – a point we must never forget…
‘Push’ doesn’t work well, for anyone: ‘pull’ is what we need if we’re to make a digital-transformation succeed. And in turn, ‘pull’ depends on understanding the enterprise as story. If we’ve been brought up on IT-centric notions of enterprise-architecture, and organisation-centric views of the enterprise, it can sometimes seem at first to be somewhat of a challenge to make sense of this – but once we do so, everything in the architecture falls into place in a much simpler way.
Really good observations, as always, Tom. Thank you. I’ll add a couple of things — Participation in a story field–let’s say it’s composed of customer narratives–does not have to be be in the shape of a story. The basis of the participation and, if there’s a transaction, collaboration, is what we call ‘game,’ and what quantum storytellers call ‘antenarrative’ — which has to do with ‘before story’ and a second meaning of ‘a bet on the future of a story.’ A game, in our case, serves as a story engine — producing stories that are thematically aligned, yet cannot have been predicted or pre-determined from the structure of the game. My variation on Potts’ quote: “Customers do not appear in our stories, we appear in theirs.”
It depends . .
e.g. Push is better. . . In an e-hub app we built for a healthcare facility, the Managed Care client had 100+ member clinics – they wanted each clinic seeing a patient to have up-to-date info.
So, the right time to get an update was the day or prior day to an appointment.
No telling when a patient would go to a particular clinic, so no point receiving an update each time the patient receives a service at other clinic/physician visits. Some only visit a particular clinic once a year.
e.g. Pull is better . . . .in a manufacturer/supplier workflow where the manufacturer is waiting for a part, failure to check daily is likely to extend the timeline if the manufacturer must prepare for delivery/receipt.
Re data exchange/security . . .
As for “Few organisations yet seem to have grasped even the core fundamentals such as privacy-issues” – we evolved at least 10 years ago a simple generic “data exchanger” where publishers declared what they were willing the share and subscribers came, cap in hand, requesting individualized subsets of the data.
The Publishers used their own data element naming conventions, the subscribers individually registered their preferred naming conventions for what they wanted/needed (i.e. a published “Office_address” data element became “OA” for subscriber1, “Off” for subscriber2 etc.)
No registration of a cross-name meant no data share for that data element/cluster for a would-be subscriber and the publisher controlled all of the registrations.
A full pending/read/confirmed_receipt tracking was part of the Log so that a subscriber who picks up, receives data but then sees the update fail at the subscriber app, could “rewind’ or “try later”.