A few years a go I was recounting the Skype story to a colleague. He introduced me to the architect who had been tasked with solving the Portfolio problem we solved at Skype. The conversation went a bit like this.
- Me: We did “X” at Skype. It took us eighteen months to get to that point.
- Architect: We are not going to do that, we are going to do “Y”.
- Me: We tried that and it did not work.
- Architect: Well then we will do “Z”
- Me: We tried that and it did not work.
- Repeat 4 & 5 for a few minutes
- Architect This is not working. We both have opinions and we do not agree.
- <End of Meeting>
As I left the meeting, I thought to myself “No. You have an opinion, I have experience. And sadly you do not know the difference between opinion and experience.”
So what is an opinion? An opinion is a hypothesis in the complicated domain of Cynefin. The architect was expressing an opinion that contained a great deal of uncertainty.
And what is experience? Experience is a hypothesis that has been tested in a (safe to fail*) experiment. So when I said “We tried that and it did not work”, I was was speaking from certainty, I was an genuine expert.
Unfortunately we were in a culture that saw all problems as complicated and deferred to the expert as a result. In a culture that sees all problems as complicated, experts express opinions as fact as uncertainty is scorned, and the high power distance rules! In such a culture, no one understands the difference between an opinion and experience. In such a culture, the most senior person’s opinion, OR HIPPO as it is known, rules supreme.
So as an executive, how do you handle such a situation? Simple, listen to experience OVER opinion. Executives know how to do this in spades… Most executives will have given hundreds of job interviews during their career, carefully sifting the facts from theory (How did you do that? talk about what you actually did? not what the group did, what did you do? You say “I think”, what happened”). Most people do not lie and will be honest about their experience when challenged, they will retreat and admit they are expressing opinion.
This highlights one of the differences between Communities of Need and Communities of Solution. In Communities of Need, the keynote are “Trail Blazers” who talk about their hypotheses and their tested hypotheses or experience. In the Communities of Solutions, the keynotes are normally “thought leaders” who are talking about Opinion. They talk about the work that others have done as if it is proof for their opinion. By contrast, they tend to strip off the context implying that what works in one context will work in another. (See Dave Snowden’s Lean Agile Scotland keynote for more detail on this)
Context is everything with some techniques. Tony Grout, myself and a large supporting cast first implemented “Delivery Mapping” at Skype. Dan North then invited me in to help one of his large Banking Clients who faced the same portfolio issue. (Note – Pretty much every organisation has the same issue). Subsequently I have implemented it in two other organisations. I am currently working to implement it in another client.
Here’s the thing about delivery mapping. It is easy peasy. The concept is easy. The training is easy. The hard bit is getting the buy in from both IT AND even harder, THE BUSINESS. It will not work unless a large chunk of an organisation agrees to it, or if the “CEO” overrides a whole bunch of self interested senior executives, effectively forcing them to ignore their performance management system. Getting that kind of buy-in either involves luck (and the right dominant culture which is also luck) OR a hell of a lot of effort and influencing. It requires you to gradually and methodically build support for YOURSELF. Building credibility in your own brand so that the people in the “Complicated Culture” trust your experience more than their expensive “experts” and “thought leaders”.
So if you want to a simple test the people around you. See whether they value
Experience OVER Opinion
Cannot tell the difference between Experience and Opinion.
If you picking a conference to spend your precious training budget on, look for one where the keynote is talk about THEIR experience, or instead is simply expressing opinion and using other peoples experience to justify their opinion. If you are not sure which keynotes do this, go and watch some videos on InfoQ, youtube and VIMEO, its easy to spot when you know what you are looking for.
Scaling Agile needs a culture which values Experience OVER Opinion. Without it, we will see more catastrophic failures where Thought Leaders express their opinions as fact and the people who suffer are the dozens of people whose careers are ruined a year later.
* Even though it should, not all experience is gained in a “safe to fail” experiment. Some experience is gained in a non “safe to fail” experiment at great cost to some of those involved.
January 28th, 2017 at 6:07 pm
Thanks for articulating this. I get a fair bit of pressure to speak at conferences and to teach. I have loads of really interesting experiences – having experimented with so many agile/lean/other approaches in so many contexts. I cannot get away from the fact that context is critical (which is why I look closely at the people). Packaging it all up into a “here is a tool that will work every time” feels profoundly dishonest. And this has been at the root of my resistance to speak at conferences. Valuing experience over opinion – not a conclusion one can easily come to when wandering around conferences.
January 28th, 2017 at 10:16 pm
Hi Christine, Thank you for your comment. Makes it worthwhile.
January 29th, 2017 at 4:39 pm
Hi Chris, I enjoyed the read and it’s definitely given me something to ponder. Does the importance of context that you mention make it challenging to know whether to value experience over opinion? It’s not always a trivial for the person with the experience to recognise key contextual differences. The other challenge I see are huge cognitive biases when reflecting on one’s own experience, what worked and what didn’t, and for what reasons. I see your point on being able to differentiate between expertience and opinion, but maybe the more important message is be aware of your own biases in both cases?
January 29th, 2017 at 5:13 pm
Hi, great point.
You never really understand the context in which an idea works but you can know when it probably won’t. Experience is really about know when an idea has failed and understanding why.
Hence the example of Capacity Planning. I’ve seen it “fail” when business leadership had not bought in. By fail I mean it did not live up to what it could be, even though it was better than what went before.
February 1st, 2017 at 10:54 pm
The comments around context are key. I agree that experience should be weighted over opinion but this supposes that the playing field is ‘level’ with respect to context. An opinion holder should be given more weight if they can be convinced to analyse their opinion in the context of the experience – not necessarily more weight than experience, but more than an unconsidered opinion. Still, as you well know – this is a TOUGH problem. I was there. I saw what experiments were fail-safe and which were fail-at-a-cost. 🙂
February 10th, 2017 at 9:57 am
Thank you for this article – you bring up an interesting topic.
One remark on your introductory example conversation: I noticed that your reply to “We’ll do Y” is “We tried and it did not work”. Do you think it would have been more palatable and easier to accept for the architect had you given some more justifications for why it didn’t work? Or did you leave out this part for brevity’s sake?
February 10th, 2017 at 10:00 am
Hi Sebastian, it was for brevities sake, I gave a full explanation of why.