The Importance of trust in organisations
Published on February 15, 2021 by Daniele Davì on danieledavi.com
Trust is a pillar for many organizations nowadays.
I remember seeing on the tv displays at the office many times a day the ubiquitous message “Microsoft is built on trust” when I worked there.
Many organizations following the trend come up with similar mottos, insert the trust narrative into their vision, mission, or values.
Every company claims to be trustworthy, many claim to care for their customers, “you can trust us!”. Some mention that the secret of company success is to treat employees well and trust them as they know what they are doing. “Take care of your employees and they will take care of the client”.
In some cases, organizations proudly mention that they collaborate only with highly trusted, carefully vetted, diligently selected providers and partners.
All the trust narrative is used from many perspectives especially to build brand reputation and elevate reliability perception.
Marketing strategies apart, let’s look closer at trust from an internal perspective.
We can take an IT organization as an example but the same concepts and dynamics apply to any industry: medtech, social media, fintech, software house, aerospace, military, education, public administration…
What is trust?
Trust is a feeling of confidence or conviction that things can unfold within a dependable framework that embodies order and integrity. We may not always understand what is happening to us, or to another, or what is occurring in a particular situation; but if we trust ourselves, or another, or we place our trust in a process or an ideal, we can find a powerful stabilizing element embracing security, balance, and openness within the trusting which, in some way, if not based on naivete, intuitively guides us and protects us from harm or self-destruction.
Why is Trust becoming so important in our days, in our life, work, digitalized world?
In the new era of innovation and trust some big changes started about 30–20 years ago with the spreading of ideas from “The new new product development game”, Lean, Scrum, Agile.
The 3 pillars of empirical process -transparency, inspection and adaptation- unlocked the possibility for teams to be autonomous. Not being asked continuously by different managers, executives, colleagues, clients, stakeholders “What are you working on? Is this ready? While doing this can you also do that? How many lines of code did you write today? What do you need this tool for? What code are you exactly changing?”
Autonomy doesn’t mean anarchy. It doesn’t mean playing around irresponsibly. Autonomy is a prerequisite for accountability. How can a developer or anyone be responsible for something over which they have no power or choice?
It is puzzling for me, as Agile Coach, after 20 years from the Agile Manifesto, to see how autonomy, trust, communication, self-enablement and many other concepts deriving from Lean and Agile values and principles are misunderstood or used for office politics and personal crusades.
From time to time we hear people say that agile is complicated because it doesn’t let them have documentation. Not sure from where they take that, but I can imagine that one of the most common misinterpretations comes from the Agile manifesto itself: We value working software more than comprehensive documentation.
Which means simply that papers don’t always reflect reality at best and it is nonsense to value working software less than documentation. We also need to contextualize and remember what was the world 40 years ago, where millions of pages of code and reports were already obsolete five minutes after being printed.
For instance in 1986, days before launching the Space Shuttle Challenger managers signed off all the required assessment documents. On the paper everything was good, all boxes ticked by security and executives.The engineers were communicating a different reality though. They were having meetings discussing critical issues, and possible solutions including stopping the mission.
The dramatic result, the Space Shuttle Challenger disaster, is unfortunately well impressed in our memories. That’s the only reality. All documents, papers, policies, and “box ticking theatre” were rubbish, and this was evident to the entire world. Just after the launch and after the investigation.
Trust, agile, critical applications, software assurance
So what? No more policies or documents or quality and control? What’s the solution?
The solution is in less than 300 words of the Agile Manifesto. Acquiring the Agile mindset is the first step for continuous improvement.
NASA learned a lot and changed a lot after the Challenger tragedy.
NASA software developers and engineers are using agile methods to enhance timeliness and efficiency as they develop critical applications for the Space Launch System (SLS) and other major projects. This poses new challenges for NASA’s Software Assurance (SA) professionals who strive to ensure safety and mission success.
We are uncovering better ways of developing software.
We see value in documentation but face to face communication and adherence to reality have higher value. We see value in processes and tools but individuals and interactions have higher importance.
Read the Agile Manifesto and if you find yourself disagreeing read it slowly again and again until you find your initial thought ridiculous.
Don’t write documents and policies that do not reflect reality. Don’t store hundreds of pages that just make everything seem in order when you have to pass an audit. Don’t keep dozens of papers describing clunky processes, bureaucratic rules that no one ever reads, convoluted procedures that no one can ever understand, apply, update or even maintain. Don’t. If you are doing any of these, Stop! Now! It is not secure.
Instead, go ask the people. They know what they are doing. Establish the right culture of transparency, inspection, adaptation. Trust them. Do it and if you haven’t yet, Start! Now! Trust leads the way to security. TRUST THEM.
Radical transparency and continuous inspection
Working software is part of living documentation. You can also automate extracting documentation from code, but what I am saying is that working software is a better proof. The most updated you can have.
The product backlog provides a living, traceable, auditable, always updated product roadmap, with highest value and most granulary defined items always on top. No need for hundreds of upfront defined documents full of things your customer will not want anymore in a few weeks. Favour the communication. Trust the empirical process, empower the people.
The sprint backlog is the living, traceable, auditable, inspectionable, always updated document of what is in progress. Don’t ask people what they are doing. Go and check it by yourself. Sprint backlog answers the question “What among the highest valuable product increments can we expect to be completed by end of the current iteration?”Any adequate tool can support the process. No need for docs, excels, gantt, powerpoints, daily or weekly status updates. Every iteration produces working software, tested and usable. Inspectable by security, marketing, legal, sales, customer, end users.
Engineering and quality best practices are written, produced and made public by communities of developers, testers, engineers, designers, hackers, scrum masters.
All people that you probably have in your organization and that you should trust.
Don’t just copy paste content from OWASP 10 website and keep it in a zombie security document. Don’t send out a security exit checklist that you don’t follow up. Same for other security frameworks you think you are implementing. Instead, attend sprint reviews, engage proactively on security concerns, challenge the team to go beyond useless bureaucracy or your own interpretation of standards. Participate on their journey to shift left on security.
Trust the people. Connect with them. Know them. Empower them.
Make them feel responsible for what they build.
The scrum empirical process works if everyone contributes and it is designed to create, unlock, enhance trust with the purpose of maximising value, quality and accelerate business success.
When someone in your company goes around -physically or virtually- asking developers “what do you need this for?” or “what piece of code are you working on right now?”, be aware that someone, even assuming good intentions, is not acting in the best interest of the company.
Like it or not, accept it. Medieval inquisition is not a practice in the best interest of any organization. WHO DOES IT, NO MATTER RANK OR ROLE IS NOT WORKING IN THE BEST INTEREST OF THE COMPANY!
It is always important to assume good faith. So how can we fix it? Let’s see possible causes. Perhaps that person is not familiar with an agile mindset, perhaps one finds scrum complicated to understand, perhaps is paranoid, perhaps they don’t know they can and should contact Product Owners, Program Managers, Scrum Master, if they want to know what people work on. Maybe they don’t know how to use Jira, Jama, Trello or any other backlog management tool. It could be that they think that is part of their job, going around questioning developers all day to slow them down and make them unfocused or nervous. It could be that a direct manager or someone from security or sales or legal or even a scrum master or product owner is trying to micromanage or is just too invasive. Perhaps their goals aren’t aligned with maximizing company value, delivery and throughput. If you finish all the options listed under “good faith” perhaps they are conducting their own crusade against agile or a culture of trust.
Is it never OK to question the team?
Unless the questioning is motivated by a security accident, suspicious behaviour, anti fraud warning, strange activities, specific concerns or similar case, no. Unless that’s the case, no one, not even the head of security, not even the scrum master have the right to undermine the trust and professionality of a team member. Especially if it happens often. It is a process deviation. There is a huge cost and irreversible impact.
If it seems too radical to you, you simply don’t know enough about empirical processes. Scrum for instance provides proper meetings, with a dedicated agenda where questioning and challenging can happen in structured, safe, time-boxed, efficient and productive ways. It’s the whole point of radical transparency and continuous inspection.
Going back to my intro, if your organization does not embrace trust and doesn’t claim to be rooted in trust or doesn’t have trust and agility among company values, then your company is consistent and truthful. It will still lose money, it will have some security issues sooner or later, and each area will suffer the lack of trust. If the organization makes some claims around trust, the issues are the same or more but the company would not be even consistent or truthful.
You may be an employee, a contractor, or a partner for a company or more but you are also a customer for many many more.
You are a user, a person and a citizen. If you read this article, you know how to recognize from inside and outside the companies that are really built on trust.
You can distinguish who talks from who walks the walk.
You will make your choice when you buy your next phone or register on a website.
You have the power to proactively contribute to the success of companies that trust people and let the old thinking medieval inquisitorial mentality die.
Trust is a must!
In my next article I describe some negative impacts that toxicity, inquisition-like questions, and the absence of trust create on different aspects of organizations
This article have been published for the first time on danieledavi.com by me, the author Daniele Davi’ on February 15th 2021.
© Daniele Davi’, 2021. No part of this site, danieledavi.com, may be reproduced in whole or in part in any manner without the permission of the copyright owner.