Ditch product frameworks and start listening: Bridging the empathy gap in big organisations
Standard frameworks and tools are little help when it comes to getting non-digital stakeholders to support your work. Stop preaching Agile and start modelling it by listening, observing and adapting.
A few years ago at the Department for Education, my team and I were given the opportunity to work in a policy unit to get to the bottom of why a flagship programme for new teachers had not landed as hoped, to ensure its next iteration better reflected the reality in schools. As with many government policies, it had been launched at scale, at speed, and under extreme pressure.
While leadership wanted bold changes and were keen to see what a user-centred design team could achieve, those who’d been working at the coalface of policy had been through the wringer with ministers and had seen UCD teams come and go. Confidence in Agile ways of doing things was low.
So how could we avoid falling into the same traps as those who’d come before us?
A lesson in humility
At least part of the answer came in the form of a one-page document pulled together by a very wise colleague. It summarised the sentiments of policy colleagues who’d been involved in discovery work with user-centred or ‘digital’ teams. To paraphrase: digital discoveries spend 3 months blissfully free of ministerial pressure, in an alternate reality where all things are possible, the only consideration being end user experience, and at the end a 150-slide deck is produced, telling us what we already know, but can’t action.
Ouch.
But this document was a gift — a map of potholes to avoid. It forced us to reflect on how we (or teams like us) may have operated in the past, and encouraged us to think deliberately about the way we wanted to work so as to (re)build trust and confidence in Agile values.
We needed to demonstrate a mindset shift, from one of ‘product missionaries’ to one of bridge builders.
Here are some of the things we did deliberately as a result:
Listen first
We were arriving in a part of the organisation where many people had worked for years and knew the landscape well. We wanted to build on, rather than duplicate others’ efforts, mindful of the feeling among many that precious time and resources had been wasted in the past. To do that, we needed policy colleagues to see their own thinking and experience in our work.
An initial ‘hopes and fears’ session surfaced how past experience of digital teams; intense, top-down pressures and determination to do better for teachers were all contributing to feelings of trepidation.
Starting each stage of work with internal stakeholder interviews to capture existing knowledge gave us confidence that we’d be extending, rather than duplicating, past work.
Communicate clearly, boldly and with empathy
We knew previous discoveries in the policy area had left people feeling bruised, with work happening in parallel, teams seemingly speaking different languages and consequently lacking shared understanding. In digital delivery the rough-and-ready-ness of show and tell presentations is often considered a virtue; here we could not afford to create barriers or alienate colleagues with unfamiliar language or missing context.
We designed our communication and presentations to be understood and acted upon by someone with no prior experience of digital or Agile. This meant continually reminding colleagues of the ´why’, our mission as a team, the approach we were taking, and our hypotheses.
We frequently reviewed each other’s outputs and challenged each other to say it — or show it — better.
We acknowledged publicly and often the hard, pressured work from policy colleagues that had gone before.
When we misstepped or hit a nerve, we adapted. For example, when a theme emerged around the programme’s funding model creating perverse incentive this turned out to be a pretty incendiary term. We quickly switched to the less dramatic ‘unintended consequences’ — and kept digging.
Tell a compelling story in chapters
If we wanted to take policy stakeholders on the journey with us, we needed to hold their attention throughout, rather than drop a big presentation at the end and leave them to join the dots.
Working in chapters or ‘bursts’ of around 4 weeks allowed us to tell complete stories, drawing on multiple data sources, bring insight to life and suggest how it could be actioned.
We’d commit each burst to solving a particular mystery or breaking down a particular aspect of the problem space.
This lent itself to compelling communication — people came to hear about a topic they could understand, and we used this genuine engagement to reiterate how we were working and why.
Build trust with proximity
We needed to operate within policy teams’ spaces, not just in the comfy world of Slack.
We actively made ourselves part of their day to day, rather than inviting them to our stand ups and hoping they’d keep up.
We planned our playbacks around our policy colleagues’ availability so the sessions could be opportunities for questions, input and challenge.
We took findings ‘on tour’ to other parts of the organisation, to ensure our insights were understood by people whose work could benefit from them.
We left deliberate space for reflection and input from others. This all meant slowing down, investing in relationships — and building bridges.
Look to the future, where no one is at fault
In the murky world of legacy systems, it helps to remember that legacy is more about people than technology. We want to solve problems, make sure what comes next serves everyone better. That’s hard to do without suggesting someone got it wrong the first time around.
Workshopping a desirable future state with colleagues from different parts of the system (contracts, delivery, policy, finance…) helped us lay aside how things had been done in the past, and encouraged us to imagine what better could feel like and why. This made for productive discussion because the future is no one’s fault, and everyone usually wants better.
Acknowledgements
None of the work that my team and I did would have been possible without leaders who were willing to try a new approach despite the high stakes, and who continued to support us even when things got uncomfortable.
Thanks also to Veronika Jermolina, for her helpful feedback on this blog. She’s written more broadly about our team’s work at DfE in two excellent pieces:
Get in touch for a chat
If any of this resonates with you and your journey in product management and leadership I’d love to hear about it in comments, or you can arrange a free initial chat with me about coaching.
