Developing a progression framework for Design, Data and Technology at Citizens Advice
Over the last 3 months, we’ve worked closely with Emily Webber at Tacit to develop a progression framework for our teams — and experimented with a new approach to defining our disciplines.
Why a progression framework?
When I joined Citizens Advice last September, the Design, Data and Technology teams had already been a single integrated function for a few months (more about the context here). During this time, the teams had developed some new, joined-up ways of working, and set up a range of communities of practice to help articulate the skills and behaviours needed from our capabilities. However, our staff survey results told us there was still something missing — for example, having greater clarity on how the various disciplines would slot together in multi-functional teams, and more transparency in how people could progress and develop.
Last year, our People team was doing some work to describe the job families we have across our organisation and the skills we support people to develop within these. To complement this work, last November we decided to explore this more closely within our team, and to develop a full progression framework that would encompass all our disciplines and roles across Design, Data and Technology.
Our objectives for this work were:
- To deepen our capability model: which disciplines do we currently have, and which ones may we be lacking? How can we have consistent expectations from everyone, but also allow for flexibility in how different teams work?
- To give more transparency to the people in our teams: what is needed to progress through a discipline? Which options for personal development are open to people, and how can we decouple professional development from seniority (and even more so, from line management)?
- To break down any remaining barriers between our teams: as in every other organization that brings together ‘digital’ teams with a variety of backgrounds under one banner, at times we have different ways of working. How can we make sure this is an asset for us and encourage more meaningful collaboration?
What happened in 3 months?
We kicked off the work by holding a workshop to define the list of disciplines across our department; we then discussed this list with our teams, and came up with a co-designed description for each discipline.
Our initial plan was to follow this with draft role profiles for each discipline; and to then move into a deep dive for a small number of disciplines, which would further define roles at different levels of expertise while creating a repeatable process that we could roll out across our entire department. But once we started to compare these, Emily suggested that there could perhaps be a more interesting and collaborative approach: looking at each role within the context of all the disciplines that make up Design, Data and Technology.
We’d always started from the agreement that everyone in each team needed, at a minimum, to be aware of all the disciplines we have — but in this new approach, we deepened this thinking to explicitly reflect how in most cases, roles need to have at least some expertise in other disciplines, too.
So for example, our Service Designers would need to be competent in most elements of User Research. But perhaps less obviously, our User Researchers might also need to be ‘novices’ in Information Security capabilities. In this framework, no role was isolated from the others: disciplines and capabilities became an intertwined network, connecting teams on the basis of their assets and strengths. The model became a prism through which we could look at each one of our teams, but equally at the full picture, through different lenses.
What did we learn?
It was immediately clear to us how powerful this approach would be, and how well-suited to our needs.
Firstly, it’s a lot more fluid than traditional progression frameworks: it allows us to scale things up or down within disciplines, as well as to create new roles starting from those we have and never from scratch.
Secondly, it makes it clear for our teams how progression and development don’t have to be synonymous with becoming someone’s line manager or getting a more senior job title: if all disciplines and roles are seen and understood in relation to each other, then development can mean spending some time in a role ‘adjacent’ to yours. Perhaps a Delivery Manager will decide to explore Product Management, for example — and an Evaluation Analyst may want to spend some time in User Research. We’re now thinking of ways in which we can encourage this flexibility: helping our teams develop, and helping us respond better to what our organization needs from us.
Most importantly, having been part of similar initiatives in other roles, I found this approach incredibly valuable because of how it shifted our focus from uniqueness to community. Too often skills frameworks become a way for teams to count the ways in which they are special and different from anyone else in their department or organisation — but Emily’s new approach pulled our conversations in the opposite direction. It helped us relate more to each other, appreciate our shared strengths, and look at our overlapping skillsets as a source of strength and opportunity rather than something to defend.
What happens next?
Of course 3 months is not nearly enough to fully develop and embed a progression framework. Some of our teams have had the chance to spend more time on this, and their work is quite advanced; others will need a few more weeks to finalize their thinking. But we intend to review the work every 6 months, and to use it as an opportunity to bring teams back together with a shared purpose. And we’ll keep working with our People team colleagues as they evolve their own approach to job families, particularly around core capabilities that we should integrate within our framework.
From the beginning, both Emily and I wanted the framework to be shared and transparent inside and outside of Citizens Advice, and that very much remains our plan, so we will publish the full framework in the open when it’s ready.
In the meantime, we’d love to chat with anyone who is thinking about these same topics, so do get in touch!