I sent out a newsletter today, which featured some links that I’ve pasted below for posterity.
However I’ve realised that I’ve written a few pieces on LinkedIn etc that I haven’t also published here, so will sort that out in the next day or so. Expect a sudden flurry of publishing as a result!
Following on from previous posts during the Great Local GDS Flurry from a few weeks ago (has everyone else moved on? Well I haven’t!), I thought I would follow up on one of my ideas for what I see as the central problems facing local authorities wanting to make the most of digital (by which I mean: technology, data, and online experience). Those problems are capacity and capability.
An answer to those problems is sharing of services. Now shared services often have a bad rep (in a lot of cases they are neither shared nor a service). But that doesn’t mean the model can’t work. It just means you have to do it right, and that doesn’t mean munging two or three teams together, sacking a couple of managers, then bagging the savings and carrying on exactly as before.
The right way is to methodically plan what functions are suitable for sharing, that will deliver benefits like efficiency and economies of scale, and not forcing into a shared arrangement something that just doesn’t belong there – or at least, not yet.
It strikes me that Wardley mapping could be very helpful here. I’ve been a massive fan of the approach for years, but have never actually used it in anger, largely because my brain is too small to cope with it. Here’s a video where Simon calmly explains it all.
The broad points are this:
There are no one size fits all approaches to any kind of business capability, but especially not technology ones
The more established and commoditised a capability, the better suited it is to things like shared services or outsourced arrangements
The more innovative a capability, the more suited it is to being kept close to the organisation
Likewise, the closer a capability is to affecting the experience of your end user, the closer you want to keep it to the organisation. If it is back-end gubbins, then that’s more suitable to being handled by someone else.
It is also possible for capabilities to move as they mature or become commoditised. So the way things are today don’t have to be the way they are tomorrow.
OK! So bearing that in mind, how could we think about applying this thinking to digital capabilities within a Council?
I’ve produced a dumbed down Wardley map to help guide this thinking. It isn’t comprehensive by any means, but hopefully has enough in it to get the point across!
I find having a grid approach helps organise my thoughts around this a bit. It means you lost a bit of the elasticity of the original Wardley approach, and if you find that annoying, no worries! You don’t have to do this the same way I do.
So the darker orange box in the bottom right is where sharing of digital capabilities ought to start on day one. These are utility-like components that have little impact on the end user and where real economies of scale can be achieved by organisations joining together.
After that, councils could start exploring the other boxes, depending on their context and ambition. There are some areas that should be left well alone, at least until they can be shifted rightwards in some way – either the market and the organisation’s experience matures, or the organisation is able to change the way it works to facilitate a rightward shift for that thing.
Now, we could all have an arm wrestle about which of these capabilities fits in what box, and I dare say that some local customisation will be required depending on context (some councils have insanely complicated bespoke arrangements around laptop builds, for example). But it feels like a handy tool to use when planning collaborative endeavour, whether formal shared services or not.
I absolutely love this – a Chrome browser extension that lets you play Breakout against your Google Calendar – bash the ball into the appointments to destroy them! There’s even an option to automatically decline the meetings you destroy! 😂 Tempting….
This is a re-publish of a thing that went on LinkedIn, my newsletter, and the Digital Leaders newsletter. I’ve backdated the published date on this post to reflect this.
Summary: all this tech called ‘AI’ is genuinely exciting. But the impact of it is unlikely to be felt for several years. Don’t expect quick results, and don’t expect them to come without a hell of a lot of hard, boring work first.
It’s hard to look at LinkedIn these days without being instantly confronted by AI enthusiasts, almost foaming at the mouth as they share their vision for how the public sector can save millions, if not billions, of pounds by simply using AI.
It sounds so easy! As a chief executive I would be reading this stuff and thinking to myself, ‘why the hell aren’t my people doing this already?’.
In fact, I am hearing from digital and technology practitioners in councils all over the country saying that this is happening. That the AI hype is putting pressure on teams to start delivering on some of these promises, and to do so quickly. I find this troubling.
It’s always worth referring to my 5 statements of the bleedin’ obvious when it comes to technology in organisations:
If something sounds like a silver bullet, it probably isn’t one
You can’t build new things on shaky, or non-existent, foundations
There are no short cuts through taking the time to properly learn, understand and plan
There’s no such thing as a free lunch – investment is always necessary at some point and it’s always best to spend sooner, thoughtfully, rather than later, in a panic
Don’t go big early in terms of your expectations: start small, learn what works and scale up from that
How does this apply to using AI in public services? Here’s my take on the whole thing. Feel free to share it with people in your organisation, especially if you think they may have been spending a little too long at the Kool Aid tap:
The various technologies referred to as ‘AI’ have huge potential, but nobody really understand what that looks like right now
Almost all the actual, working use cases at the moment are neat productivity hacks, that make life mostly easier but don’t deliver substantial change or indeed benefits
Before we can come close to understanding how these technologies can be used at scale, we need to experiment and innovate in small, controlled trials and learn from what works and what doesn’t
Taking the use of these technologies outside of handy productivity hacks and into the genuinely transformative change arena will involve a hell of a lot of housekeeping to be done first: accessing and cleaning up data, being a big one. Ensuring other sources for the technology to learn from is of sufficient quality (such as web page content, etc) is another. Bringing enough people up to the level of confidence and capability needed to execute this work at scale, for three – and there’s a lot more.
The environmental impact of these technologies is huge, and many organisations going ham on AI also happen to have declared climate emergencies! How is that square being circled? (Spoiler – it isn’t.)
The choice of AI technology partner is incredibly important and significant market testing will be required before operating at scale. There’s an easy option on the market that is picking up a lot of traction right now, because it’s just there. This is not a good reason to use a certain technology provider. Organisations must be very wary of becoming addicted to a service that could see prices rocket overnight. More importantly perhaps is whether you can trust a supplier, or those that supply bits of tech to them, to always do the right thing with your data. There’s always going to be an element of risk here: but at least identify it, and manage it.
Lastly, the quality of the outputs of these things cannot be taken on trust, and have to be checked for bias, inaccuracies and general standards. Organisations need to have an approach to ensuring checks and balances are in place, otherwise all manner of risks come into play, from the embarrassing to the potentially life-threatening.
This ended up being a lot longer than I first imagined. But I guess that just shows that this is a complex topics with a whole host of things that need to be considered.
Just remember – any messages you see claiming that AI is a technology that takes hard work away for minimal investment or effort, is at best just guesswork and at worst an outright lie.
Related to this post is a set of slides I presented to a conference in Glasgow:
This started off as a daily not for Monday, and has been sat in draft all week as I add more and more to it…
Had a proper chance to watch this and read about it – “Place-Based Public Service Budgets: Making Public Money Work Better for Communities”. Nice bit of big picture thinking around local public services. We need more of this sort of thing.
This is an interesting piece about YouTube and how content creators chase the revenue, resulting in a worse experience for viewers, and how this is resonant of the way the web went.
Nice video from Giles Turnbull, giving a talk to folk from the state government in British Columbia about using the human voice in communication.
The Future Councils Playbook is a “set of tools to help you understand complex problems and their impact”. These are useful of course, and as much good practice support we can get out there the better. But a step change in local government digital quality is unlikely to result from such things – we need more.
More Simon Wardley – this is a fun new intro to his mapping, etc:
Yesterday I made use of Colin Stenning’s excellent local gov CMS research to help write an options appraisal for a council’s new website technology. What a legend!
…Along with the need for a less hyperbolic and more scientific approach to AI itself, the current state of government data isn’t exactly ideal for implementing AI given it relies on access to high quality, accurate data and metadata. But the National Audit Office reports that government “data quality is poor” and “a lack of standards across government has led to inconsistent ways of recording the same data.”
A minor innovation in these daily notes – pulling out the occasional quote from some of the links, and then using a horizontal line to provide some separation. Also using the lines to make it clear when a multiple-paragraph comment from me is over.
In its current state, generative AI breaks the value chain between creators and consumers. We don’t have to reconnect it in exactly the same way it was connected before, but we also can’t just leave it dangling. The historical practice of conferring ownership based on the act of creation still seems sound, but that means we must be able to unambiguously identify that act. And if the same act (absent any prior legal arrangements) confers ownership in one context but not in another, then perhaps it’s not the best candidate.
In a conversation today I got to reference the chicken and pig analogy around project managers, which is something I haven’t done in ages.
I was differentiating between those project mangers without domain knowledge who coordinate, document, follow up on actions, make sure stuff happens, but who don’t really have skin in the game in terms of the outcomes of the project.
Then there are those who really care about the thing they are working on, who are really committed to it succeeding in the long term.
Chickens aren’t always bad and they really do have uses in the right context, but it’s important to know whether you need a chicken or a pig PM on a certain project because it can have a real impact.
Maybe the most interesting changes are not in the tools that we so readily focus on, or our methodologies and approaches to innovation and improvement. Maybe we should be paying more attention to the most valuable of resources, the humans, and how we think, behave and work together for change.
Can anyone be confident that a local government software scandal isn’t on the horizon*?
One thing I have been mulling on following the recent – and much belated – focus on the Post Office Horizon scandal is just how much assurance any organisation can have in its core line of business systems.
The implementation of supposedly off the shelf software inevitably involves the kinds of customisations and bespoke code that caused problems (not all of them, but a fair few) for Fujitsu and the Post Office, and of course the people who suffered the consequences.
Where there are systems in use in local councils which handle similar workloads – revenues and benefits, social care systems, finance and payroll systems, to name a few – how confident can we really be that errors and bugs aren’t causing major issues, that for whatever reason lie undetected?
This from Dai Vaughan is really excellent on how technology failures keep damaging people’s lives, and how frustrating it is that the answers to this problem are well known, but unevenly implemented.
A slow start to the year, blogging wise, been getting other stuff up straight. So here’s a bunch of things I’ve spotted during the last few days or so…
The delightful people at Lincoln Council are hiring a Web / Digital Officer. Lovely place to work on exciting local government things!
I have had to replace my several years old Apple keyboard, and couldn’t justify to myself the nearly £100 cost of the official one, so picked up a Logitech version for a third of the price. It is taking a bit of getting used to and the resultant loss of productivity is alarming.
Substack’s Nazi problem seems to be getting a lot of attention at the moment. It’s a weird one for me, because I just don’t see it. It was a bit like that for me on Twitter as well, lots of people would say how toxic it was, but that just wasn’t my experience. Doesn’t mean I shouldn’t care though! Of course, after the Musk buyout it ended up being the case that my experience on X was very affected by the unpleasantness, which is why I now pretty much never look at it.
Substack has a great writing experience, and it’s free, and it makes it easy to send e-mails to people that are nicely designed and readable. That obviously comes at a cost and I wonder if the adage that if a service is free, then you are the product needs amending to something like, if a service is free there are probably some shitheads paying on your behalf and that makes you a bit of a shithead too.
I’ve no doubt I will have to move my newsletter away from Substack at some point. It’s a faff though and the alternatives aren’t obvious. Maybe I could use my new WordPress emailing setup to DIY it? Doesn’t fill me with joy, I have to say.
Am playing around a bit with Feedland, Dave Winer’s newish RSS aggregating thing. I like how it is all public, so anyone can see the feeds I subscribe to and what is in them. Am enjoying the desktop app feel of NetNewsWire for now, so don’t think I will be switching, but it’s fun to play 🙂
The next step for government as a platform is to directly help services transform. We’ll do this in two ways: first by going much further to help people make better design decisions for their services, and second, by helping services continually optimise themselves.
“The Transforming Government Services team in the Central Digital and Data Office (CDDO) is redesigning the products and services offered to other government departments to support the delivery of their services. This includes updating existing standards and guidance, so that more services are implemented to a ‘great’ standard.”
Bit of an old chestnut, this, that I referred to in another post and I have been mulling on for a while.
User feels a bit techie, a bit too transactional, and sometimes like somebody who indulges in illicit substances. However it is delightfully generic.
Customers tend to have somewhere else to go, unlike many of those who engage with local public services. It does have it’s benefits though – it works for businesses and communities as well as individuals, and it is helpful to get colleagues to take improving the ‘customer’ experience seriously.
Citizens is a very complicated term in the UK, and besides, many of the people we work with are citizens of other places, not the UK.
Residents is one that I have liked for a while, but it doesn’t cover people who commute in, or visit for other reasons.
Businesses and community groups need to be factored in and the more individual terms don’t really cover this base. In work in the past, I have used the long and rather awkward ‘residents, communities, and businesses’. I now look on this period with a sense of shame.
On LinkedIn, Craig Hervey from Solihull asked why we don’t just use ‘the public’ – and he had a point. On mulling this though, I find the need for the definitive article a bit clumsy sometimes, and often plain old ‘public’ sounds just a bit weird.
On a current project working on digital strategy for a small local authority, I’ve needed to come up with a term to use, and this time I am trying to stick with ‘people’. Sometimes it can appear vague, which is a problem, but I then do a bit of work on the rest of the sentence to try and provide any additional context that is needed.
So that’s that, for now, for me. Those who engage with local public services are people.
I’m barely posting any links into Raindrop. I just like linking to them here, on my blog. But I worry they get lost. Not that I ever seem to look for them.
A few teams were very mature in their prototyping practices. When they needed to move fast, try out loads of ideas and surface issues quickly, they used low-fidelity prototypes in paper, Powerpoint, and Mural or Miro. These helped them test out different journeys and flows. They progressed to Figma and Prototype Kit when they needed more fidelity or to test out technical approaches.
More good stuff from Steve: all of this post is worth reading, but the section on Cycles, not sprints is great:
For research and development work (like discovery and alpha), you need a little bit longer to get your head into a domain and have time to play around making scrappy prototypes. For build work, a two-week sprint isn’t really two weeks. With all the ceremonies required for co-ordination and sharing information – which is a lot more labour-intensive in remote-first settings – you lose a couple of days with two-week sprints.
Sprint goals suck too. It’s far too easy to push it along and limp from fortnight to fortnight, never really considering whether you should stop the workstream. It’s better to think about your appetite for doing something, and then to focus on getting valuable iterations out there rather than committing to a whole thing.
This is a great story, about the wonder that was Yahoo Pipes, beautifully told… and now I am really interested in Retool, so I guess it did its job (tech marketers, take note)!
We kicked off with an open call to join an online workshop, and had over 120 participants attend from dozens of government organisations. This helped us to understand the diversity of ways in which the task list pattern was being used, from application forms to case management systems, as well as collecting research findings, and user needs that the pattern was helping with.
From the workshops a smaller group, comprising designers and researchers from across different government departments, was formed to work on iterating the actual design.
Collaborating in this way wasn’t always fast – the work had to be fitted in around everyone’s main roles – but a dedicated Slack channel and semi-regular calls helped to maintain momentum.
Not been looking forward to today really. I have to go to see a foot specialist about an ulcerated wound on the balls of my right foot. It’ll be good to start getting it sorted, but it involves going somewhere I have never been before, not sure about parking etc, and the whole thing fills me a bit with worry.
The challenge now for design in policy – I like a lot of the stuff in this post, which includes lessons that work for many relatively new disciplines, not just design.
I’ve been moving a few of the sites that I manage away from a simple shared hosting arrangement onto something a bit more proper, with Steph’s advice (this blog, being incredibly simple albeit with a fairly hefty archive going back to 2004 or something, remains on the shared hosting for now). The new ‘platform’ is made up of using SpinupWP to manage the setup of the servers and WordPress itself, which is all hosted on DigitalOcean, with all the benefits that come from having this kind of control over the environment.
One area that has been causing me some worry is around sending emails out of these sites. The emails that WordPress sends, like password resets etc, can be a bit flakey in getting delivered at the best of times, but to make it more complicated, SpinupWP doesn’t install a means of sending emails itself, you have to configure your own, using an email sending provider like Amazon SES or Mailgun. It sounds complicated – and it is, in a way – but there are plugins and things to make it easier.
I’ve played with a few ways of doing it, but think I have settled on one, that I will now move all the sites onto over time. I’m going to be using the WP Mail SMTP plugin to get everything set up and working, and linking it up with SendLayer to do the actual emailing. When setting these things up, you need a domain to use, and each one needs configuring in SendLayer. To make life easier for myself, I have registered a specific domain to use for this, and so emails will come from sitename@davesemaildomain.notreal, which hopefully will keep things simple.
Lloyd mentions how he likes writing the date at the top of his daily posts, as it reminds him of school. It does me too, on these posts, but also on the daily notes that I write more religiously using my Kindle Scribe. I am writing a log of pretty much everything that is happening, or that I see, or think, that feels particularly meaningful. It’s a marvellous aid to my memory, particularly as I discover more about how I struggle retaining information a lot of the time.
Indieblocks could be an easy-ish way of doing my preferred way of blogging through chunks and links in WordPress, maybe.
