When it was introduced, the capability framework was a key milestone in the development of the digital and data function in the UK government. It includes the complete list of digital and data roles for which you can hire, and what combination of skill levels anyone in each of those roles should exhibit at different grades. The framework was meant to help by setting standards for hiring, creating transparent expectations on how pay and career progression are tied to skills, and establishing a compensation structure designed to be competitive with the private tech sector. These were worthy goals, and they have been largely met - but today the framework risks struggling to keep pace with how digital work is changing.
In my time as interim head of profession at the Department for Business and Trade, I was involved in reshaping the framework for data analysts. The process involved engaging with leaders across government, all of whom were competent and willing. And yet it took over a year, outlasting my time in the role, in part because different departments were pulling the same role description in incompatible directions. Some prioritised data governance expertise, others statistics, others business intelligence, making a single coherent definition difficult to land.
To get round these issues, more recently new roles are being proposed with fuzzier boundaries between them, such as analytics engineer (something between a data analyst, data engineer and data architect). These are also the subject of tortuous cross-government consultations. But still, the slowness of changes, and rigidity of these role descriptions dissuade departments from experimenting with new types of roles and processes.
Perhaps more worryingly, the status quo doesn’t set up the government to adapt to structural shifts in the labour market - in particular, the way AI is already reshaping what skilled workers spend their time doing.
A topical example is the convergence of product management and software engineering in the tech industry. Coding agents are already enabling product people to ship working software independently, while the best developers are increasingly expected to own business problems end-to-end rather than execute against someone else’s user stories. A product manager who can prototype and iterate without always waiting for developer time, or a developer who can engage directly with policy intent, could dramatically compress ideation and delivery cycles.
The current framework is not designed for this. Product managers are not expected to have deep familiarity with the tech stacks implementing their products, let alone contribute to them. And the only skill listed for software developers that gestures toward wider problem ownership is “user focus”, a thin proxy for what is actually becoming a core competency.
A skill-centric approach, similar to the SFIA framework, would give departments the mandate to compose bespoke role profiles from a shared library of defined skills rather than inheriting fixed job descriptions from the centre. A department handling sensitive personal data might combine foundational ML competence with advanced risk and ethics expertise and change management capability into a single role - or split and recombine those skills differently as their needs evolve.
More fragmentation, even within departments, would arise but this can be managed: similar but distinct roles could share a head of profession and communities of practice. Another possible objection is that the same coordination problems would simply reappear at the level of skill definitions. That’s partly true, but agreeing on the building blocks of a framework is simpler than agreeing on every role configuration centrally. Giving departments the mandate to experiment locally might produce a framework with a fair chance of staying fit for the future.