The Weakest Link: Transitive Trust

Raise your hand if you remember going through this sequence of events at least once in your life:

  1. You have a favorite doctor, hairdresser, babysitter, or some other professional whom you trust.
  2. One day, that person isn’t available. Maybe they are sick, vacationing, retiring, or moving away.
  3. “But don’t worry!” they say. “I have a friend/colleague who will take great care of you. Here, I’ll introduce you.”
  4. You follow their advice… and immediately regret it. Their replacement is awful. Incompetent. Maybe even rude.
  5. It takes several days or weeks to clean up the mess, and then you have to start from scratch on finding a new replacement.

If this story sounds familiar, then you’ve experienced firsthand the problem of transitive trust: You trust person X, exclusively. Person X trusts people Y and Z and chooses to delegate your trust to them. Depending on what they are delegating, the consequences can range from minor nuisance to life-threatening disaster.

During my Infosec days, I was introduced to this problem when my small employer was bought by a larger corporation. We had our network, and they had theirs. Our employees needed access to their network, and vice versa, but one of us had a much stricter security policy. That meant several months of periodic outages, lockouts, general confusion, and painful arguments about the policy itself.

Another example in the tech world is ads; even if the folks who run your favorite news site are squeaky-clean, they may choose an ad network that does not properly vet its advertisers, thus exposing readers to malware. Ad blockers are becoming a security feature.

Later on, I learned that this problem doesn’t only apply to systems; it also applies to people, as in the first example above. The difference is, in meatspace, we usually see it as an isolated incident and fail to identify the earliest point when our decision-making process started to go wrong. Many if not most of us will even continue to make this mistake over and over again, assuming that trustworthy or competent people can reliably deliver us other trustworthy or competent people, even though events rarely play out that way.

The human version of the problem is simple: Doing is not the same as delegating. They are different skill sets, but for some bizarre reason, our brains seem hardwired to believe that they are the same. It’s true that those with a certain skill are better at recognizing that skill in others via the quality of their work or technique; for example, I can easily identify a great coder by looking at their code, but can’t evaluate a football quarterback very well by watching them play. However, even if my skill assessment were perfect, trust in a person depends on much more than their ability to perform a task. There are social factors involved; work ethic; general intelligence; verbal/language skills; etc. I might, for example, have a high tolerance for tardiness in my colleagues, but if I’m not tardy myself, then a client of mine might be angry if I referred them to colleagues who were.

Smart companies who depend on highly-specialized skill sets recognize that this problem also applies to hiring. We hire people, who will eventually hire other people, who hire more people, and so on. The success and reputation of the company depends heavily on employee competence, so by necessity, we have a very difficult and complex hiring process that requires significant training and vetting for interviewers, involves several non-interviewers, and is extremely biased toward no hire. The consequences of taking on even a single unqualified hire are potentially catastrophic, if they manage to hire others who are worse than themselves. Despite all of these safeguards, bad hires have started to creep in, due mainly to constant pressure to “streamline” the process (AKA: lower the bar).

On the flip side, companies that don’t understand the Do vs. Delegate distinction can get into a lot of trouble, which is why many startups fail during the initial growth phase. At one startup where I worked, the founders were sales guys. They were phenomenal at sales, racking up huge contracts every few weeks. Eventually, however, they needed to dial down their sales activity to actually run the business; that meant hiring other salespeople. Surprise: those people were mostly awful. One simply underperformed; another was a blowhard who annoyed everyone else in the office. Then they took on a sales manager, who hired three other salesbots who were all fired on the same day for some serious ethical violation that we weren’t allowed to know the details of. Growth stalled out, because the customer trust that the founders had built up was subsequently broken by the founders’ delegates.

In systems and in life, it’s best to avoid second- or third-degree trust. Be suspicious when a person or institution you trust is telling you that you can trust a third party whom you’ve never met nor heard of. They may have good intentions, and there’s nothing wrong with following up on a referral, but treat that referral as you would any other unknown, starting with zero trust and plenty of skepticism, and keeping your options wide open. This applies to everything from your professional contacts to family friends to the news you read.

If you ever need to inflict this situation on someone else, be transparent about your actual level of trust and familiarity with the third party, and expect a rough transition. Like it or not, your own credibility will take a hit if your surrogate causes a trainwreck.

Bonus round: Consider how the transitive trust problem might affect larger institutions, including governments and entire nations.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s