Transparency is one of the great industry buzzes to build out of the collaboration movement. People talk and talk about becoming transparent to their partners, their clients, their cousin Phil… you get the idea. It’s a good movement; transparency promotes information sharing, and information sharing leads to better decisions… or does it?
Transparency can be a double-edged sword. There are aspects of any process that may be par for the course, but to an outsider, look like unmanaged, undisciplined chaos. Watch any of the “reality show” series like Mythbusters or Junkyard Wars, where people build very complex things very quickly, and you’ll see what I mean. The team that looks under control sometimes is not, and vice versa.
This is particularly true in software development, where developers often debate the hows of solving a problem until just the right detail shows up; where it’s hard to commit to a final deadline or even an order in which you will do things until the last detail shows up, where what appears to be small detail changes to the outsider can lead to huge changes in the software. A good friend of mine refers to this process as “making the sausage”. Most people love sausage; if they saw how it was made or what went into it, they wouldn’t be able to eat it.
So if transparency is so dangerous, why is everyone doing it? Why shouldn’t we run from it? Why aren’t projects falling apart all over the business world globally because of it? The truth is that some are. Like all tools, before you can use Transparency to its fullest potential, you need to understand what it’s for and what you are trying to do with it. if you use it incorrectly, it will hinder rather than help.
Transparency lends value in two important ways: it spreads useful information, and it builds trust between groups. There are two key words there: useful information, and trust. These are actually very easy to apply here if you think about it: information people do not understand is not useful. People do not trust things that they do not understand. Also, in the category of trust, no one trusts anything or anyone that surprises them in a negative way.
Drawing from this, we can apply a set of simple do’s and don’t's to Transparency to make it work better:
- Do share anything that is a roadblock. Never let people get surprised when your team runs into trouble.
- Do summarize wherever possible. Keep things in terms that all teams understand. Ditch jargon.
- Do be prepared to explain details, especially related to roadblocks.
- Do be prepared to rate the amount of trouble the roadblock really is- people fear the unknown; quantify it where possible.
- Do not share details for the sake of sharing them, unless you’re specifically having some type of true learning session. Respect people’s limits in how much data that they can take on a time. If you bury people in information, they’ll miss the important parts you share. Make sure the most important details are always at the top.
- Do be prepared for that there will be times that too much detail comes out, and you’ll have to handle it. A lot of people are problem-solvers in the business world. That’s what we all do. If you get too much detail in front of them related to a problem, they will want to dig into it. This is a delicate balance, because often the time you take explaining what’s going on just contributes to delaying the solution and contributes to your frustration. On the other hand, not explaining enough frustrates the people you are sharing with- and it can make them feel you’re hiding things from them. This is one of the slippery slopes of Transparency where you can build stronger trust, or you can do a lot of damage.
- Do not make shared decisions in a vacuum unless you have no choice. Once you open things up, you hurt trust when you start leaving people out.
There’s a lot of other things to consider, but the bottom line is Transparency is about building Trust. Follow your instincts around building Trust and respecting people’s time.