After last week’s howl at the moon, I’m trying to get back into the habit of weeknotes, so I can do the valuable journalling and reflecting that makes things better.

I’ve a fairly sedentary weekend ahead, looking after my partner who’s recovering from surgery and doing my company accounts. The stack of receipts to file isn’t huge, but there’s some accounting admin to be done.

Anyway, what did I do this last week?

Switching roles

As one of our product managers is leaving to join the BBC, leadership have asked me to step in and take over the product management of Extract, leading the product through its alpha and a probable beta.

Until this week, only two of us have been working on it on the MHCLG side: our product manager who’s leaving and me. And we haven’t been able to do much beyond scoping risks and shadowing a few local planning authorities. But we’ve finally been able to onboard a delivery manager, a designer, a frontend developer, and a user researcher is on the way too.

I won’t write much here about what we’re doing because we’ll be publishing weeknotes and you can read the first one now. We’re keen on sharing insights, learnings, methods, new designs and the results of testing, as much as possible to feed into the growing body of work on AI-enabled services in government. I’m grateful to our colleagues in leadership and communications who are supporting us in doing this.

But I’ll reserve the right to have personal reflections on the work here, in my own space, views which don’t necessarily represent the views of my client(s) and the people I work with.

OK, disclaimer out of the way, what are my thoughts?

Aligning two teams

The tricky thing I’m working through now is aligning two teams, where one is ahead of the other so they’re out of sync, working at different paces, and using similar but different methods. Like a car chase scene in a film, except it’s a people carrier razzing it down the motorway, trying to catch up with several motorbikes weaving and slaloming through traffic.

It shouldn’t be too hard, and I think I’ve got my mental model correct so that the two can join together. The i.‌AI team are developing the AI capability in the backend, and we’re developing the user experience and functionality in the frontend, the two joining via the API in the middle. The sooner we can get these two pieces joined as a whole, the sooner the two can be iterated in tandem, reducing divergence. But we’ve got clever people who can move fast, and we know we need to test this thing for real, so the conditions and mindset are appropriate for the task.

Team dynamics after AI

Last weekend, I finally got around to reading Duncan’s piece from Agile Cambridge.1 It’s very articulate and describes well the danger of vibe-coding your way to delivering something without establishing a feedback loop between users and a context.

He makes a good argument for understanding the dynamics of a domain, feeling its material, before rushing to solve problems in it. And that’s how we set up our working relationship with i.‌AI on Extract (which Duncan also references).

What’s important is understanding what problems you’re there to solve. As I said above, my mental model is that i.‌AI is solving a technology problem, proving a concept that AI can be used to extract geospatial data from PDFs and documents containing maps. But the product and design problems – whether it’s a valuable problem to solve, and how to solve it in a way that works well for people – is our job. We’re each working in our domains of expertise.

I remember speaking to Giuseppe in 2021 when he was leading the AI Skunkworks in the NHS. He told me that after incubating a technical solution, they had to do all of the discovery-alpha-beta work to understand how that needs to land in a context, how it becomes valuable and usable. That’s how R&D works: you iterate toward solving a problem in lab-like conditions. But that’s not enough. You’ve got to do the work afterwards – understanding the real-world constraints, building trust, and ensuring the solution fits.

This is how you can innovate with intention. Don’t rush a solution through. Do the work of creating a dialogue between a service, its users and a context (as Tom says).

The real threat, as Duncan’s piece points out, is the language of inevitability around everything. It creates an environment where failure isn’t allowed, learning isn’t rewarded, and context isn’t considered. AI isn’t a magic wand. Success requires permission to fail, context-aware iteration, and a partnership between technical and domain expertise.

The craft, the iteration, the collaboration, that’s where the magic happens, where the rough becomes the smooth. It takes more time, it’s not immediate, but it’s much more valuable.

‘Not all projects take time, but they do take a lifetime. In calligraphy, the work is created in one movement of the brush. All the intention is in that single concentrated movement. The line is a reflection of the energy transfer from the artist’s being, including the entire history of their experiences, thoughts, and apprehensions, into the hand. The creative energy exists in the journey to the making, not in the act of constructing.’ – Rick Rubin, The Creative Act

