Transparency accelerates… but are you providing the trust needed to count on?

Share this:

At SIG, we are in the business of providing transparency. We open up the proverbial black box that is software development, bringing to light details on both the application landscape under development and the teams developing it. And this can be scary. Take this to the level of a single application and single team, and the scariness just increased tenfold.

When it comes to transparency, this is one of the most important factors to deal with. How do we ensure that opening up the box is less scary. And this is where trust comes in.

Before we start implementing our Sigrid | Software Assurance platform, I am often in contact with various of our clients. It strikes me how often we run into the concern of getting acceptance of the development teams for the transparency that Sigrid will provide. Often, management indicates that they really want more information and insight to steer on, but that it is difficult to get that from their teams.

To me, this is a clear smell. A smell that the organization needs to take some hurdles to learn to work with transparency.

Transparency means opening up yourself, putting yourself in a vulnerable position. This is indeed not easy, and psychologically we are all wired with a protection mechanism that prevents us from sharing too much, so we don’t get hurt. The people around us can influence our behavior in this regard. When we are treated with respect and people are mindful about offering constructive criticism, we tend to open up more and more. In this way, we can become more confident , and the more confident we become, the more vulnerable you can position yourself and the more you learn. This is a clear pay-off that is out there for all of us.

And the great news is: Software Engineers are already used to this process.

In IT, we  apply agile processes. These processes focus on a ‘fail often and learn fast’ concept. This means that software engineers, more than anyone else, have to deal with making their work transparent for evaluation. Often in a quick cycle of just two weeks. They are used to opening up and learning from their mistakes.

Within a team, this is possible if there is a safe environment. This is normally quite easy to achieve as the team is working together a lot,  and the storming and forming of the group is able to take place and trust is built.

But now come the other stakeholders from around the black box that is software development. Product Owners, Architects, Manager; they are all looking for some form of insight and transparency. They all have their agendas that intertwine with those of the development team. They all depend on the results that come out of the black box, and would like to influence the inner workings of the black box.

However, before a team is ready to offer this type of transparency to people outside the ‘box’, there needs to be a safe environment. And this is more difficult to create. Because this transparency is often to people that are a little further away from the team, making it difficult to go through the steps and phases of forming and storming. And this is what we often see. Various stakeholders are asking for transparency. But before this can be asked, you need to ask yourself:

  • Have we created a safe environment for teams to try and fail in?
  • Are we giving teams the opportunity to learn and giving them the time to do so?
  • Is there reciprocity in the information exchange we ask for?

If you cannot give a full and resounding ‘YES’ on the above questions then there are hurdles to overcome.

It means the rest of the organization is not ready yet for development teams to provide transparency. We see it often in many of the organizations we work with. Software Engineers are more than willing to share and be transparent. Because by being transparent about a problem you invite help and a shared responsibility to get to a solution. Moreover, software engineers are even used to it because of  their agile way of working. But this only works if there is a two-way street: opening up requires trust.

And again, good news! We find that building this trust can be accelerated when you bring technical experts and business stakeholders together to solve a specific problem together.

So if you find yourself looking for transparency on what happens in development, ask yourself: are we creating the environment that makes this possible?

Related resources