In July 2014, Spark the Change offered an Award for organisations trying to change the way they worked. We were looking for creative innovation and responsiveness, and a commitment to building happier workplaces. From 67 applicants, the prize was awarded to GCHQ, with a runner-up place given to Markel International. In this article, Spark judge and writer, Helen Walton, discovers the detailed story of changes made by the Digital Retail team at Markel International.
Behind the technology curve
Markel International is a member of Lloyd’s – the insurance market that dates back to the seventeenth century and has plenty of quaint traditions to prove it – including a ‘smart business’ dress code for visitors. It’s an industry that even its own journals refer to as, ‘slow to change and even resistant to change’.
A specialist marine insurer I spoke to – not from Markel – assured me that business deals were still done over drinks, dinner and golf. ‘It’ll never change in big insurance,’ he declared confidently, ‘personal relationships are what matter. Technology’s just the back-end stuff’.
‘The Back-End stuff’ in insurance is hardly acclaimed as a perfect model of efficiency however. A recent report by State Street surveyed more than 300 insurers from around the world, and found that 86 per cent of insurers are challenged by legacy IT issues, with 93 per cent saying they need a new IT infrastructure to integrate and manage data. Other topics that frequently draw attention within the industry include improving customer experience at key touch-points of claim or renewal, refining product targeting and detecting insurance fraud.
These are all opportunities in which you would expect technology to play a big part. But commentators see the insurance industry as behind the curve. Ernst and Young’s recent survey showed that nearly 80% of insurers acknowledged they are “only playing at” or “still learning” digital insurance. They specifically called out internal blocks: conservative cultures, organisational structures that prevent rapid change and systems implementation issues (exacerbated by legacy technology).
Despite a significant gap between where they were and where they wanted to be, few of the companies surveyed were investing to close this gap. Fewer than 10% were trying to ‘transform’ the culture that they named as blocking progress.
A company looking for change
It’s a picture with which Paul Jackman, Markel’s Director, Information Technology and Services, was painfully familiar. ‘We had the right strategy,’ he remarked ruefully, ‘we knew what we wanted our capability to be – but not how to achieve it. And we had to.’ Director of Operations Hugh Maltby echoed the urgency: ‘One thing was certain,’ he said, ‘digital wasn’t going to go away. We needed better tech capability right now – and that need was only going to grow.’
A tech lead on the ground put the case more bluntly: ‘IT was seen as too slow, too expensive and a total blocker. Various people in the business wanted to bypass the existing IT team altogether for new development. I’m so glad that Markel decided to tackle the culture and get to the root cause, not just the symptoms. The day everyone looked at the existing development process and understood its pain points was a wake-up call for the whole company.’
In partnership withThoughtWorks, Markel International began a fast-track programme to transform the practicalities of how theyit developed IT, the culture and IT’s relationship with the rest of the business.
A palpable difference
Walking through the 70s-built Markel building – which everyone I spoke to was keen to point out they were soon to leave – was a strange experience. To someone used to working in start-ups and creative departments, the formal dress code, straight lines of desks and feature-less grey walls felt rather damping. I had an urge to speak only in whispers. Then, tucked away in one corner of the building, was a sudden explosion – a space which HR Recruitment lead, Emma Guojah, referred to as Markel’s Aladdin’s Cave.
Every wall was covered from floor to ceiling in posters, charts and post-it notes. People, dressed casually in jeans and t-shirts, huddled together around desks or gesticulated in front of white-boards. The noise level, while not excessive, was on a different scale to that in the rest of the building. I understood why Hugh Maltby had referred to the team’s ‘buzzy way of working’. The energy was palpable.
Darius Kumana, Head of IT and Digital Strategy for Retail, introduced me to the team and took me through some of the basic Agile practices they used. The teams were fully cross-functional, they programmed in pairs and followed a two-week iteration cycle. They had invested heavily in automation and were deploying every other day using release pairs. He talked me through the different governance structures and planning changes they had introduced. He pointed out a ‘Stupid Rules Board’ where the team challenged corporate rules that they felt blocked innovation and collaboration – everything from not being able to use google-docs to strict templates on the intranet.
I asked Darius how senior management reacted to being told the organisation had stupid rules. He grinned disarmingly. ‘Markel has always said it welcomes challenge as one of its key values. I’m not saying people aren’t a bit taken aback occasionally, but we make small changes happen. And each time the next change goes through a little easier.’ Perhaps I looked slightly underwhelmed, because Darius introduced me to a few long-serving members of the team to hear from them just how big the changes had been.
Waterfall to Agile in under 6 months
‘Before this, the way we worked was pure waterfall,’ Victor Martinez, a Business Analyst told me. ‘There was a lengthy requirements gathering phase which involved no actual users – just assumptions about what customers wanted. Then everything was handed over to programmers who vanished for 6 months or longer. The testing phase added more time on top – and our quality was still pretty awful. By the time it was done, the business could barely remember the original requirements – except that whatever we delivered was definitely not what they needed now.’
In contrast, Victor described the work that the team now did to understand the likely users, from initial research through validation and showcasing. Persona posters were prominently displayed and I saw developers pointing to them several times as they discussed particular stories. Indeed, the process of story creation was moving from analysts to developers, while analysts signed off on functionality pre-development. The speed increase was impressive – where Victor recalled a direct web platform taking 2-3 years, he was convinced that the new platform just launched had delivered equal functionality in only 3-4 months. ‘While as for releases…’ he said.
‘It’s chalk and cheese’ chipped in Paul Rathborne, one of the Tech Leads. ‘Before we were running about like headless chooks. Now, releases are almost a non-event. And although we have spikes and troughs, there’s a sense of calm in the development process. We trust our capabilities. There’s clarity over how decisions get made. We have greater freedom. And I don’t just mean not having to wear a suit and tie anymore.’ He smiles: ‘everyone is more motivated.’
The motivation was so tangible in QA Sandeep Sattani that he was practically vibrating. ‘I’d done something called “Agile” before,’ he told me, ‘but as soon as we started this process, I realised it hadn’t been real Agile. Here we are genuinely cross-functional – and that has meant huge change: not just in what I’ve learned technically but in how I’ve developed personally. The first time I heard one of the Thoughtworks QAs arguing with a Tech Lead I thought – you can’t talk like that to a manager! And now I feel as if there’s no hierarchy – we respect each other but we really pushing each other as well.’
Despite the enthusiasm of those I spoke to, the process had not been plain sailing. Several people had disliked the new way of working; others had been nervous it was a cover for pushing people out; many admitted to being sceptical at the start. Everyone acknowledged that the learning curve had been exceptionally steep.
The So What? test
The recent launch of a new retail platform in Canada was a test case for how the transformation performed in delivering actual software and real products. The team had launched to beta in record time. They were gathering positive feedback on usability and design, as well as crucial learning about tweaks needed to the product mix. This last point was the essential one. Revenue alone would prove the real ‘so what’ test for the team’s transformation – would the new platform and products deliver a profit?
This highlighted a key learning. The team had wanted to launch an earlier version with fewer features and several backend processes being carried out manually. To some in the business this MVP had felt too sketchy and risky. Now, early feedback was showing that the number of orders could easily have been dealt with manually, while the extra features were completely unused. The key product learning could have been gained earlier. ‘By now,’ Darius Kumana commented, ‘we would not only have tweaked the mix, but we could have launched a second product, or to a new region – whatever was deemed more valuable. It would increase the likelihood of delivering the revenue we all want.’
So would the business learn the Lean lesson? Would they launch faster and learn through feedback next time?
On the whole, I was impressed by the willingness of those to whom I spoke to admit the mistake. ‘We are getting much better data through Agile, ‘ said Jason Duncan, Head of Retail and Overseas Finance, ‘it means our decisions will get better too. We can already see things we should have done differently and we’ve learned. Before, I don’t think we would have done. Reviews used to be a finger-pointing exercise – not about doing things differently.’
Spreading the Word
The team that stands out so much that they get ‘side-glances from people passing’, might soon become the norm. Many department heads had toured the Retail team, several board members had accepted invitations to take part in Brown Bag breakfasts.
Quite a few had seen tools and practices they felt might work for them. Other teams were beginning to adopt a much more visual approach – there was a gradual encroachment of post-it notes across grey walls and informal kanban boards were popping up in several places. The actuarial department might not be about to swap suits for jeans, but the Head had asked for help in setting up stand-ups and retrospectives. They were considering moving to cross-functional teams.
In HR, Emma Guojah commented on how they were changing recruitment practices in order to spread the word about the kind of developers they were looking for. ‘I talk to recruitment agents who simply don’t believe me,’ she admitted. ‘They have an image of us as boring. It’s great seeing that opinion change when candidates visit us.’
Continuous improvement?
Far from patting themselves on the back over the gains they had made, the team was looking forward to future changes. Darius showed me the plans of the new Markel building and talked through the changes he had agreed with the Head of Facilities after various talks at Spark the Change. ‘– The shiny new skyscraper on Fenchurch St (the walkie talkie) wais already a brilliant venue, but we wanted to focus on the little details to make it a more creative and collaborative space.’ Others discussed setting up ‘Communities of Practice’ to share ideas faster. Individuals were, unsurprisingly, focused on improvements in their specialities – faster releases, improved UX, better metrics, legacy extraction…
All of them felt that the next 6 months – as Markel made choices about how to apply its improved development capability – were critical for the company’s continued transformation. The Lean start-up model of fast feedback driving design was one which the IT team clearly grasped, but it remained a big leap for an organisation used to signing off each product well in advance.
In particular I wondered how other areas of the business would react as the development team took more ownership for user testing and understanding the customer. IT teams often talk about being ‘partners’ in the business. They occasionally forget that this means other functions need to re-envision the relationship as a partnership. Would those used to ownership over product and customers feel empowered by IT’s new confidence, or threatened?
Paul Jackman summed up the mood: ‘IT is no longer the blocker – now we need the business to get faster, more responsive and more innovative. Senior management will need to make faster decisions – all of us are going to have to change.’
The enthusiasm and determination of Markel International’s Retail Digital team was impressive. Somehow I felt confident they would propel Markel through those future changes. But heading out into Leadenhall Market, crowded with insurers and bankers in crisp suits, trailing briefcases stuffed with paper, I wondered how soon the rest of the industry would follow Markel’s lead.
About the Author
Helen Walton is co-founder of Gamevy, an employee-owned tech start-up with no bosses. They also run Spark the Change - a conference designed to help other companies consider management innovation and radical methods of working. Sparkthe Change runs in London and Toronto - follow @SparkConf. Helen is a marketer who has worked on brands in make-up, skincare, fine art publishing and financial services. She is also a professional writer with eclectic interests, meaning she has authored several books on Agile Software Management, as well as puppet and radio plays... She's always happy to debate these topics or anything else on twitter @helenislovely.