223 – so what do you actually *do*?

I’ve been pretty lucky for the last five years, in that I’ve not had to apply for jobs.

I mean, I did apply for jobs, it’s just that other people were a better fit. But they were always levelling up on what I was doing. The day-to-day carried on, and slightly more interesting projects appeared for me to do. (Some of them I will describe differently when drunk, but that’s another story) But I always carried a certain amount of history with me, some Tom folklore and reputation.

One of the things I’ve learned in the last day is how easy it is to forget to discuss the absolute basics. I spend a lot of my time thinking about culture and strategy and people and alignment and value – and how to adapt myself to the gaps in the organisation around me. I also spend a fair amount of time thinking about what product management is and should be.

I’m also quite good at what I do, so it’s quite weird to get to the end of a conversation with someone new and have an odd feeling at the end, like they didn’t get quite what they wanted.

And then I remember, oh you wanted me to talk about backlog grooming and user stories and roadmaps…and I didn’t actually say any of those words. Because it’s obvious to me, and one part of a big toolkit of getting the right thing done. However I need to remember to make the implicit knowledge explicit.

This is also much in my mind after a very odd article in The Register today. Unsurprisingly, the thrust was that GDS had run its course and you needed to get grownups in the room who understand backend technology where agile isn’t much use, and here’s a man from IBM who can talk about the mindset of e-commerce not being relevant to government transactions.

The comments were also a joy to behold.

But what it made me realise is how misunderstood Agile and the digital mindset actually is. Because we don’t talk about the implicit knowledge. We don’t talk about technology being a function you delegate a project to, it’s core to the way of doing business – and core to policy. We know that policy is flawed and messy and prone to groupthink, cultural disconnect, a lack of frontline operational awareness and more. We know that our automated testing practices make it easier for a team to support our services and make releases more quickly. We know our user-centred approach around an alpha or MVP will tell us a lot more about a policy intent’s chance of success in the real world than a pilot of the finished system. And that building it with our users mindset from the start will mean they’re far more likely to find and complete a task on their own, without needing an army of in-house people to fix the bad data where the user simply didn’t understand what we wanted for our internal processes.

And because we don’t talk about this, folks think it’s just about wearing jeans and writing user stories and thinking about frontends – not running a Proper Technology Project. When actually we’re thinking about the whole system and making it work for everyone.

As ever, it’s also worth pointing out, how lucky we are to have some air cover to work this way. The folks writing those comments aren’t more stupid than us, they’ve just never had the chance to that this was what good could look like. We should remember to be kind.

Metrics update:
SLIs: all fine, although I could have phoned a recruiter back who sent me her number on LinkedIn.
Health metrics: spent way more than four hours under a laptop, and didn’t get to write any music. Having a deliberately lazier morning tomorrow.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.