A question was asked about structures in the LocalGovDigital Slack group last week, and I thought maybe it would be worth me sharing and elaborating on my response to you lot.
The initial question was around where ‘digital’ sits - is it with ‘IT’? Or on its own? Or with customer services? Or communications? etc.
My thinking on this has evolved just a little bit over the last few years. Some of this is about organisation design, and some of it is about semantics.
First - I don’t think there should be a ‘digital’ team at all. Interpreting the definition of digital as being about how we do work and how we think about work rather than specific roles or activities, as I do, means that it works best more as a descriptor of culture rather than an organisational unit. A bit like how I sometimes prefer to talk of D:DDaT rather than plain old DDaT.
So:
Absolutely your traditional IT function has to be integrated and fully aligned with your new, ‘digital’ roles. In terms of which takes the lead - ideally you have a person who has a foot in both camps. If you don’t, then whichever area best embodies the new culture you want to embed should take the lead.
In terms of vertical structures, put in place collections of disciplines or practices. My preferred breakdown would be technology, design, data, and delivery.
The purpose of these groups are to develop great practice in all of these disciplines. They are not units of delivery of work however! The ‘Heads of’ stop apportioning work to their teams and instead focus on developing people and practice.
Instead, work happens in horizontal delivery teams, made up of people from across the various disciplines.
Some of these teams will last longer than others. Some will exist for a short period of time: come together, do a thing, move on. Others will stick around for longer, maybe even permanently - such as if there’s a genuine product that needs managing long term (oh which there are not many in local gov).
There’s no ‘web team’. The website is a product (see above bullet).
If you’re a smaller council, have two teams - technology and design. Bits of data and delivery go in each one (don’t just squidge all of data into technology, and delivery into design, for example).
Each bullet (and I am bound to have missed some) in the chart above are capabilities rather than jobs. It’s best to have dedicated expertise in these things, but not every organisation is big enough to justify it. But you do need people who do this stuff.
Also - the work you do, particularly in the technology space, will impact on the numbers of people in each practice as you progress. For example, application teams are often very large, however, as software-as-a-service applications replace traditional ones, your need for those people will reduce. Similar cases will exist for other disciplines too. Make sure you design for that.
Key to making this work is a fundamental shift in terms of thinking about what teams are, what vertical organisational hierarchies are good at, and what autonomous multi-disciplinary delivery teams are good at.
As well as getting the structure in place, you’re also going to need to finally get round to tackling one or two pesky issues:
Governance - for this to work you have to get a grip on the pipeline of work, how it is triaged, assessed, prioritised and resourced. You need to land on a approach to decision making that is lightweight enough so people don’t try and avoid it, but heavyweight enough to ensure things don’t become a free-for-all.
A big part of this is getting the funnel right - the way into making requests. This has to be designed to ask for the right amount of information at the right times. Lots of teams ask for service areas to produce business cases to accompany requests, which feels far too heavy handed to me. Ask for the minimum viable amount of detail at each stage.
BAU - ‘business as usual’ work has been the bane of my life for several years now. It’s like a magic formula which means a bit of work has to be done right now, no matter what. Being asked to work on project X, which you don’t fancy and would rather tinker with project y instead? Just claim it’s BAU and nobody can do a thing about it! The delivery team driven model is based on the vast majority of work being classed as projects, and prioritised accordingly. Very little work should ever be classed as BAU, outside of things that literally take minutes. Someone in a service area wants a new field creating? Or a report generating? Triage it and prioritise it, don’t just let individuals take the burden of deciding this stuff onto their own shoulders.
So an awful lot of this isn’t about the structure itself, but how people work within the structure. A huge part of this is breaking the link between vertical practices and horizontal delivery teams.
Let me know if this helps, or if you have some challenges to my theory!
Author: Dave Briggs, Chair, LocalGovDigital
留言