Sparklemotion

The Devil’s Advocate™ — projects you can try at home →Go uptown Click ᐅ to expand: Projects Tell me more Sign up for our newsletter — or just get in touch: for ½ a weekly 🍺 you get to consult JC. Ask about it here.

How to build your own internal skunkworks.

The original Lockheed principles

• Have a set of core values that define the team: Favour what is right for the project and the outputs, even if it requires breaking with company common practices and culture.
• Have sponsors: Develop sponsors outside the group who can help cut through the red tape and institutional resistance.
• Give free rein: Let the team manager have complete practical control of all aspects of the programme".
• Keep it small: The number of people on the project "must be restricted in an almost vicious manner. Use a small number of good ­people (ten to 25 per cent compared to the so-called normal systems). This should self-select.
• Be like a shark: keep moving: Let the team collaborate and iterate easily. Promote agility. Lightweight tools. Like SharePoint. Favour agility over robustness. Quid pro quo: act with urgency. Set strict milestones, deadlines and budgets so everyone acts with a sense of urgency.
• Delivery early, continuously, and iterate:
• Log everything: Keep as much data on everything as you can: you need to explain what you’ve been doing and why it was worthwhile even if it didn’t work. Have as few reports as you can, but document important work thoroughly.
• No secrets in the group, top secret outside it: Let the people in the group have the big picture. Tell people what you have achieved, not what you're planning to achieve. Hence: no business plan.

Additional ones

Have a kill switch: if a project is working out, be prepared to nix it. Ask: what have we learned? What could we tweak which realistically might make a difference? If you can’t think of anything, let it go. But record your results.

What it is

What it ain’t

Diverse: Fun: stimulating, challenging, intellectual, entertaining, and empowering. Social: It really does depend on that serendipitous spark that tinkles off employees of a large organisation when they bump into each other in the lift, at the gym, in disciplinary processes etc. A chance or learn: This is not a drill. This is not rote. You will acquire new skills and new ways of looking art the world. If you bring a paint-by-numbers view to this, it won’t work. This is an antidote to painting by numbers, which is what large organisations do by habit. Disciplined: But it is not all table-tennis tables and soft play areas: you need to generate concrete outputs. It doesn't matter that they’re negative, but you need to have something to show for the investment in time. So form a plan, state success criteria, run experiments, iterate, and write it up. If it works, you need to take it and implement it back into the organisation. If it didn’t you need to document why your bright idea didn’t work. That reason might point to a structural impediment in the organisation that you can’t shift, but someone else can. Failure is an option: Expect failure. If there are no failures, you aren’t trying hard enough. Effective experimentation in a complex system must be iterative — the feedback loop is non-linear. It should be evolutionary: evolution only works because some stuff dies. In trial and error, you need .... error.

Death by PowerPoint: On one level you are trying to eradicate bureaucracy. You can’t do that with bureaucracy — no painting by numbers. Cut out business plans, use-case justifications, deliverables and deadlines. Leave the paperwork for the write-up at the end. A talking-shop: This can’t be an excuse to kick back and yarn. You need some outputs: no organisation will tolerate that kind of frivolity. You need a plan, you need to get on with it, and you need to report back about it. But up to you how you do that stuff. A moan-fest: Go write a wiki if you want to do that. An objective on your end-of-year appraisal: This one I’m conflicted about because punters need some kind of cover, but goal-setting, and performance appraisals, are exactly the sort of behaviour we are trying to avoid.

See also

• Project method