The optimism of #Purpose & science of #design in forging #digital customer experiences! Opinions my own!

JOURNEYLED ORGANISATION (JLO)

If we are certain that transposed journeys are accretive vs dissipative ROX then perhaps we need to commit – conviction perhaps manifested in a new type of org design we will simply call a Journey-led Organisation (JLO)  for now. 

The siloes we are contending with are constructs from the renaissance of the Industrial Age, the swinging 60s and hippy 70s. We’ve adapted these siloes throughout the course of history – but it’s time we accept the fact: what got us here, won’t get us there. 

If you’re a sci-fi fan specifically  a Trekkie  then you’d recall Zefram Cochran discovered the  warp engine – then the Vulcans arrived (signalling human civilisation is now warp capable, space faring etc). The same analogy, we need a JLO to set us up to navigate Industry 5.0 and Web3, tunneling through ‘wormholes’ I simply label InfiniteJourneys. 

Imagine an org being laid flat on its belly- a transposed org places full  focus and emphasis on journeys. You’d imagine near initiator ‘strains’ of journeys making up the DNA of the org. 

Multidisciplinary teams will be working on a bunch  of journeys (and their sub-parts, episodes, scenes, acts) – fixing ‘pain points’ or experience gaps iteratively. It’s quite important to note these agile pods/squads are transient and virtually formed – meaning each of these teams comprise required MVP skill sets to fix problems at hand (when identified in journeys). 

Let’s take for example, in a Telco onboarding  journey, when new subscribers are (net) added onto the network (a new customer). Imagine they need to be familiarised with their first bills (to avoid something commonly known as a bill-shock). The teams assigned to this journey would be focused on initiatives such as video/electronic billing, digital welcome packs (download the app?) offering step by step guides and wizards, social media notifications etc. While the onboarding journey might seem  quite ‘front of house’ ie marketing/service related (again, we should stop thinking in siloes) – we need team members from the ‘backend’ in this case OSS/BSS represented. How first bills are pro-rated, how rates and CDRs are mediated is too complicated for the customer – it is the team’s job (pet peeve)  to simplify language and annihilate jargons. 

Similarly if it’s a sub-journey relating to network quality and experience (QoE, QoS), we need the Network and Engineering ‘departments’ represented in these agile pods. While the user stories, what gets into the backlog (to be developed, a fix) might be on the telcos’ network layer- it’s essential that the customer doesn’t have to contend with such sacrifices (most common in telecommunications = signal strength, blind spots, network/call drops, throttling etc). How the ‘solution’ is presented to the customer – how it’s communicated post an outage – should all be in a language we all understand. 

There will be hundreds and thousands of these agile pods/squads at any one time, working on entire journey strains, or it could be specified episodes. What’s more important- there’s no mention of hard siloes, only primary, secondary and tertiary skill sets to fix gaps and solve for optimal experience! 

It’s a little like the StarShip Enterprise (I’m a Trekkie obviously)- everyone at the Bridge  can ‘cover’ for each other. However each would have their primary areas of specialisation eg. flight , navigation, communications, tacticals and defence etc.

This is really pushing the boundaries of XM. 

Change management is the single hardest thing to do in large scale  Transformation projects, hands down. We are after all, dealing with humans – it’s never about technology, and other enablers.

It’s always about human purpose and leadership – from when we huddled together for safety, started hunting in packs, toiled lands together, waged wars even. Everything we’ve ever done is a manifestation of (someone’s) purpose. Visionaries, futurists, leaders have shaped human history over a millenia – and now we just give these fancy names, digital, transformations etc. 

Enter the Chief Customer, Chief Experience and soon, Chief Journey Officers. Definitely new members of the C-suite. By new I’m saying <5 years as of this writing (the author has designed a lot of ‘new’ orgs optimised for XM – variations on customer obsessed if you will – over the years). 

The idea is the CCO is an ‘upgraded’ COO. Usually the 2nd man/woman, the CCO has total autonomy over the customer franchise (regardless journey, department, silo). He/she is fully responsible for the Customer-centric P&L, balance sheet statement. 

The CxO typically reports into the CCO, and one could argue is the overall architect/designer of the intended experience; some orgs have tried giving the  CxO jurisdiction over what’s known as Experience/Journey Orchestration as well – but early data suggests that responsibility should fall on the CTrO’s shoulders (at least for the initial 2 years of Transformation time elapsed). 

There’s a slight nuance that the CCO is the 2nd man/woman with the CTrO and CXOs continuously supporting the upstreams and downstreams of the transposed journeys. Mind you, orgs in transition do not have 100% of journeys transposed (actually – we would be lucky to see 50%) – what we end up with is something described in Innosights’ work : Dual Transformation, except both non and transposed orgs are part of Transformation A (NewCore). . Transformation B from that train of thought then focuses on FutureBack, totally new business models – typically disrupting Transformation A over time. 

Which brings us to another newly minted C-suite member: the rise of the Chief Journey Officer! The CJO has both CXO and CTrO’s jurisdictions combined- in a long strain. You might think of if this way: the newly transposed journey strains go with the CJO, and over time, that would approximate ~100% of the org (Transformation A). 

It feels as if the CTrO’s transience has an expiry date, the impermanence might not be every/any executive’s cuppa! To that end, the CJO role is an adaptation that’s arguably ‘cleaner’ for the target end state. The CJO would have the agile pods/squads – who might previously be under the care of the CTrO – working directly for him/her. The CJO would also spend a commensurate amount of time upstream – taking charge of the innovation and  design aspects of the journeys; which was typically the CXO’s remit. We’ve observed there’s less leakage and attenuation with this model, with the CJO accountable for 100% of each journey strain. To put it simply –  the user stories and the backlogs are crisper vs muddled prioritisations if too many parties get involved. 

Now the CCO would have several key CJOs (typically <5) each making up the entire org fabric – now we begin to see the overall autonomy of the JLO being laid flat on its belly. There’s very little friction and attenuation between non-existent siloes. There might be over capacity, eg over concentration of skillsets – but 

optimal equilibrium is quickly found as pods/squads swap in/out between CJOs.