Written on 

Hack the hack day

It’s been just over a week since the LocalGov Digital Makers hack day and the last few days have given me time to think things over in a bit more context.

I enjoyed the hack day last week, it was a good experience and it’s kicked off some great projects that are all set to continue over the coming weeks and months, however, the LocalGov Digital Makers hack day didn’t have the same kind of output as a typical hack day. For me, not seeing web apps, apis or websites produced in their droves wasn’t a bad thing, it just made me wonder if there’s an opportunity to make the most of the culture in local gov circles.

I’ve often seen people have difficulties getting creative with technology in local government because constraints that the existing process or the policies bring. It was even evident on the LocalGov Digital Makers hack day when two out of the three challenges spent alot of time talking over the variations of hows and whys we couldn’t, shouldn’t or hadn’t done things up until that point. Over the course of the LocalGovCamp weekend I heard the phrase “the problem isn’t the technology” at least 8 times, more and more I see local government craving a fresher approach to the design of services.

the problem isn't the technology

- more than 8 different people at LocalGovCamp 2014

Local government as a whole doesn’t appear to have a problem with tech. To me, it appears to have a far tougher time with policy and process getting in the way of good solutions. Poorly designed policies and processes inevitably lead to technology being ‘bodged’ to fit an already broken requirement. If we can start to collaborate, iterate and improve our policies and processes, we can up the quality of customer experience we’re delivering. With that in mind, I want to try something; lets run a different kind of hack day. We’ll remove the technology and politics and have a bit of a party on the processes. To try and gauge the interest in the idea, I posted this question on twitter:

Part of me thinks I worded this poorly as the reference to customer services wasn’t entirely necessary. At the time I was thinking along the lines of getting people involved that weren’t process people but who knew the kind of issues customers faced. I didn’t want to just involve service managers and business analysts because the ‘process party’ could quite easily fall foul of the same constraints that’d usually be imposed as part of business as usual. What I was trying to get at is trying to keep the same vibe of a hack day, a positive jfdi approach that can be refined later.

This week I’m arranging the first process hack day at work, not sure what we’ll focus on, not sure how it’ll go but I’ll make sure to write up the results. I might even do some video stuff and see how that works out. The important thing is, it’s an experiment without rules and that’s okay.

If the first one goes okay, I’m tempted to bug Kate and James and others into giving it a go on a different scale. We could even feed the process hacks into more typical tech hack days and get a bit of service-hack set up going.

If you’re interested in giving it a go too, I’d love to hear about it and if have any other ideas that might be fun to try out, get involved and let’s get it done.

If you enjoyed this post, feel free to buy me a coffee. There's still an RSS feed, and you can follow me on Twitter and Instagram