This is one of the phrases I dread hearing the most, mainly because it usually ends in “... so I’ve already told everyone we can do it this way” (or something scarily similar).  This phrase definitely falls into the bucket of “partners telling us solutions” (which has it own dangers), however, for me this one is a little bit more insidious…

A Game of Telephone

Generally I don’t hear this phrase first hand.  Instead, I’m (un)fortunate enough to hear it second, third or fourth hand.  It tends to originate from someone higher-up in the org chart, generally a VP, Senior Director or the like.  It also tends to originate from a place with good intentions. After all, this person and their team is faced with a big challenge, so why not use something they KNOW has worked before?

How it plays out (in Robs super-oversimplified world)

Why it’s scary

This is scary since where ever we are now, we ARE NOT at the same place this worked for them in the past. We’ve also entirely skipped the part where we identify the problem.  Even if the business is identical and we make the same product/service, the way our systems are setup will differ in some fashion.  Generally we’re not in the exact same industry, making the differences even greater. Further, the individual who puts this idea forward likely does not understand the specifics of what was done, only the end product (it’s seldom a Director or higher I meet who truely cares to learn the technical specifics).  So even if the solution worked exactly as remembered, they do not fully understand the pretzels their tech teams had to wrap themselves into in order to deliver.

How it should play out (in Robs super over-simplified world)

Getting from scary to supportive

Technical teams (whether it be IT, legal, communications, etc) are the experts in solving problems, so we get very concerned when instead we’re fed solutions.  The best way to improve this relationship is, well, to improve the relationship. I personally spend a great deal of time working with my partner teams and sharing the  basic concepts / patterns/ processes that my team uses. This helps demystify tech (that said a lot of it is still magic to me) for my partners, and, more importantly, helps build trust.  This is needed for those times I have to tell them that what their VP said may have worked somewhere else, but it may not work here.

In the end it all boils down to the strength of relationships with  partner teams. These scary phrases will continue to come up, but, they should become less and less scary as time goes on and more and more folks know to trust their tech.