This week, I took a trip down memory lane and revisited a (non-government) project I last worked on nearly five years ago. The ‘temporary‘ system I built back then is still going – amazingly – but the team wanted some changes made. Various people had dabbled in the code since 2003, most recently the organisation’s team of Romanian programmers.  The problem was, my former colleague complained, though cheap those guys didn’t really understand the project, moved onto other stuff and ended up delivering a half-upgraded system which was worse than what was there before.

Today, I had lunch with some proper government techies. This social media stuff is all very well, they said, but what about accessibility, and security, and data protection, and support? To paraphrase their argument, the dabblings of people like me trigger an avalanche of expectation which people like them are then commanded to deliver on. Frustratingly, it’s not that those guys aren’t innovating – just that the incredible stuff they’ve been developing hasn’t managed to see the light of day.

So I’m starting to think this means two things:

  • If we want to be creative in how we apply technology to the problems of government, then we need to draw a line under the extent to which we outsource IT. Though they’d beat you to a pulp with one of their white papers for saying it, you’ll never get real innovation in web communication from the big outsourcers. For that, you need a guy in the corner who does this stuff out of pride, not for money and doesn’t need a spec to tell you how it should be built. It comes from leaving just enough breathing space in the day job for the in-house techies to build the stuff they think is cool, and ensuring it gets in front of the right people. It comes from the developers still working on the project their boss told them to stop working on six months ago. Like Spolsky says, we need to treat our good in-house developers like the superstars they are and recognise just how much talent we have sitting within government if only we could – dare I say – unlock it.
  • Social media tools lower the barrier to entry, but only so far. WordPress.com, TypePad, Ning and SurveyMonkey are great. They let people like me take our meagre knowledge a long way. But we have a responsibility to stop others who understand less about these tools than we do from running away with the idea that this means government webbery has fundamentally changed: it hasn’t. More than ever in a converged, transformed, empowered world, we need the enterprise CMSes, the resilient hosting and the focus on making stuff that’s accessible to everyone. A swiss army knife might save you on a camping trip, but it’s not exactly the tool of choice when you’re refitting a kitchen, and quite right too. We need to understand which of our projects are camping trips, and which are kitchen refits, and choose our tools and teams accordingly – making sure the senior decisionmakers understand the distinction too.

To a non-techie, it can feel like your grumpy developers are just being obstructive when they tell you that they can’t just deploy that blog site you wanted overnight when that guy at the conference said that you could do it yourself on WordPress.com in half an hour. But chances are – if your techies are any good – it’s not obstructiveness at all: it’s professionalism.

Get notified of new blog posts by email

Comments

Amen to that. Sounds like it might be worth getting together with our IT decision makers to map out the options? They’re certainly much more willing to talk about this stuff with me than even a few months ago.
(by the way, I’m the kind of idiot who would try and build a kitchen with a swiss army knife… 🙂

Well said. I wasn’t at this lunch but you and I have had a similar conversation. There really is an expectation that we can knock this stuff together quickly at zero cost – which of course we can, but not at zero risk.

And I’m all for more in house development. Show me a big organisation that’s happy with its outsourced IT. Anyone?

For me, the sweet spot is finding an in-house developer who understands open source and cloud-based programs – and can help me implement them in our networked environment.

That’s why I always talk to the IT department about my next big idea – not necessarily the CIO (more like the guy who usually tells me about who was caught with p2p apps on their desktop).