top of page
  • Writer's pictureTom Hopkins

Why should I trust you?


I've been having this conversation quite often lately. The idea is that for every action, for every statement, and for everything that we do ourselves, we either build or destroy trust. When we go to Gemba and talk with people, we are often taken positively. But, many times we are still seen as "the outsiders." In our organization, I am part of the Continuous Improvement team and we are on a mission to help develop people around the principles of Lean and Continuous Improvement.

"When you leave, they will just go back to the way they were." What's interesting about this line, we hear it from both sides of the organization. This is a sign of mistrust between people. This is a clear sign that we don't act like a team.

I was reading a wonderful book a few weeks back called The Five Dysfunctions of a Team by Patrick Lencioni, where this concept of trust was a key moment within the story. Lencioni's character Kathryn brings the executive team of her company to an offsite hotel conference room and draws a triangle on the board. The first thing she writes is "absence of trust" (see pyramid below from this great book). What causes this absence of trust? It is a lack of being vulnerable with each other. Kathryn tells the team that she sees a lack of discussion with each other. They try to fight her on this and say she just doesn't know them well enough, but in reality they aren't truly in lockstep with each other, they don't fully agree, yet there's no discussion.


When I go to an organization I do a lot of observing. I observe the interactions and behaviors of the team. Often noted is a lack of communication, but the crazy part about it is that everyone wants more communication!

"Why should I trust you?"

What I really hear is the underlying question between people, "why should I trust you?" When we address this issue we will find out what it is or what it was that is creating this lack of trust. The only way to address this in the team is to first address it with ourselves. If you want to know why someone might mistrust you, look at your actions, what you say, and how you say it. See everything from the eyes of the people that should be part of the team. If you want to be a team, be a team member. This requires you to communicate openly and honestly. Take actions that benefit the team, and be humble. You don't have the answers, I don't have the answers, they don't have the answers. As a team, we will have an answer.

Even with this post, I don't have the answers for you. I've got a very important question though. Why do we have to work in an organization where we mistrust each other? Use the Why? What If? How? model described in my previous post. What if we acted more like a team? What if I acted more like a team member rather than a manager? What if I worked more like a team member than a subordinate? What if I admitted that I was wrong? What if I started seeing my actions as building or destroying trust?

There is no neutral with trust. I either build it, or I destroy it. With this though, we cannot be so afraid of destroying it that we do nothing. Just be conscious that our actions will either build or destroy that trust, and if we destroy it, then we need to try extra hard to build it back up. It is much easier to build trust and be a team when we aren't constantly destroying it.

How will I see my actions as building or destroying trust?

How will I become a team member?

How will I act more like part of a team?

I will let you work on the hows - I have no answers for how you will do that, but realize that this is something you have to address.

 

I've got a story about how I addressed these questions for myself. I have now been part of multiple teams in my career, but when I joined a company I wasn't fully part of a team. Just by joining a company didn't automatically make me a team member. I had to do something. When I first graduated I started working at the Kennedy Space Center as a Quality Engineer for what was then the Constellation Program. I sat in a cubicle in a room away from the rest of the Quality team. I had a computer with no access, and was given a CD full of NASA requirements and policy documents. So I read them.

Eventually I was granted network access and started to explore the NASA universe. One of the things that was suggested was to read the Rogers Commission Report (Challenger accident) and the Columbia Accident Investigation Board report. Reading these reports led me to realize, even NASA realized that cultural issues, team issues, eventually will drive to bigger problems. Challenger had an issue with trust. An Engineer from Thiokol tried to bring up the issue of the impact of temperature on the O-Rings. The culture of launch and pride kept this information from stopping the launch on that cold morning. Nightly lows reached into the 20s. The culture surrounding Columbia was eerily similar. Issues of foam falling from the External Tank were commonly addressed as "In Family" on the problem reports. Silos existed between Vehicle and Launch Operations and Mission Control even though they were part of the same Shuttle Program. Columbia wasn't just one problem on January 16, 2003 when the foam struck the leading edge of the orbiter, it was a common issue that wasn't addressed by the team. The culture again was one of launch and pride, where the program saw themselves becoming more operational than experimental.

So here I was, a new engineer within this place of so much history and greatness. Now I started to see the importance of a team, and more importantly the ability to trust your team. I walked down the hall to talk with my Quality team. It was this first action that showed I was a team member, not just a young engineer. As I started reading more of our NASA requirements, I asked questions with the Quality team. How are we addressing procurement quality? How are we involved with engineering design? As a team, albeit a very small team, we started to address these questions. Our Branch Chief was a big driver of teams, and he even placed a small symbol outside the door of our offices.


He said we were "The Rebel Alliance." We had to think differently than the past cultures and organizational thought patterns of the Shuttle Program. If culture was the problem, he was going to create an open team environment where as team members we would be free to speak up and we would make decisions within this team. We were driven by facts and truth, and did not allow fear of repercussions stop that flow of information.

I was a young engineer who had to help change the culture. I was a young engineer who had to become part of the team first. Soon I realized, it wasn't just our team, I had to become part of the engineering teams. We had to see ourselves as team members and act as such. So as a team member, I didn't say "No" I said "Yes, If." This was our motto. We are engineers, be creative! Yes we can do that, if we account for the safety hazards and quality risks involved. Our team will become part of your teams and help address these hazards and risks. We were open in how we communicated and that drove a better culture. I soon branched out and became part of the Safety team. We were so strong of a team that we communicate daily today, even though I have not worked there for nearly 3 years.

I was a young engineer, and I was developing a skill that, at the time, I had no idea I was developing. It isn't until now that I understand the skill of reflection that I can look back upon my experience and learn. I learned that in order to develop others, I must encourage them to step out of their comfort zone, and become part of the team.

That starts with me. It starts with you. When developing a team, or an individual, I must be a team member, and bring them to realize that first they are also a team member. That requires that I act in ways that show we are a team, and speak as though we are a team, because that is what we are. When we do this, and when we build trust, our teams become stronger and we can do great things, together.

9 views0 comments

Recent Posts

See All
bottom of page