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.
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.
No secrets in the group, top secret outside it: Tell people what you have achieved, not what you're planning to achieve. Hence: no business plan.
There's no point in working on a secret project if you don't keep it secret. "Access by outsiders to the project and its personnel must be strictly controlled by appropriate security measures."
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.
