Daveslist Volume 3 Issue 13 💼
Daveslist Volume 3 Issue 13 💼
Structural considerations
Greetings!
I got a little pushback on my last newsletter for not mentioning the obvious thing you can do about legacy technology - which is to replace it with something better. I probably should have started with that, rather than taking it as read and diving headlong into what you can do if you can’t replace it - either right now or ever.
It’s a point worth making though - there are suppliers out there trying to make better, modern software, and we should all make the effort to see how they might be able to help us solve our problems.
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.
I’m always delighted if the things I write about are of use to people. Sometimes folk need a bit more help - in which case my advisory services might be just the thing they are looking for.
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!
This issue’s links
I’m organising a little collaborative project, called the New Council Website Playboard. Am aiming to put together an open, freely-accessible Trello board listing all the stages and the steps within the stages that a council ought to go through as it puts together a new website. If you would like to join in, just send me an email.
The Local Digital team at DLUHC are running a thing called Future Councils, and that work has produced some shared problems statements that they believe are facing the local government sector, and holding back its ability to modernise using digital and technology etc. You can feed back on them here.
Laura Hilliger, Doug Belshaw and Matt Jukes all on the same podcast? 😍
I wrote up a quick note about why I am cautious about the use of AI / LLMs in local government (in particular).
“Focusing on just outcomes leads to whacky tech decisions” – more along the ‘it’s not not about the technology’ lines.
“Lessons for implementing digital health technologies”
I quite like this distinction: “Federation vs Small Pieces Loosely Joined”
Lots of stuff coming out about how Chrome is increasingly unethical as a browser, what with its data collecting and whatnot. Mark, amongst others, is using Firefox, which as a suggestion feels delightfully old school to me. Handily, Mozilla have just published a guide to switching from one to the other.
That’s it for this issue. Don’t forget to hit reply if you have any feedback, or forward this on to anyone you think may enjoy it.
Until next time,
Dave ❤️