Quarter four, 2018–19, is launched. Work scoped, backlogs filled, sprints begun. We pace ahead on GOV.UK. It’s been a really enjoyable week and, despite one blip, pretty easy-going. I’ve had to wrangle my calendar a little and so, in the spirit of being open, feel free to grab some time to chat about anything: during work hours or in the evening.

To everyone heading to UKGovCamp today, I hope you have tons of fun. Sad to be missing out but it’s my girlfriend’s birthday and needs must. To all weeknoters, old and new, put your name down if you fancy a weeknotes meet-up in London. And I’m having a crack at publishing a newsletter, so check the Reading section for details on that.

Four Things That Happened

We did more things than this


My new team, Search Performance & Resilience, kicked off the quarter! We’re looking at three specific problems in the problem space: our Elasticsearch is out-of-support and needs upgrading; managing our clusters is costly on time and takes us away from feature work; and knowledge of Elasticsearch is low throughout the programme.

Our small but excellent team started by getting Elasticsearch 5.x and 6.x running on their local machines, importing data and noting the differences. This couldn’t have been done without the clear and detailed notes that Kat left us before Christmas, so we’ve a card on our backlog to say thanks to her. Having picked out the breaking changes between v2.x, v5.x and v6.x, we’re working out a plan for jumping to the latter version.

We’ve each acknowledged the blazing fast pace we’ve had this week, it’s a great feeling getting up to speed on the landscape so quickly. But once we get into the meaty work, I’ll be mindful to mention how we can’t always move fast. Tricky technical work deserves some thinking space, so metering everyone’s expectations upfront should hopefully mean no one laments slowing down.

Our main key result: performance and resilience is not degraded.


My other new team, Explore Personalisation, also kicked off the quarter! Our initial meeting provided us with a bunch of questions to answer, to help us work out the unknowns. Getting a feel for the problem space is one of the essential first steps for a product team, so we’ve lots of interviews and desk research lined up. As mentioned before, I’ll not go into too much detail on this work as it’s sensitive and we’ll be blogging about it (plus publishing our research for others to use).

Product managing this work is important for me because, up until now, I’ve been on a very technical product team at GDS. This is a discovery with myriad possibilities, many loud opinions both in the team and battering us from external stakeholders, and balances vision leadership with the current climate around privacy ethics. My history on Platform Health risks me being pigeonholed as a technical product manager and, whilst I’m not afraid of getting into that complex work, this is a chance to showcase my other skills.


We pulled out some questions to help us start forming a roadmap for core products. That’s mostly the applications in the publishing pipeline, authentication, other backends and some cross-product experiences that don’t sit elsewhere. As GOV.UK continues to scale, taking on more government bodies, publishers and serving more people, it’s going to need a bit of operationalisation and programme-wide strategy. For example, if our Publishing product group want to start doing fancy new things, we’ll need to guide them based on what’s possible now and where the overall platform is headed. We need to build up some data, research our colleagues and form a vision for where we’re headed in the coming weeks – that’s for next week though.


I learned how techniques for dealing with HiPPOs don’t always work. People whose bread and butter is making demands can’t be reasoned with during tense moments. This is where knowledge work rubs up against authority bias, where evidence and lean methods lose out to solutionism and senior demands. It’s bullshit.

Having said that, we are in unprecedented times and who’s to say that one way is the best to navigate through? It might be the case that features based on little evidence work, though I’ve not seen that happen often. People with a high degree of domain knowledge can often make instinctive decisions that turn out to be successes – Steve Jobs was great at this. But it’s hard to make reasoned, objective decisions in domains where one has very little knowledge of the intricacies and the environment. Strong product teams exist ‘to serve the [users], in ways that meet the needs of the [organisation]’, as Marty Cagan says in this piece, and they don’t operate well under ‘command and control’ management. So what does work?



What I Learned

I’m lucky to be paired with more of our excellent delivery managers this quarter, which has allowed me to experience some new delivery styles and learn a couple of facilitation methods. I’ll cover those in the post I’ve promised about how to kick off agile delivery teams and credit both Lee and James. Here’s thanks to them for this week!

What I Could Do Better

Calling myself out for snapping in a meeting, which is the first time I’ve done it at GDS. I was angry that our methods aren’t respected and colleagues were pushed against a wall, but that doesn’t make it OK. To be honest, almost every single meeting I’ve been in at GDS has been fine, nothing like the heated conversations you read about in other organisations, both public and private. I’d prefer to keep it that way though, so here’s to metering my own emotions.