September 25, 2019

Being Transparent

Being transparent in extremely important. It not only gives team members background about a problem but builds confidence & trust with them as well.

Being Transparent

I am a big believer in being transparent with my team members whenever possible. I know that there are a few situations where it isn't possible to tell them, but I try as much as possible to let them know, even though I'm not perfect at it.

Trust & Confidence

Whenever you try to obfuscate something within your team, you are bound to create fear & concern. By playing open cards you are sure to gain more trust within the team as they see that you have nothing to hide.

At the end of the day, you don't want to surprise anyone and the last thing you want is for people to start hearing rumors via the grape vine. When this happens, it is often a mangled version of the truth and hearing things via this method is a surefire way to quickly kill off any trust that you may have built.

In the situations where something may not happen, but it will affect the team, I tend to tell them about it. I will say that I'm not 100% sure about how things will pan out, but here is the current scenario. From my personal experience, I know that I would prefer being told early rather than when something is 100% definite. In the past, when I have told people about some possible changes that may affect them, they actually thanked me for keeping me in the loop.

All these things can help build trust & confidence. Your team will feel that they have been part of the conversation and had their voices heard and not surprised. After all, they are part of your team and not some pawns on a board.

Developers In The Dark

Quite often, I have seen the scenario where a developer gets told to go and develop a feature without ever providing them some background on to what the actual problem is that they are trying to solve. Team members need to know why a feature is being built and how it will improve the lives of the customers. Without this knowledge, they are merely cogs in a machine. This is quite sad because often they can be some of the most creative thinkers that the business has.

For example, imagine I just told you that you needed to redesign a page and move a few buttons around, change some textboxes etc. The developer would happily go along and do just as they are told. However, if I added that the reason that these changes were to be made was to increase usage of a particular feature, you get the developer thinking about the actual problem and they too would be able to provide valuable feedback on some things that can be done.

I cannot stress enough the importance of giving your team members the actual problem to be solved as opposed to just the solution that needs to be implemented. I will say this yet again, having many heads on the problem will lead to a better solution in the end.

Exceptions

Of course there will always be exceptions to the rule and in some circumstances you may not be able to share certain information. For example, you may have some non-disclosure agreement (NDA) in which case you cannot share it with anyone. Another example would be when someone has explicitly asked you not to share the information. In these situations, keep the information private, but still aim for the general rule of sharing as much as possible.

After a while you will start to see the benefits of being transparent. Sometimes you may forget to share things and it may be frustrating but at the end of the day it will be worth it.

Until next time...keep learning!