The Speed of Mistrust
Remember the scene in the original Star Wars where Luke, Hans, Chewbacca, and Leia are trapped in the garbage disposal with the walls closing in on them? As the walls inexorably press closer and closer, they engage in increasingly desperate attempts to stop them, a ritual made famous in dozens of adventure movies. No matter how hard they push back against the walls, their efforts are futile. Of course, they are the heroes of the movie, so they do find another way out; after all, if they had not, the movie would have come to an abrupt ending and the fans would have been crushed.
Of course, rather than counting on finding a miraculous escape, it would have been better to have not been in that tight a predicament in the first place.
At Soak Systems, the CEO, whom we’ll refer to as Luke, recently made the comment that, “I guess I should have pushed back harder.”
He was referring to a disastrous product release, one whose eager anticipation by their largest customer was exceeded only by that same customer’s anger and disgust when they finally received it. Their subsequent email was, to say the least, crushing.
In the inevitable post-mortem, it quickly came up that Luke had made at least a couple of attempts to play with the product before it was shipped, but that engineering had “refused to let me see it.”
In retrospect, Luke felt that if he had only insisted more strongly, then clearly engineering would have complied and he would have been able to identify the problems and save the release. Luke is also capable of holding back those moving walls with just the little finger of his left hand. Okay, well maybe not.
While it was gallant of Luke to accept some of the blame for the disaster, he was actually missing the point. In fact, the question is not whether Luke could push back hard enough to convince engineering to cooperate. The question is why he was in that position in the first place. Why, as CEO, does he need to push back that hard just to get basic cooperation? It’s hard to imagine how a release that disastrous could occur without plenty of warning. If nothing else, the stink should have been obvious.
At this point, the traditional thing to do is to nod sagely and observe that if they simply had better communications, the problem could have been avoided. While that observation may be true, it is definitely useless. Of course they weren’t communicating! Why not?
In Star Wars, our heroes at least had the excuse that they landed in the garbage disposal because they were trying to avoid pursuing Storm Troopers. In the resultant rush, they didn’t really have a chance to sit down and calmly discuss their options. At Soak, Luke didn’t have that excuse. There was no rush and no panic, other than the ones that he manufactured.
Effective communications comes from building trust, and trust comes from taking the time to build connections with employees and from, yes, communicating. The problem is that, as CEO, people don’t typically drop by to chat. If you want to get people talking to you, you need to seek them out. Luke didn’t do that. By comparison, IBM’s founder, Tom Watson, was legendary for showing up unannounced at different IBM locations and just dropping in to chat with different people. He was trusted as few CEOs have ever been: employees believed that he cared about them personally.
Luke, on the other hand, talked only to the people he’d worked with in other companies. When he came down to engineering at all, it was mainly to exhort them to do more or complain that they weren’t doing enough. When it became clear that the release had problems, the engineers had mixed feelings about talking to Luke. They couldn’t decide whether he would yell at them and go ahead anyway, threaten them and go ahead anyway, or simply ignore their input completely and go ahead anyway. The VP of Engineering wasn’t able to help them figure out which one it was either, so they decided to simply say nothing.
This is, perhaps, not the best way to establish strong and effective communications with your team.
Now, the fact is, Luke was certainly communicating with the rest of the company. His particularly choice of what to say and how he said it served to build a foundation of mistrust, not a foundation of trust. Sadly, in this environment, the speed of trust has nothing on the speed of mistrust.
Worst of all, Luke’s response, that he “should have pushed back harder,” only confirmed that mistrust. From the perspective of engineering, the release failed due to a number of serious problems that Luke and the rest of senior management were unwilling to address. Acting as if just yelling and demanding more would have changed anything was telling everyone in the company that Luke still didn’t acknowledge the severity of the problems.
The net result: nothing has changed since the release. The metaphorical walls are continuing to close in, Luke is ineffectually pushing back, and one after another the top people at the company are resigning. While Luke may end up with a company full of people he can push around, it’s not at all clear that any of them will be able to push a product out the door.
The situation is not totally irreparable, although it’s getting close. Luke needs to take the time to sit down with his people and actually talk to them and listen to their answers. He needs to take the time to actually get to know more employees than just those with whom he worked in the past. He has a lot of mistrust to overcome and doing that will not be easy. Whether he succeeds or not really depends on whether he is willing to recognize how little trust people have in him, and whether or not he’s willing to work to change that. Until he makes those changes, trust gets the dirt road and mistrust gets the superhighway.
Which is running faster in your company, trust or mistrust?