AI as normal technology

Arvind Narayanan and Sayash Kapoor wrote this paper on AI as normal technology, which is long but oh-so worth it. It articulates how I use the boring magic mindset to view technology.

What I like about it is that it’s addressing two viewpoints: the overwhelmingly for and the overwhelmingly against. Like I said earlier, the language of inevitability is not helpful as it doesn’t allow for hypotheses to be proven wrong. But the rhetoric around AI being abhorrent – which they call ‘non-proliferation’ – isn’t helpful either, as it doesn’t allow for hypotheses to be proven right.

A realistic view, founded on AI as a normal technology, is a route forward. No hype, no hyperbole, just finding what works.

I’ve made lots of highlights and will likely write separate notes, but I wanted to pull out one highlight.

Moving beyond the government’s role as a regulator, one powerful strategy for promoting AI diffusion is investing in the complements of automation, which are things that become more valuable or necessary as automation increases. One example is promoting AI literacy as well as workforce training in both the public and the private sectors. Another example is digitization and open data, especially open government data, which can allow AI users to benefit from previously inaccessible datasets. The private sector will be likely to underinvest in these areas as they are public goods that everyone can benefit from.

There’s a piece I want to write about the pre-requisites needed for different AI use cases, but the above is what I describe to people who ask about AI in planning. Making planning data openly available will distribute the potential for innovation more evenly, and help with the diffusion of new technologies and more efficient workflows. Otherwise it’ll all be centred around a few authorities and their big suppliers.

A day in town

Had a lovely Saturday with Nikin and my girlfriend last weekend. We went to see the Jennie Baptiste exhibition at Somerset House, followed by a listening party at Rough Trade for the new Tortoise album. Nikin took a lovely photo or two. Negronis at Bar Termini were delicious, followed by dinner at Camille.

Ideal.

Running

Things have been a bit up and down recently. Last year’s hip injury started bothering me again, and my right hamstring is tight. Rather than think about these as individual issues, I’m looking at them as interrelated symptoms that exacerbate each other.

To counteract it, I’m doing a proper warm-up before a run, lasting about 8 minutes, which loosens up the hip flexors, hamstring and the rest of my leg. I’m focusing on form, trying to pull my hips forward while running to avoid overstride. And I’m focusing on pulling knees up and pushing feet off.

It’s quite hard to adapt my form because my biomechanics are quite set. I’ve been running a particular way for ages. But I need to work on it to prevent worsening the injuries. (Also need to work on glute and core strength.)

Bookmarks

• Design by cliché, 4 mins. Another good bit from Duncan that describes why so many CRM projects fail.
• The Majority AI View, 4 mins. Follows on from viewing AI as normal technology. Most tech workers think AI is useful but overhyped and being forced on people. They worry real critiques are ignored and fear speaking up because of industry pressure. If we listened to these moderate insiders, we could build less centralised, more responsible AI.
• There’s no such thing as a universal digital service, 8 mins. The ever-excellent Rachel Coldicutt cutting through comms bluster and memes. She advocates for design to start by meeting the needs of the most excluded, then expanding to include the majority. That’s where we wanted to start with Personalisation but we were pushed to look at the ‘Starting a business’ area.
• Who knew? How Starmer kept his digital ID plan secret for months, 6 mins
• Mapping is thinking, 3 mins
• The work is (often) people, 4 mins
• When to start small and do it for real, 2 mins
• How to work with developers, 5 mins
• Note 52: Get the week out, 7 mins
• Iterate, if you can, 14 mins
• Bubble-talk is breaking out everywhere, 4 mins
• Inside Oklo: the $20bn nuclear start-up without any revenue, 6 mins
• How to recover from burnout and chronic work stress – according to a psychologist, 5 mins
• Shokunin, 4 mins
• AI has a cargo cult problem, 2 mins
• Open Digital Planning: Month 4, 4 mins
• AI as Normal Technology, 83 mins
• Team dynamics after AI, 3 mins
• The Sloppery Slope of AI, 3 mins
• Governing AI starts with giving users control over their data, 5 mins

And thank you to everyone who DMed it to me, I haven’t been checking RSS as much recently, so would have missed it without you! ↩