Go to chapter:
Agility is the primary element of the organisational side of CX design, digital or otherwise. This is not to be confused with big A Agile, which is something very different, created by consultants.
We define organisational agility as:
- Work delivered in small, testable chunks, rather than monolithic, complete pieces
- Starting with a best-case plan, refined and adjusted as work is progressed and completed, and
- Having open, honest comms, so when progress or quality are at risk, everyone knows and the project can be managed accordingly
A quick example might help illustrate why we think this agility is crucial, and more important than set in stone Agile methodology and rules.
When the Wright brothers were developing their first aircraft, their aim (unlike many of their contemporaries) was to build a craft that was:
- Safe to fly, and
- Fast to repair
That meant creating something that would move as slowly as possible and still fly. Their aim was to iterate as rapidly as possible, without losing time to injury or repair work, and to arrive at a design which worked, quickly.
The result was that they constructed a wind tunnel to test 200 wing designs, and went from in 1900-1902 making gliders and kites, to in 1903 having a powered, working aircraft. Over the next two years, they went from flights of under a minute to flying 24 miles in 40 minutes. By the advent of World War 1, aircraft could fly at 70 mph+ for hours at a time. All due to a system of agile prototyping and rapid development.
Efforts in helping modern organisations adapt should work on similar principles. Tests should be frequent, designed to show as much impact as rapidly as possible, and should be designed to as non-destructive as possible, so should something fail, it can be reversed as rapidly as possible.
The key traits to aim for are:
- Rapid decision-making, execution and review cycles
- Information accessibility across the whole organisation
- A culture where high performance is expected
In our experience, the best methods to achieve this, especially for mid and large scale organisations which traditionally struggle to adapt, are:
- Having leadership focused on removing friction in existing processes, to create greater efficiency
- Improving knowledge sharing and access to data and cross-departmental resources
- Having departmental priorities aligned to ensure different aspects of the organisation aren’t in conflict
- Developing greater levels of strategic planning, informed by both internal aims and external market factors
Obviously though, these things cannot be achieved without having someone in charge of and accountable for them. Which brings us nicely on to the subject of...
When we look at CEO, CMO and CIO views on what digital CX means, we see an interesting spread. CMOs think it’s mainly about technological innovation and customer interface development; CIOs believe its IT and infrastructure and innovation, CEOs see it as IT and infrastructure and custom-facing technologies. The truth is of course that they’re all correct; to degrees it’s all of these things.
However, because of this difference in viewpoint and beliefs around where digital spend should go, someone has to be put in charge who has a solely digital remit. Otherwise, they’ll always view digital CX as an extension of their other job function, leading to organisational friction.
Therefore, someone has to be in charge of leading digital change and development whose viewpoint is agnostic of, but can recognise and respond to these functions. Whether this is the emerging CDO (Chief Digital Officer) position, or a COO or CIO role doesn’t matter as much as that the responsibility exists somewhere in the organisation.
This leader’s job is to find ways of achieving the vision of the organisation’s leadership, to facilitate a working relationship to digital technologies and transformation between the CIO and CMO, and to deliver better user experience through digital channels.
This is especially important when we consider the first trait and method we noted down - “rapid decision-making, execution and review cycles”, and “leadership focused on removing friction in existing processes, to create greater efficiency”. That’s not going to happen without someone owning operational agility, and since most initiatives to develop that are going to fall into the digital transformation area, a CDO or similar is the logical choice.
Focus on Platform Simplicity
There’s a saying in the programming world - YAGNI. You Ain’t Gonna Need It. It’s a warning against building technology that you won’t end up using, because whilst you think it might be useful, there isn’t anyone actually asking for that thing, or trying to do it.
The same is true in platforming in business. What matters more than platform capabilities is platform surface area usage. If you have a system that can cater for anything you can think of, but never use more than 10% of what it does, then you’ve ended up with something that’s 90% redundant. Whether it’s a CMS, CRM, server hosting platform, content wireframing or anything else in the digital sphere, it’s invariably better to have a single, smaller system, supported by a couple of specialist systems to extend functionality, than a vast system which covers everything you could ever need.
Small, lightweight, extensible and replaceable elements, with shallower, shorter learning curves will always win out in both user adoption and usage.
This also feeds into the second aim, and the second and third methods. Data availability and knowledge sharing never work when the platforms involved require significant specialised knowledge to operate. In organisations where this is failing, we tend to observe one of two existing solutions:
- The “Call Fred” solution - known experts having time sapped by being a human interface to a complex system
- The “Best Guess” solution - users trying to get data, and trusting it, without having checks in place to ensure it has been read and analysed correctly.
Needless to say, these are both symptoms of systems which are opaque to those who need to use them. Organisations focusing on creating simplicity in platforming, to put the needs of employees and consumers interacting with them first, see notable increases in operational efficiency, and user satisfaction.
Small, Focused Teams
In a similar way to how small, simple pieces of software beat larger all-in-one systems, small, focused teams outperform monolithic organisational architectures.
The key aims for highly performing teams are to keep them small and able to both distribute and absorb knowledge rapidly, and to foster an environment of emotional openness and community. Both are as important as the other. The first allows for dynamism, and the second creates a positive group dynamic.
Ideally, this form of “atomic” unit should be replicated company-wide. The rationale behind this is to create a structure by which gains found in one team can be rapidly distributed to all other relevant pods, and to ensure that issues in any given atoms are contained. Also as we discussed earlier, the organisation has functions which underpin, processes, outcomes and interfaces. So having small teams allows for the organisation to reflect that; we can have atomic pods of work, which join into chains to facilitate processes, whose outcomes can be traced back to the people who facilitated them, and then measured effectively.
We’re aiming, as far as possible, to create a structure here that allows both what a business does, and how it does it, to fully take advantage of how digital technologies work, and the benefits they deliver.
An additional benefit of this is that it helps facilitate the last aim; it’s hard to have a culture focused on high performance when employees see themselves as cog in a machine. Smaller teams, where individual performance can be recognised and pushed to achieve excellence, creates an environment where everyone expects everyone else to deliver. It also helps push the organisation as a whole to be constantly developing and refining best practice, which can be shared out and replicated more readily, as employees from a pod can be seconded to other pods, to pass on their knowledge and upskill other teams more rapidly.
The final advantage of small teams is generally better management. Google’s Project Oxygen has spent over a decade now looking at the data behind what makes for good management, and they’ve so far nailed it down to a list of ten elements, which improve team performance and effectiveness.
However, the flip side is that, in looking at the list of attributes, they’re challenges which will be harder to face with a large team vs a smaller one. The list, in case you’re curious, is as follows:
- Is a good coach
- Empowers team and does not micromanage
- Creates an inclusive team environment, showing concern for success and well-being
- Is productive and results-oriented
- Is a good communicator - listens and shares information
- Supports career development and discusses performance
- Has a clear vision/strategy for the team
- Has key technical skills to help advise the team
- Collaborates across the organisation
- Is a strong decision maker
Coaching is harder when you’ve got more people, spreading you more thinly. Inclusivity is simpler when you’ve a smaller team and can better manage group dynamics, and ditto communication. Every element of management becomes simpler, allowing those who manage to be more effective, when their teams are smaller and they work more directly with those people. Everyone wins.