Innovation requires trust and freedom. But freedom only comes from trust, so the primary requirement for innovation is trust. And broadly speaking, the more trust you extend to a development team the more innovative they’re going to be. At the very least, innovation will not extend beyond the trust they’re given. Here are four levels of trust, and the innovation each can lead to.

• Trust = 0
• Trust with tasks
• Trust with milestones
• Interlude: Where we don’t want to innovate
• Trust to define projects

Trust = 0

Let’s start at the very beginning, where trust = 0 and hence freedom = 0. “I don’t trust you to work by yourself; everything you do must be done in conjunction with me.” This is micro-management and generates nothing unexpected whatsoever. The only opportunity any team member has for creativity is during their bathroom break. We can do better.

Trust with tasks

Let’s extend trust a little bit: we allow our team members to complete individual tasks or deliverables that we specify — but let them determine how each task should be completed. This is work to a tightly-defined plan, and so any innovation will be under the hood — the internal architecture, the software design, and so on. But what you’ll see is what you expect. The tangible product, and every visible aspect of the product, is exactly what you imagined.

Trust with milestones

We can extend trust further still: we allow our team to deliver to clear product goals and trust them to work out the details of those product goals. This is where we start seeing innovation — as opposed to having innovation under the hood. Innovation of this kind is driven by project milestones or product principles, like “We want some personalisation features” or “The user must be able to share their work”. We want the development team — the programmers, user experience people, designers and so on — to be free to determine how to achieve this because it’s they who have the most intimate understanding of the product, how it fits together, what it’s capable of, and what it might be capable of.

In this scenario those project milestones or product principles come from outside the development team. It’s what they rely on product managers or other senior stakeholders for. Amazon does this with a press release: a description of the product in terms of end-user benefits, written to inspire and guide the development team.

Interlude: Where we don’t want to innovate

If you’re thinking that this amount of freedom, from this amount of trust, is just hippy nonsense that leads to escalating budgets and timescales, then let me bring us down to earth.

One area where we almost certainly don’t want to be innovating is project management. There are plenty of good project management methodologies out there, one or two of which will be good enough for us, and we don’t need to be inventing any more. So we may not go in with a detailed task list and instead trust the team to define the tasks themselves; and we may not go in with any predefined product features and instead trust the team to work out for themselves what features will achieve the stated aims of the product; but to not go in with any idea of how we might responsibly spend our budget, manage risks, showcase progress, communicate with stakeholders, meet timescales, and adapt to feedback is downright irresponsible. And to generally deprive the team of project management expertise is foolish. Unless we explicitly want to invent a new project management methodology we really should ensure the team picks one of these tools and has the wherewithal to use it well.

Trust leads to innovation, but let’s be clear about where we want to innovate.

Now back to our regular programming.

Trust to define projects

We can extend our trust even further if we allow our team to define not just product principles or milestones, but entire products or projects. We can set an organisation-level goal such as “we want to double our revenues” or “we need to make our service a social experience” and then see how our team can achieve it.

A goal like this is important for two reasons.

First, it eliminates irrelevant ideas. Anyone in an organisation can have ideas, but we really want ideas that push our business forward. If my media company specifies that our goal is to make what we do more social then an interesting idea like making an iPhone game will be considered irrelevant because it doesn’t meet the goal of making our existing work more social. In other circumstances it might be promising, but our current circumstances are about being more social and that’s what we need to focus on.

Second, it allows us to compare alternate ideas. I might propose that people could be given virtual biscuits every time they share an article. Already this is more relevant than the iPhone game idea thanks to having to focus it on our organisation-level goal. But if someone else has a proposal to create common interest groups around our content then I’d say my virtual biscuits are looking pretty poor, relatively speaking. Our organisation-level goal has provided a scale of comparison.

And round again…

We’ve just extended trust to enable people to envisage an entirely new project. This is the very first stage of development — the concept. We also have to implement it. And this takes us right back to the beginning: how much trust do we want to give to the team? None? Just enough to complete a series of predefined tasks? Or do we trust them to devise the most appropriate means to meet the principles of the product? This is our chance to inject innovation again.