I left Cancer Research UK last week and while this is not exactly a goodbye to digital transformation it does signal a shift for me – instead of supporting other people to make change happen I will be leading change in the services that I am responsible for – working with the talented Adur and Worthing digital gang led by Paul Brewer. This post is a bit of a reflection of the work I’ve been doing and in effect my starting point for the next digital project I work on. All the usual caveats about the term digital apply and you can read all about my dilemmas with the term here.
We didn’t call out the work we were doing at CRUK specifically as digital transformation as it doesn’t feel like a useful term – if we define transformation as a step change in performance and practice its hard to imagine any transformation not having ‘digital’ as a foundation of that change at this point. The CRUK technology strategy (which you can read about on the CRUK Tech blog) therefore focuses on modernisation and digitisation across all aspects of the technology teams work with the expectation that will need to be delivered in partnership with business teams. I’ll reflect on that work at a later date as I think these things are better left percolating rather than being written down the week after you leave (it took me 2 years to blog about my last role!) but there are a few things I have learned over the last couple of years I want to take with me into my next job:
All change is system change (original article here)
I wrote this a couple of years ago now and its still represents a foundation to my thinking (warning – its a bit long but lots of references etc if you like that kind of thing)
In it I talked about the need to shift the business change trope of ‘people’, process tech:
- Change ‘people’ for ‘networks’: Lets not think of people as unit of resource inside an industrial model – instead let think about the power of collective action and the asset that provides
- Exchange ‘process’ with ‘purpose’: We want to create an environment where we unite behind common purpose and then iterate and improve the process that helps us to work to that purpose
- Update ‘technology’ with ‘infrastructure‘: Don’t just think about the technology but instead the operating context which will help you make change happen
I would still hold by this and the thinking behind it but with three additions:
- You need to understand the boundaries of the system and in many cases make sure that these fit with the organisational boundaries you are trying to shift – at least in the first instance
- You need to have the right place to start and a strong foundation to do it from – you are moving the world so you need the right place to stand
- You need to have a vision for your future state at the same time as being able to adjust it as you learn more
All that being said, people, process and technology are useful starting points – but only if you know your destination is going to be more complicated than that.
Technology mirrors organisational dysfunction and organisational design matters
Over the last 18 months we (the CRUK we) have had a team wrestling with a CRM replacement programme – in essence removing a legacy enterprise CRM in order to replace it with some more modular, interoperable and open. In doing so the programme team have done some truly impressive analysis work, digging put processes and trying to fit them together. At times it feels more like organisational archaeology than transformation as you sift though the history of process and design changes that silt up your infrastructure. Its an acknowledged effect called mirroring – your technology as a mirror of your decisions and structures (read more about this here).
This kind of analysis lays out your choices for the future as well as showing very clearly the impact of the choices of the past. I am particularly proud of the work the CRUK team has done in this area – particularly the way in which they have brought together business analysis, business and technical architecture as well as service design to create really deep and sophisticated recommendations (HT to @Snez, @tammy and @nic as well as the wonderful Kate who is not on twitter). This was inspired by the work at Essex on service transformation and the work on digital services at Croydon, as well as what we see emerging from the Catalyst work on Service recipes for Charities. Finally, the thinking that both Sarah Drummond of Snook and Lou Downes with her Good Services book have done in this space has been hugely influential to me and to other people.
The other consideration is that all of your technology is not created equal – we just don’t live in a nirvana of modern technology that fits perfectly together and so we need to design and run technology transformations with a degree of pragmatism which is often missing. I really like the Simon Wardley definitions of pioneers, settlers and town planners as showing the different modes that are needed to cover the different scenarios of business need and technology readiness and its worth giving this article by Neil Perkins a read as it really nails this>
[Aside – charity people have often wondered at why I draw so much on government and in particular local government examples – here it is in a nutshell:
- In common with any large organisation localgov is never a green field site – its always wrestling with legacy
- In common with charities It can’t ignore part of its user base just because they have become inconvenient which is what corporates can do
- Its never got enough cash (at least the local bit) – also very much in common with charities!
The final point is a shared intent around public service – something which shifts the perspective of people and as a result drives different behaviours and solutions. Convinced yet?]
You can only go so far with user centred design before you need to design the whole service – or the whole organisation
Of course user centred design is central to building good technology but unless you look at the service that sits behind the experience you are always going to fall short. I’m delighted that we introduced service design into the team at CRUK (led first by Giulia Merlo and then by Snezh Halacheva) but this was only possible because we had those user centred design skills already there, understood and valued (all credit to Dylan Barlett and his merry band). Because this foundation was in place we were able to embed service design in a number of areas in the CRM replacement programme and as a result create another route in for new ways of working and design thinking.
But the bringing it together with Business Architecture and analysis was critical and very much a way of creating a wide ranging multidisciplinary team that reflects the fact that without some of the organisational analysis techniques that ‘traditional’ architecture practices bring its difficult to look at organisational scale problems and questions. I prefer this kind of bottom up analysis but it does then need to resolve into some kind of target operating model and I suppose that is my other takeaway – eventually you have to look at how the pieces all fit together and this is where you need to make a decision about you organise around.
This analysis is not only essential for figuring out what’s going on right now – its a backbone of understanding your future state. But that future state can’t be some kind of ideal and that’s where I think modern transformation approaches need to diverge from their waterfall antecedents and bring forward thinking about how something will actually fit within the organisation is in its ‘run’ state – not just figure out how to build it. This is the lesson I took away from reading up on Devops in the context of our future state – there is no point in creating something that doesn’t have continuous improvement embedded into its design – and this means that technology and organisational design need to fit closely together to avoid the kind of divergence that we have been uncovering in our organisational ethnography. The future state design has to look beyond the technology into the business function its serving if you want to avoid that drift.
Organisational design take us down a whole other rabbit hole but my thinking on this was very much formed by a combination of my MSc which was analysis and design of information systems and covered some of the principles of organisational design and more strategic approaches around how to design around organisational outcomes and value chains (nice intro to Porter’s work on this here) or value propositions (definition here) which are more common in agile environments which use methods like lean business canvas. It makes questions of what you value and also what you need to control and/or change central to any transformation you are thinking about – its these things that provide your place to stand.
And let’s not forget about purpose – which I wrote about here – which can overcome any kind of strategy of cultural barrier.
You can’t build a modern thing in old fashioned ways
All of this needs to be balanced with thinking around how to create more networked and less hierarchical organisation (still love Laloux on this) in pursuit of greater organisational agility. This means three things:
- You should be aiming to create stable, multidisciplinary teams and funnel work to them (Always good to refer to the research done at Google on this)
- You need to make sure that any major project or programme is designed and delivered with the agility and change that you are trying to end up with
- You need to be clear on what you are trying to control and where your organisational value sits
At CRUK we have done a lot of work over the last couple of years working on our capability model (al la Spotify) and also making sure that it was made up of more established capabilities such as Business Analysis as well as newer disciplines like UX design. This work has been hard at times but the team now have an internal playbook that reflects the landscape but more importantly in concreting that the different disciplines have a better appreciation of the value that they each bring. It gives a solid foundation for an new piece of work that is spun up – which alas is too often as the current operating model has technology at the end of firehose of business need rather than organised into those stable teams ready to catch work as it emerges. I would do this again – its a lot of cultural work disguised as practical stuff but its really valuable.
The work I described on big programme design has been progressing over the last year and is one of the things I will write more about when I have had chance to reflect but my immediate reflection is on the importance of good governance design and a flexible approach to planning and programme structure that allows you to iterate and adapt as much as possible.
The questions of control and value are more difficult to access but a lot has been revealed by the deep analysis that I described which has enabled the team to ask some far reaching questions that are more about organisational strategy than the technology it serves.
All of our cores just got flexible
The other motivation for deepening of these new disciplines is the unavoidable nature of some of the legacy technology that needs wrestling. There is only so much change you can do at the front end before some kind of legacy chicken comes home to roost and we are not seeing organisations wrestle with what Forrester terms the ‘flexible core’. Having spent the last 18 month knee deep in a CRM replacement project this is exactly what I have been looking at. It’s hard.
Its hard not just because any legacy system tends to have ossified but also because this is the point at which your (hopefully) more digital front end practices need to come face to face with the folks who have been keeping the legacy system alive. This has to be treated as a cultural change at least as much as its treated as a technical one.
Modern software – not just the front end stuff – is set up for agility and its also set up for continuous improvement and deployment (that’s the whole point of Devops which you can be introduced to in the terribly written but highly informative Project Phoenix book). Legacy software is just not designed with constant change in mind and while there are loads of aspects of devops – the devops mindset – you can introduce without modernising your infrastructure at some point your ambitions to be agile will be thwarted by some crappy old bit of tech that its too terrifying to change without a full on change control process. The people managing this stuff have tried to adapt – that’s why things like SAFE exist but its not enough because:
Digital folks need to come to terms with legacy technology
This final point is really important if you really want to achieve an organisational transformation but it means that those legacy systems become everyones problem. And this is also hard – so many of the practices that have been developed for digital green field sites – such as agile, product management or service design – rely on being able to experiment and iterate – something that is hard if not impossible with many legacy systems. You are then left with a conundrum of how to bring new ways of working and management practices to bear before you have the technology estate in place to be able to easily support them.
And this is the reason why you need a capability model that includes old and new disciplines. You need all the skills working closely together to bring these two worlds together.
At some point you have to choose
And that’s my final thought – at some point you have to choose. You can iterate and experiment but at some point you need to define an operating model that reflects your organisational purpose and organises people into stable teams with clear technological boundaries to the best extent possible in order to deliver value against your objectives. You need to minimise handoffs so that teams can progress at their own pace and you need clear governance and accountabilities so that it’s obvious how and where decisions get made. How hard is that? I mean how HARD it THAT!
Organisations – especially established ones – don’t often have a clear purpose. Technology rarely has need boundaries and stable teams are hard to maintain when expensive skills are scarce. But that’s not the biggest choice. At some point you need to decide that this modern digital stuff is not something you are testing, exploring or experimenting with – its something you are doing – and that’s another kind of hard as to remove ambiguity around this means that you have run out of time to persuade cajole or support people to learn about new ways of doing things.
Choosing doesn’t mean overnight change or the magic bullet – but it does set you on the right path.