“Доверяй, но проверяй” — Suzanne Massie, circa 1984-1987

When I think on “trust,” a few things come to mind immediately.  Creating trusts between AD domains, creating a local account with which I entrust admin rights, destroying trust between co-workers, and building trust between teams.  So, realistically, I think about half as much about trust with regards to technology as I do with the people around me.  (Says something about my social skills, doesn’t it?)

Technology

I trust computers to do what I ask in the way that I ask.  This is pretty much the definition of computer programming.  In a day when you can ask Cortana, Siri, Alexa, or Google for pretty much any information in the world, it’s sometimes hard to remember that there is software behind those queries.  This is where the technology trust begins – with the algorithms and the big data analytics that they use when crunching my data.  I trust the companies with which I share information to protect my information, secure my personal data, and return me valuable services.  Most of the time, this is the case and I’m a happy camper.  Most of the companies I trust use some type of encryption to protect my information.  If they don't offer something like that, then I'm not using them.  It's just that simple.

People

Working with people, and trusting in people is frequently the hardest thing to do in IT.  In the past, I’ve worked at companies where it was dog-eat-dog and if you could cut someone off at the knees, you did.  This was seen to be the most advantageous thing you could do for your career.  I’m hoping that this is now more of a rarity in the workplace, but I would not be surprised if it lingered on in some places.  In those places, “trust” is a four-letter word.

Other times people trust one another to carry out a task.  Normally, this is in regards to larger projects.  I remember a time or two when I was younger, that I was asked to handle some tasks and I didn’t come through.  This was the first time that I was working on a project that extended outside my immediate team.  Failing to complete this task delayed the project.  I realized that I was the wrench in the machine – I wasn’t being helpful, I was a hindrance and people couldn’t trust me.

Fast forward a few years, and I was the project manager.  Now I had to trust other people to complete the necessary tasks to keep the project moving forward.  Thankfully, I remembered my earlier lesson and it was when I was first introduced to the phrase “trust, but verify.”

It’s a Russian proverb that was introduced to President Reagan by Suzanne Massie when he was dealing with the Soviet Union in regards to the Intermediate-Range Nuclear Forces Treaty.  In those days, the thought was to trust the opposing side to do what is stipulated, but verify it for yourself.

Long story short – if you need something done by someone else, let them do it, but make sure that it’s done.  This is my mantra whenever I run projects.  We come up with the project plan, we assign out the duties (trust), then we check with everyone about how their tasks are progressing (verify).

Alternatives

There’s always the alternative to not trust anyone other than yourself.  In most cases, this should be avoided whenever possible.  IT is a community, like any other, which takes input and interaction to truly prosper.  However, I think that everyone in IT has taken on every aspect of a project themselves, but hopefully it is for a small project.  I know that I’ve only done it a handful of times and in retrospect, I’d never do it the same way.  If attempt to be the lone team-member for your entire career, you will be one of those guys in the basement bemoaning about setting the building on fire.