The Art of Trust

I was about to tweet about some happy cows I saw while driving to work today, until I remembered the law and thought better of it.  The cows weren't worth a ticket.  But aside from the desire to avoid tickets and stay alive, there is another hazard of automotive texting - thumbing the wrong key and sending the wrong message, perhaps to the wrong person.

When I hired a guy last year entirely over SMS I committed a gaffe - I received a Twitter DM (direct message) and hit reply, sending the reply to all of my followers.  This is a variant of a DM Fail, when people think they are sending a message to just one person but instead broadcast it widely.  In my case I uttered something relatively harmless like "req opened this week."

Something more nefarious happened recently on Twitter: they actually sent DMs to the wrong people, detailed in TechCrunch.  Jason accurately called this a "breach of user trust," but it was resolved quickly.  Twitter is not alone here.  A colleague of mine was using an esteemed Web2 product when they one day got a trove of someone elses messages dumped on their desktop over IMAP.  Only once, but once is all it takes.



This is an area where Web2 (I hate the "oh") and Enterprise2 differ, since the "average risk of mistake" differs.  In other words, a breach of trust will, on average, cost you more in the enterprise.  Stewart Mader characterized this issue of trust well in his Tale of Two Tunnels, where he characterized Web2 applications as building tunnels in the earth, and Enterprise2 apps as building tunnels under water, with the failure of the latter catagory being quite different.  While we don't care if we see the Twitter Whale Fail occasionally, "a crack or crumbling of a tool inside an organization is not seen kindly and raises doubts around the viability of the tool."

But here is the point of this post: DON'T SCREW IT UP BY BEING TOO CAREFUL.  For those of us building Enterprise2 stuff, especially those of us that have been serving the enterprise for a while, then tendency is to be too careful.  I remember a discussion with the CIO of a major CPG customer a year ago.  I had energetically described how all of our activity feeds (I might have worked for a different vendor then) had three layers of security -- first people opt in and share, then the assets are redacted based on ACL, then central XACML policies can do a secondary redaction.  The guy looked at me for a while, and said: Forget everything but sharing.  We want this thing to grow.  If people misbehave we can fire them.

Ironically, this CIO was talking about trust.  "We can fire them" sounds negative, but he was actually saying "We trust our employees to do the right thing by the business.  And if they don't we can fire them."

This was a breath of fresh air.  Too often the systems that try to "keep us in line" cause us to abandon the official tools and use tools that work.  We want to comply, but we MUST get our work done.  A CIO that wanted to err on the side of trust (we're talking people, not certificates) seemed modern indeed.

When designing systems keep this in mind.  Keep an audit trail, not a frustration trail.  Let people know they are making mistakes, don't necessarily prevent them.  And if you trust them, you just might find that they behave a little more responsibly.

Now if I could just open this confidential attachment on my blackberry...