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.
[Kabat-Zinn 1994]
Why Trust is becoming so important in our days, in our life, job, digitalized world?
Everything starts 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.
Zero trust and cargo culture
Following a process without understanding the rationale behind it is useless and dangerous. And it has a name: cargo culture.
Too often while safeguarding digital assets some people forget that technology should empower people. Sure, processes and policies need to be in place and respected. Even enforced by tools, if possible. But in any case they need to make sense, be simple, easy to understand, applicable, and logical. Irrationality and unreasonableness are more common than expected. Processes that don’t make sense are advocated by people that try to apply a solution without understanding the problem.
For instance, the “Zero Trust Network”, or “Zero Trust Architecture”, model created in 2010 by John Kindervag is commonly misunderstood in many organisations and sadly tend to become just “zero trust” or “no trust” or even “zero tolerance”.
These misunderstandings or wrong beliefs are the root causes behind many security incidents. Similarly to the junior developer that copy-paste code without understanding it. Similarly to anyone emulating behaviours for the sake of it or like the “five monkeys experiment”. Whilst you may question if the experiment really happened in the way is told, transmission bias, cargo culture, confirmation bias and other erroneous predictably behaviours are proven and well studied.
Ticking boxes
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. Whoever 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.
Below are some negative impacts that the inquisition-like questions create, no matter if posed to a full time employee, contractor or partner.
LEGAL
It diminishes the work done from HR and legal.
Everyone is assumed to be vetted, cleared, checked and so worthy of trust before the company signs a contract. If we say that a company doesn’t trust the people, partners, vendors, entities, providers with whom contracts are signed then the company is not reliable. In that case customers shouldn’t trust a company with such doubts.Perhaps legal is OK but someone thinks that is not enough.
Well… Solve the concerns with legal and let the developers work.
MARKETING
Full time employees, collaborators, partners, vendors, including the handymen are the frontline of branding reputation. Always be kind and respectful. Put in place the right process but don’t bother people with your arrogance.They are citizens and people with rights, feelings, opinions and social influence.They will tell their daily experience to friends, family, co-workers of the same or other projects. They are the ones filling the questionnaires that determine your Net Promoter Score.They will compare their experience with other employers and make it public on Glassdoor, Reddit, Stackoverflow, Github, Google review, their blog, and thousands of other communities and meetups. Online and offline.
Stop harming yourself.
BUSINESS
Developers provide transparency to everyone and in particular to their key stakeholders not only keeping the backlog items they work on always up to date but they do more. They dedicate time to status updates on a daily basis (daily standups), on a sprint basis (sprint review and planning), on a release basis.Using extra time and budget to require them to continuously prove the legitimacy of their work, fragment their days, it slows down their activities, it kills their productivity, focus, confidence, engagement, it stops business innovation, puts deliveries, business, customer relations, revenues at risk.Loss due to context switching and distractions is high and not reversible.
Do not disturb developers. Trust them. Let them do their job. They are amazing at it, that is what they are paid for.
SECURITY
Human factor is considered the weakest ring of the security chain. I usually see two common antipatterns or biases.When security has a fixed mindset, they suspect everything and everyone. Everyone except whoever is in their team of course. This is evident when there are double standards and undocumented exceptions.
The second is that they convince themselves that it is their job to go around patrolling everything and everyone. Again, except whoever is in their team of course. They tell you never to share your password with anyone but they are the ones who send passwords by emails, because the internal doesn’t allow resetting the password by the user. Every software proposed by others needs a business case and a hard-to-pass security screening. Unless it is proposed by one of theirs.
This type of black spot with many other biases is one of the major dangers when we talk about company security. And that is the weakest ring according to studies and industry security reports. Biases in people from security even more than others.
There is a third factor too often ignored.
Security breach chronicles and news tell us that people that leak information or cause damage to company assets are the ones who have not been treated well, not treated properly, and not trusted. It is not important what you did but how you made them feel.
I am not saying that those who have a bad day will automatically think of revenge.
Voluntarily or not, people that are not engaged are more prone to make mistakes. People that are not trusted, aren’t confident enough and make more mistakes (overconfident people make mistakes too).When they make mistakes, if they aren’t confident they tend to hide the errors, rather than shout about it. If you work in security you know that is not about “if” an incident will happen. It is about “when” it will happen. Recognizing and responding immediately is paramount.
Showing everyday arguable behaviour and ridiculous questioning, unreasonableness, bureaucracy means building up a culture of fear, untrust, silence, low cooperation. It is security building up its own worst enemy. Unsecure environment. Culture of scapegoating, blaming, mocking, shirked responsibilities, discouraging bridging, shooting messengers. If you work in security and you are reading this, make yourself a favour. Make your company a favour. Make your customer and users a favour. Make the world a favour. Build a culture of trust and safety.
Of course do also your due diligence, properly manage access, implement governance policies based on roles/projects/resources. Make your risk assessment matrix, document a light-weight transparent process, put in place automated logging, auditing, warnings, sentinels, whatever…
Inspect process and tools but let people do their job. Your job is not to block or delay production activities. Your job is to safely support their acceleration. Build confidence.
DEVOPS
If your organization has still development on one side and operations out of the team, and you think it is OK then you can just skip reading. Apologies for telling you this now. This article is meant for people who understand software development nowadays (2021), in a world where teams need to release multiple times a day.
Testers or operations outside of the team are well known antipatterns. Any 101 modern book, research, report, study about it, would tell you that if you think you are doing devops because you use Jenkins, Bitbucket, Terraform or other tools stop messing around. No, really. That’s not devops.
Devops starts with a strong culture of collaboration, shared responsibilities, team autonomy and self-sufficiency, strong focus on automation and quality and no silos between developers and operators, from design to deployment closing the feedback loop with users.
If you disagree, stop reading bits and pieces of old blogs posts and get some serious structured knowledge about devops. In my other blog articles I suggest books, and I write about devops capabilities. DevOps is the union of people, process, and technology to continually provide value to customers. Devops is about culture. A culture of trust. By adopting a DevOps culture teams gain the ability to better respond to customer needs, increase confidence in the applications they build, they achieve business goals faster and they trust each other.
All the team members work together, using traceable, auditable boards that provide transparency. Be responsible as a team for your own quality. Shift left on security. Be proud of your work. Communication, trust, commitment, courage, focus, openness, and respect.
Trust Trust Trust.
HR
Not trusting people, not enabling them to work, creating a beuracrocatical or pathological culture (Westrum) in the short, medium and long term creates issues in the company. Work engagement and job satisfaction are one of the drivers of organizational performance. Toxic culture in many organizations cost billions of dollars a year. It increases attrition rate.
Many talents just leave if they aren’t trusted or worst they suffer distress and risk burnout. No trust, no safety, no happiness.
If your company seems like a Dilbert cartoon, fix it.
FINANCE
I don’t claim to be an expert in all areas but I think I made my point clear at this stage.
Developers need to stay focused on producing the most valuable increment during an iteration.
Wasting time answering redundant inquisitorial questions is like throwing money out of the window or like being taxed twice. It is inefficient and it has a ripple effect on all production activities. Not rarely it makes the difference between profit and loss. Each simple distraction added to context switching, can determine a measurable loss in productivity. The well known phenomenon is called dual task interference.
The damages produced by a non safe environment, lack of trust, no security, and no innovation are huge. According to many studies the total costs of toxicity, easily top $100 billion in US only every 5 years.
Any CFO who would be informed of someone going around mining the culture of trust and distracting the teams with silly questions should grab that someone to say loud and clear “stop wasting our money”.
Stop working against the company budget. Stop putting at risk our financial goals. Stop!
Anyone else
No matter if you adopt scrum, agile, lean, waterfall or even if you work in IT or car manufacturing or education, aerospace industry or public administration. Absence of trust is the first, the largest, the most frequent and the most expensive of the well-known 5 major dysfunctions identified by Patrick Lencioni. Any team and organizations will suffer a ripple effect and develop more dysfunctions due to lack of trust. The costs and overall negative effect on society are huge!
In the above scenarios, you may not necessarily be a persecutor, rescuer, victim or witness. Yet, if you are impacted by lack of trust and low organizational performance, ask to have clear, short, meaningful policies based on project, roles, and assets to protect.
If you see an unfamiliar face or someone tailgating, alert security. Follow the policy and common sense. Don’t close your eyes.
Trust, double check, trust.
If you need info from the team, ask to PO/PM, SM. Familiarize with agile, scrum roles and responsibilities. Demand and follow lightweight well defined fair processes that encourage transparency, inspection, adaptation. Contribute breaking down walls and silos. Support proactively a generative culture (Westrum) and smooth flow of information.
Secrecy is poison! If you trust, you will be trusted and you will definitely benefit from a safe trusty organizational environment
Conclusion
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!
* * *
I write about organizational patterns, transformational leadership, healthy businesses, high-performing teams, future of workplace, culture, mindset, biases and more. My focus is in leading, training, and coaching teams and organizations in improving their agile adoption. Articles are the result of my ideas, studies, reading, research, courses, and learning.
The postings on this site and any social profile are my own and do not represent or relate to the postings, strategies, opinions, events, situations of any current or former employer.
This article has been published for the first time on danieledavi.com by the author Daniele Davi’.
© Daniele Davi’, 2021. No part of this article or the materials available through this website may be copied, photocopied, reproduced, translated, distributed, transmitted, displayed, published, broadcast or reduced to any electronic medium, human or machine-readable form, in whole or in part, without prior written consent of the author, Daniele Davi’.