All too often I hear that development or business leaders aren’t trusted in an organization. This can be expressed by both sides in words and actions. The problem is, if the organization is feeling this way nothing will truly succeed and at best a subpar solution is delivered. Trust is a two-way street. Both sides must work together to build and maintain trust.
If one of the individuals/groups involved is not open to build and maintain trust, then there is nothing that can be done. People will realize this and do whatever it takes to cope. Usually this equates to some kind of detachment from care, doing just enough to get by, or it could be finding new jobs/people.
There are many amazing articles out there about trust in the workplace. But there are some common themes that show up when one of the groups involved is a software development team. Development teams and business leaders that find a way to work together as one unit instead of combative forces end up producing some of the most amazing solutions that I have seen. While this can be difficult to make a part of a company's culture, the pay-off far exceeds the cost. The place to start is recognizing that there is an issue.
Communication issues are the first and biggest sign there is a trust issue. These communication problems can come in many forms like, outbursts of emotion, keeping quiet, or over communicating.
Frustration is a natural reaction on both sides of the trust spectrum. This can cause people to have outbursts where their frustration shows through. This immediately induces a defensive stance by the other side, furthering the divide.
On the other side, it is easy to clam up and not express anything during conversations or saying just enough to make it through. This is another coping mechanism that is detrimental to any relationship between those involved. If nothing is being discussed how can an amazing solution be discovered and implemented.
This could very easily lead to micromanagement. I have seen this happen on both sides where business leaders don’t trust their development team so they try to manage everything they are doing. The opposite has happened where the development team doesn’t trust what the business leaders are giving them, so they try to inject themselves into the business process to make sure what they are working on is what they think is needed. Both of these instances one side is saying “Because I don’t trust you, I have to make sure everything you are doing makes sense.”
Another sign within a given group is the “bad mouthing” of the other side. This is a way of letting off steam because of trust issues. This will create a toxic work environment, even when everyone who is participating is in agreement. The relationship between the groups will continue to suffer and slip further into toxicity.
Knowing how trust is lost is key to not losing it in the first place. There are many different ways in which trust is lost between development teams and business leaders. Some may just be inherent to the individuals involved, which need to be addressed in one-on-one conversations. The following are some common ways in which I have seen trust lost across an organization. While it isn’t a comprehensive list, it does give you insight into different situations and how they apply to both development teams and business leaders.
Technology is viewed as a necessary evil in order to accomplish business goals. This happens more commonly when the technology is playing a supporting role instead of the primary business functionality. When technology is a “cost center” instead of a “revenue center” then this perception of “necessary evil” tends to form. This happens from both sides. Not only can the business see it as an anchor, the development team can be made to feel like an anchor.
Another way for skewed perceptions is when there is little visibility from either side on direction or decisions. Now, this shouldn’t be at the micro layer, but the macro. If the development team isn’t being informed of why what they are working on is important then their work can make little sense without a foundation to build upon. On the other side, if the business doesn’t have visibility into the progress and accomplishments of development, then it is easy to dismiss the work.
When something is promised, regardless of it being called a promise, trust will be lost. In development of software, that is frequently attributed to the delivery of features by a given date.
If both scope of work and the deadline are fixed, trust will most likely be lost because there is no flexibility for the development team to deal with unforeseen problems. In this situation, there will be an immediate loss of trust on the part of the development team as they feel a proverbial noose wrapping around their necks.
If there is flexibility in either scope or deadline and the development team still doesn’t deliver, then the business leaders will learn that they can’t rely on their team to do what they say. Now, this can be mitigated if there is good visibility and communication in the organization, but if that is suffering then this trust loss is made much worse.
Besides delivery dates there is an unspoken promise that exists between development teams and business leaders. On the development side, they promise that they will produce good stable code with an acceptable level of bugs/issues. While one major issue can be seen as a mistake to learn from, if mistakes continually happen where major issues are introduced into a “production” environment, of course trust will be lost.
On the business side, they promise that they have thought through their direction and eagerly await the implementation of needed features. It is understandable that sometimes that direction needs to shift, but if that is the norm and not the exception it is a huge moral hit to the development team. So much of their hard work may never see the light of day. Many development team members are in it to solve problems and give people what they need. As a result the praise that many people rely on will never materialize.
Development teams are domain experts in developing and deploying solutions. Business leaders are domain experts of the business. The expectation of either to be experts in the others domain is unrealistic.
Even though each group may be experts in their domain doesn’t mean they know everything they need to define and implement ideas. People learn by trying then failing and then rinse and repeat until a great solution is found. Expecting everyone to know everything up front is a quick way to lose trust in each other.
Open communication is critical in order to discuss direction and implementation. If one group feels like they are not being heard this will lead to distrust building. When development says something can’t be done there may be reasons. Those reasons must be expressed in a consumable way to the business leaders and the business leaders must listen to their experts. If either side feels like they can’t express their knowledge or opinions for fear of being ignored or worse, for repercussions that may happen, then trust will be lost.
The number one way to immediately lose trust is to lie. I am not talking about failing when you are trying to do a thing (miss a delivery date), I mean deliberately saying something you know not to be true. This includes lying in front of someone about something else. If lies are easily said, then how can trust be maintained?
While there are many more was to build trust, the following describes what I think are the core to start the process. Once the ball is rolling, the organization can evaluate more advanced thoughts and methodologies.
First and most importantly, both sides must accept responsibility and work together to rebuild. Everyone involved must realize that trust is only lost if it is not maintained. If something happens to lose trust in one side, both sides must immediately work hard to correct. If not then the slip to increased distrust will be rapid and destructive.
This needs to be part of the culture. The key players must be involved and the individuals must have an open dialog. To have an open mind, a safe environment is essential where everyone is free to be vulnerable and willing to put themselves on the line.
Really evaluate why trust isn’t there. Always ask why, and keep asking until getting to the root of it. For example, development missing a deadline is a common way for trust to be lost. But why did they miss the deadline. Was the scope too large, did they lack the time or knowledge to find the pitfalls, did they not speak up when something went wrong? Even then I would keep asking why. Why was the scope too large, why was there not enough time or knowledge, why did they not speak up?
This can make people uncomfortable, showing all their weak points. Sometimes having an outsider listen and be the bridge between may help. There is something about bringing in someone who is not attached to give weight to their words. If the person trying to make improvements has too much personal involvement their opinions are more easily dismissed.
Trust is a precious thing, and it should be treated as such. Working hard to build it and even harder to maintain it. When trust is held in high regard, and the development team and the business leaders become one organization working together, great solutions are their pay-offs.
Are you ready to build something brilliant? We're ready to help.
.jpg)
