Radical Transparency?

In the Lean and Agile community, there’s a lot of talk about the value of transparency. Often the takeaway is „the more transparency, the better“, followed by the advice to provide more transparency inside of your company: Make business numbers transparent, make salaries transparent, videotape all meetings and make them available to the whole company etc. I see all the advantages transparency brings and I agree that companies could and should be more transparent in certain areas. I disagree, however, with the notion that we should aim for radical transparency in all areas.

My main argument (of course I haven’t come up with it myself) for this is:

While transparency breeds trust, it tends to hinder innovation.

Real innovation (and I am not talking about optimizing an existing thing, but coming up with a very different thing) requires secrecy. You need to try crazy things, throw things away, and iterate on the same problem over and over again. This is a very wasteful process, the efficiency is extremely low. On the other hand, the operating system of an organization (eg most software development teams) are optimized for velocity, efficiency and high quality. Innovation and optimization can really be considered as two different worlds, they operate by different rules. Rules like „you build it, you run it“, „if you break it, will you notice?“ or „build quality in“ are proven to be really useful in the world of optimization, but they are poisonous to the world of innovation. We don’t want to write high quality code here, we don’t want to write code at all. We only use it to learn things – and only if we don’t find a way to do it cheaper than writing code. The code should be written in a quick-and-dirty-manner, and nobody should expect that it’s tested and monitored and maintained afterwards. (It should, however, be removed after the testing is over).

Now let’s look at transparency. In the world of optimization, transparency is oftentimes really helpful, because it fosters communication and collaboration and breeds trust („Oh, they have that much on their plate. I wasn’t aware of this and was wondering what they were doing the whole day.“) It also creates a certain (often healthy) tension towards accountability and getting stuff done. And this is exactly the problem in the world of innovation. You don’t want this tension here. You don’t want people focusing on getting stuff out of the door quickly. Instead, they need to feel comfortable playing around with seemingly stupid ideas, and it’s not helping when people tell them: „That’s not working, everybody knows that“ all the time.

What does this mean? The world of innovation is very different from the world of optimization – neither one is better than the other. Companies need both, but they need to be treated differently. Transparency is one of many examples where we tend to throw out the baby with the bathwater when we demand things like radical transparency. We should think about how to create healthy environments for optimization and innovation – and be aware of the fact that they will look very different. Unfortunately this comes with a tradeoff: In many cases you will trade trust for innovation. You can certainly minimize the negative effects of this, but you cannot eliminate them completely.

Another thing we need to think about is how we bridge the two worlds, because at a certain point we need to transfer innovation into the operating system of the company. And we should not do this by throwing our brilliant innovation over the fence to those who now have to implement and maintain it.

This all is not very new. 

• My friend Markus Andrezak talks about it for years, for example in this great talk from LKCE13. 
• Nonaka/Takeuchi wrote the book The Knowledge-Creating Company, which deals with the differences between the two worlds 20 years ago (thanks to Stefan Roock for pointing me to this). 
• The concept of Skunk Works is 70 years old and does very similar things to what I was describing: Creating an environment that’s decoupled from the rest of the organization and operates by different rules. 
• In 2004, Charles O’Reilly and Michael Tushman published an HBR article named The Ambidextrous Organization, which is – again – about the differences between the two worlds and ideas how to bridge them.
• And there’s scientific evidence that the statement „the more transparency the better“ is plain wrong. Read for example the HBR article TheTransparency Trap by Ethan Bernstein (yes, he studied other areas than software development)

Again, I am not saying transparency is bad or we should have less transparency. What I am advocating is that we should have a closer look at different contexts and evaluate transparency according to these contexts, instead of beating the same „transparency is good“ drum over and over again.

Addendum: Christoph Poyault pointed me to this interesting (German) article So wirkt sich Lohntransparenz auf die Zufriedenheit aus

_______________________

Like this post? Then you should check out one of my newer posts An Alternative View on Company Structures