The Distractions: Weeknotes S18E03

The Distractions

This easyJet plane is sat at the end of the runway, about to take off as I start writing these weeknotes. We’re going elsewhere, leaving the week behind. And ain’t that what weeknotes are all about?

Distractions

I felt overwhelmingly distracted this week. By Slack, mostly, and having to keep an eye on emails. That’s not good because it took me away from implementing some of the foundations we need, the playbook I mentioned last week.

What’s bad is that I don’t think I need to be all over Slack all the time. There wasn’t anything I caught or nipped in the bud by being so alert to notifications and scanning channels this week. So next week I’ll be stricter with focus time, turning off notifications, and catching up later.

Team topology

Last week I drafted a new design for our teams and how they interact to create value, based on Team Topologies. After talking to one of our senior delivery managers about hand-offs between teams, I got to put the topology in front of a team and get feedback. They’re the ones with the most demands on their time from other teams, so it’s most important it works for them. I’m trying to create more focus and flow after all.

They liked it and thought it was a good state to iterate towards. I was particularly pleased that the sub-teams I drafted for their area matched categories of work they divided their time on. Always nice to have assumptions validated!

The next step is for them to review and categorise items in their backlog so we can make informed decisions about capacity and burndown strategy. They’re going to do this in GitHub Projects instead of Trello, where they currently work, because where appropriate I’m shifting teams to use GitHub’s offering. Why? Well, it’s actually designed for software projects. And it’s lighter and simpler than Jira, which is over-engineered.

GitHub Projects also brings tasks and issues closer to pull requests, which creates a better record of the work that happened. For those who come after us.

Value

We’re making a concerted effort to talk about value beyond the frameworks in the Magenta Book. There’s too much focus on cost-savings, which means we don’t get to talk about what those savings enable. Saving money in one place means it can be redirected to another place, another place that may create more value.

Automation is a good example. Automating software releases means developers can spend more time coding, which leads to better quality code and potentially some innovations. (Which is what’s missing from all the talk about AI currently. Are we using it to reduce costs or redirect resources?)

A new person joined the team to focus on producing case studies, economic models, and enabling us to tell these stories. So I spent some time laying out how we’d done this on GOV.‌UK Pay and GOV.‌UK Design System, and highlighting areas I’d investigate were it my job.

I mean, it is kind of my job but I’m so stretched, I’m glad to have someone join who understands planning and has a background in economics. Much more than my poxy A-level!

It got me thinking about the value of digital transformation and how we need to communicate that going forward. Innovations that enable data to be re-use, across government, between services provided by different departments will certainly improve the user experience. But the time saved from not typing something out is quite small.

Quicker processing times will be good, and reducing failure demand is better. But that’s all just reducing costs through time-savings.

It feels like those innovations should be a component of missions that drive growth, rather than being an atomised growth-creator. For example, computers were a component of the mission to land on the moon, rather than being viewed as an inherently productive thing.

(I’m probably saying something that’s obvious to people much cleverer than me, but thinking out loud helps me work stuff out.)

Trust

Last week I mentioned building trust, that common growing pain on the supply side for many multisided marketplaces. I ran my thinking past people on the programme, including a service owner, and got good support for a) it being a problem, and b) an important one to solve. A few people had good suggestions for ways we could work through it, so I’m going to organise a workshop to collect tactics and decide on a strategy together.

Still need the support of psd, who’s been off this week, but I know he’ll have some thought or insight that only improves our approach.

Harsh Browns