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
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.
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.
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.
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.
2 thoughts on “How innovation depends on trust”
I like much of what you say; goals (I’d call it a product vision) are more effective if they reduce the set of options around what to work on, allowing people to make decisions about what they work on or how they will implement something increases their motivation and commitment.
I think that a key component of trust comes from observing how people act rather than what they say, especially under challenging conditions, such as questioning or raising concerns about decisions or discussing the competence of the team.
It’s easy to say “we trust you to meet the principles of the product”, but what happens if you have concerns or want to challenge the team’s decisions? Are you allowed to raise these issues, or does this become micromanagement and demonstrate a lack of trust? Many people equate trust to mean that their manager leaves them alone and treat inquiries as a challenge. Trust boundaries are best established on the basis of predicted competence to deliver the results. Again, what happens if the team demonstrates it lacks competence?
Often people find discussing these issues difficult and embarrassing, so they avoid them or try and “ease-in” by talking around the topic (“How’s the project going? Finding it hard going at the moment, eh?”). The trouble with avoiding or easing in behaviours is that they involve hiding information from others, and commonly, not admitting that this information is being hidden (the cover-up must be covered up). It seems hard to see how trust could be established in situations where one party is deliberately hiding information from the other.
What’s your view?
Benjamin, I think you’re going further than me. The post above is saying that trust is important for innovation, and you’re then going a step further by asking how can that trust be established. I think you raise some interesting questions, and I’d agree with your perspective.
There were questions in my mind as I wrote this: If a team is trusted, why should we have any governance/reporting/oversight structures? Could it be that those are needed because we don’t really trust the team? And I think the answers may lie in what you say: we need those structures because the team is working at the boundaries of trust. So we really want to extend trust as far as possible, and therefore we need checks and balances to ensure we haven’t over-extended ourselves. And having an effective governance structure enables those difficult questions to be asked in a non-threatening way.
Comments are closed.