I first wrote this as a comment on Joel Bailey’s excellent blog post titled ‘This thing called agile might kill us all’ but thought it worth re-hashing and expanding here.
For context, Joel writes about “working for a big high street bank. The brief is to redesign the ‘end to end mortgage experience’. The timescale is to reach a business case, with a roadmap of delivery waves to achieve minimum viable product, within 6 weeks. ”
He floats the idea of a Target Customer Experience as counterpoint to that change management staple, the Target Operating Model.
I’ve had recent experience with a “TOM”, attempting to intercept with an agile, digital project. It left me puzzled, and I’m grateful to Joel’s post for helping me clarify my unease.
In case you haven’t come across one before, the TOM is a Thing in the world of “change management,” defined on Wikipedia as:
a description of the desired state of the operations of a business. Typically a TOM also includes the roadmap over time that specifies what the company needs to do to move from the “as is” to the “to be”.
For the service designers among you, a typical TOM covers similar turf to Alex Osterwalder’s Business Model Canvas, only with fewer sticky notes and more spreadsheets.
As an aside on his nascent agile project, Joel writes about the toll it takes on participants:
someone needs to write a Marxist evaluation of agile. Yes the outcome is better and it’s all very sexy and new and ‘oh so right’, but I suspect the cost on the worker is high as essentially it speeds production and works the asset of production (you and me) harder.
… which immediately set me thinking that if people are using “agile” to mean doing the same process only faster, even at the risk of burning out their people, then they’re Doing It Wrong.
I reached for the 8th of the Agile Manifesto Principles:
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
And that’s when I realised the real challenge to peddlers of TOMs and the like: agile transformation isn’t a one-off thing that you do to get from A to B – it’s a continuous culture of iterative improvement.
Agile organisations succeed through sensing, not planning.
- They are in touch with their actual customer experience (not just some brand fantasy). This is the dirty secret of much Target Operating Model work. A warts-and-all “as is” picture is far more valuable than any amount of “to be” prognostication – but even if that’s what executives secretly wish for, no consultant can afford to say out loud “I’ll tell you the time if you show me your watch”. Sadly the picture TOM processes do generate is often missing empathy, the key ingredient that spurs the organisation’s people on to make things better for their customers.
- They truly understand their operating model (clue: it won’t look like a flow chart). Organisations are nothing more than systems made of, and by, people. They’re complex social constructs that operate on emotional as well as financial planes. This is what agile understands when it says “individuals and interactions over processes and tools”. To map an organisation by decomposition is to follow in the footsteps of the early Cartesians, dissecting a dog to prove it has no soul.
- They have the capacity to make very frequent adaptations in response to their ever-growing understanding of customer needs. Being able to respond quickly to what you learn beats any amount of predicting and planning. Embracing diversity means pushing decision-making to the frontline. This in turn reduces the waste inherent in standardised processes. Let’s cultivate this as a core competency of every organisation. If we never get stuck in a rut, we’ll never require a “change programme” to jolt us out again – and that should come as a relief to all concerned.
All of this poses problems to an organisation addicted to discontinuous change. We’ll have to break down the Berlin Wall between the bits of an organisation that create “strategy” and the bits that do “operations”. Likely, product development can no longer be capitalised, so the balance sheet might appear worse before it gets better.
But I’ve come to the conclusion that this is the only sane way to run an organisation.
Learning by doing: it’s the Last Target Operating Model You’ll Ever Need™
Matt Edgar writes here 
Exactly right. Strategy should be limited to determining the purpose of the organisation (i.e. what it does better than anybody else and why/how), ensuring that everyone in the organisation understands that strategy and how their role helps fulfil it, and finallywatching out for the signs that mean that said strategy is under threat. Everything else should be operational.
Thanks John, and yes to all of that!
love to have triggered another chain of thought. I agree with this entirely. the pain I am witnessing is the shift from discontinuous to continuous change. thanks for the words!
Thanks for the stimulus, Joel. I’d be really interested in follow-up posts to hear how that shift progresses.
Nice analysis. I guess the Change guys get bought in when the patient needs heart surgery though, no? Iterating your way towards success isn’t always possible when you’re going really really slow and management is all upside down and your brands in the gutter… Sometimes you need a restructure, a new business plan and some shock therapy!
Thanks Nick, I guess I could buy that analogy if the management consulting profession had anything like the fact base of modern, precision heart surgery. Until then I’ll stick with 18th Century quackery as my analogy of choice! Strange that the organisations in most trouble seem to be the ones that go in for drastic quick fixes most frequently?
Interesting and probably true when working across organisations that are small enough to manage personally. So my question how do you change an organisation with thousands of people? Learning by doing seems a bit too risky. Maybe your experience doesn’t extend to changing large organisations? If you look at the practicalities of an organisation which employs 120k people worldwide (Microsoft) 55K (Google) 80k (Apple) 1.7 million (McDonalds) 100k (GSK) there are much more; I think your approach may start to creak at the seams. You will quickly find you’ll want to define a strategy that accommodates large scale change called a TOM. If you apply a TOM strategy to a small organisation, then you will find as you have stated, it doesn’t work, it overplays the process of managing change.
Hi John, and thanks for commenting. In fact, I reckon that the fiction of the TOM is even _less_ believable as organisations approach city scale. Between 2000 and 2012, I worked for Orange/France Télécom (157K employees). In that time, cargo cult “visionary” leaders with grand transformation projects brought the business close to bankruptcy and created a social crisis that became front page news in France. Both times the business was saved by countless little acts of bravery and kindness in the workforce all over the world. The idea that we can engineer an organisation to greatness is a fantasy that only gets more dangerous as the organisation gets bigger.
Matt thanks for the reply. I probably agree with you and have also experienced grand change programmes that don’t achieve anything. So how do you disrupt what seems to be a major business consulting approach?
This got me thinking – about many things, but most of all about organisation, partly because of the thread above about scaling agile to large organisations.
I wondered if you’d come across Ricardo Semler? In essence, his / Semco’s model of industrial democratisation is a way of decomposing a large organisation into overlapping, self organising teams responsible for specific areas (which teams can also define – they’re a highly diversified business, partially as a result), and which elect their own leaders.
https://en.wikipedia.org/wiki/Ricardo_Semler
http://www.freibergs.com/resources/articles/leadership/semco-insanity-that-works/
Of course, it’s pretty dangerous stuff taken as a whole for most organisations, but I feel there’s plenty we could learn from it that could be applied elsewhere.
Any thoughts?
Interesting article, thanks.
The organisation at which I work is just about to start introducing a TOM, so I’m keen to understand what best practice is when the business purports to be acting in an agile manner. I’m completely new to this area and approaching it from an IT Development perspective, so apologies if I’m missing the point, but what are you saying is the alternative to the TOM? A Target Customer Experience (TCE) based around a high-level strategy (as in the Business Model Canvas)? And that organisations should focus less on upfront business process modelling, and should rather concentrate on establishing means of measuring the impact of changes on business benefits or progress towards the TCE (e.g. in terms of service availability, customer retention/satisfaction, or sales conversion)?
Are Service Designers expected to consider the impact of continuous service/TCE changes on business processes, people, facilities, and technology? Would they then provide information to affected parties on a continuous (possibly sprint-aligned basis, or as features are toggled on)?
TBH, I’m struggling to grasp where this all fits in relation to my current employer’s structure. I’m not sure whether it’s correct to assume the term Service Design as it is used in this article is similar to ITIL (spit) Service Design (covering Availability Management, Service Catalog Management, and Supplier Management etc.). From Googling the subject, I get the impression Service Designers are involved in aspects of Service Strategy and Transition too.
I have done some brief Googling on this matter, but am not really any the wiser, though I did find the following links useful:
Click to access Agile_Service_Design_Framework_Enfocus_Solutions.pdf