Interview with a skunkworker

Simon Dickson has been asking where the government’s skunkworks project has got to. It sounds like there’s some interesting work going on, appropriately behind the scenes, though there is perhaps a chance to hear more from one of the people setting it up, Mark O’Neill, at the Institute for Government’s event on Tuesday.

In the meantime, I’ve been wondering how such a skunkworks might work, given the constraints and pressures of government. For those of you new to the concept, Wikipedia tells us that skunkworks are projects typically developed by a small and loosely structured group of people who research and develop a project primarily for the sake of radical innovation.

So a little while ago, I interviewed a couple of people who work in two separate skunkworks-style operations in the public sector to find out what we might learn from their experiences.

Q. So to check: I think of you both as working in team environments which others might describe as ‘skunkworks’: would you?

A1. I’ve certainly described what we do as “skunkworks” – but only to those I imagine might not read that negatively. That usually means we’re “skunkworks” to people outside the organisation, but something a little more palatable to those inside.

A2. Our team is a bit unusual.  We take on several projects a year to produce innovative tools that don’t yet exist (or to improve on tools that are either not good enough or have been abandoned). We also take on internal projects to replace tools & systems in order to reduce costs, or add in new features.

Q. You’ve talked in the past about working on projects ranging from the ‘semi-official to the extremely unofficial’. How do you decide on the projects you take on, and how much to talk about them to the outside world?

A1. We decide what we commit to on the basis of our capabilities, funding opportunities and speed of delivery. We do say no, in the nicest way, sometimes: we have to have the control and responsibility for delivery in the same place. We talk about the work we do as much as we are properly allowed to do at present – and we’d like to do a lot more of that.

A2. When we started out we filtered suggestions (collected through our website) based on a set criteria, e.g. does it already exist?  can we do it with our resources? can we add some sort of value? Most of our projects so far have been through this process. Unfortunately, as time has gone on, we’ve had to start justifying our decisions more and more, so we now have to go through a business case and approval process with our senior managers before we can start a project.  We also try to operate a 10% scheme, where we spend some time on our own projects.

Q. I’m interested in the conditions for success of a skunkworks, particularly the middle/senior managers who enable them to develop and prosper. What kind of manager does it take to support a skunkworks?

A1. A brave one! Where we’re visible, we stick out like a sore thumb. We only survive at all because we have the direct protection of senior staff within IT. Without that, we would have sunk within about a month. I’m assuming it’s a matter of personal trust.

A2. You need a manager that understands the premise of what the team is trying to do (they don’t need to understand every detail, but they need to grasp the concept).  Another important atribute is trust – having a manager looking over your shoulder all the time really isn’t conducive to work done quickly.  Finally, you need a facilitator – a manager who can keep obstacles, such as paperwork, out of your way.  We could quite easily spent 90% of our time putting together paperwork and get nothing done, so someone who can reduce or simplify this aspect is really iomportant.  Our team has had some trouble in this aspect – when we started we avoided doing any paperwork of any kind, then we got bogged down in it, and now we’ve got just about the right balance.

Q. What’s your team structure?

A1. The team structure we have is exactly that: a team. We’ve left our grades and job titles long ago. We still get paid different amounts, but that because of the way our ‘parent department’ hired us years back. As senior staffer, I take personal responsibility for the direction and output of the team – but that’s through choice. We don’t have strict dividing lines between skills – we can’t afford to maintain those sorts of illusions.

A2. Our team sits outside of all other functions within the organisation.  We are not part of any policy, communications or corporate services team.  We originally reported directly to the CEO, but now to one of the Senior Directors on the SMT group. To be honest,  I’m not sure what I’d call our team any more.  Our original function was purely to produce innovative tools for customers – no internal systems or developments for other teams.  If we came up with an idea to build something, or someone suggested it to us, we went ahead and did it.  These other ‘in house development’ elements have crept in to our work over the last year due to lack of provision elsewhere and shrinking budgets.

Q. Assuming there will be, as promised, a government skunkworks set up by the Cabinet Office with strong ministerial support, what advice would you give to the leaders of that project? And do you think it’s a viable idea, in that context and based on your experience of working in a public sector organisation?

A1. I certainly do think it’s a viable idea, though it’s not going to be straightforward. Not taking it further would certainly be a missed opportunity.

A2. I think it’s a great idea, and I really hope it is pushed forward.  It certainly is a viable idea, but it’s going to be hard work to begin with. In terms of advice:

1. Just get on with it. The project leaders need to keep as much paperwork away from the developers as possible and not get tied up with it.  We could spend forever filling out business cases, risk assessments, balanced score cards etc. but it doesn’t get the team anywhere.
2. Don’t be afraid to fail.  There is a huge fear of failure in public sector, but in a team like this, failure is really important.  You need to learn from mistakes to get better.  Failure should be met with open arms not avoided.  This is probably going to be a difficult lesson to swallow.
3. It’s going to be difficult to start with. There will be resistance – some people will not understand what you are doing, some people will see it as a waste, others will be scared by the idea.  Educate them and don’t let yourself or the team get demoralised – some people just don’t like new things.

Postscript: the best write-up (long, but gripping) of life in skunkworks I’ve read is by the team who worked on Apple’s Graphing Calculator in the early 1990s. Their project cancelled, they sneaked into the building for months on end, and shipped their software by slipping it to the guy making the master installer discs.