Shooting Where the Rabbit Was

"It is change, continuing change, inevitable change, that is the dominant factor in society today. No sensible decision can be made any longer without taking into account not only the world as it is, but the world as it will be." - Isaac Asimov
 

Early on in my career, when making a strategic decision on a technology or in creating a technology strategy, we would consider the tradeoffs, constraints, expected future changes, and business objectives, then arrive at decision with the business. After 3 years the decision often looked ridiculous. By ridiculous, I mean the advances in technology, pricing, and the change in available options, invalidated many of the assumptions that went into the original decision.  

I have noticed that many evaluations of technology options are static in nature, and fail to account for the dynamic changes that are almost certain to occur within the timeframe of the analysis.

So why is this a problem? It's a problem because we are in the 6 Months to stupid world, we don't have 3 years in many cases. Example: A vendor tells you that you can save 50% on public cloud by moving to an onPrem private cloud. Dig in a bit deeper, and you find that the estimated costs associated with the cloud provider are unchanging for the lifespan of onPrem alternative. 

It is possible that cloud providers will not lower prices, in the sense that it is possible to survive a fall from the 30th floor. The dilemma is that just about any technology asset has at least a 3 year life span. While the pace of change in the past made this a somewhat acceptable time horizon,  making a wise 3 year decision in the current environment is increasingly risky. 

Technology costs are going down due to competition, technology upgrades, new pricing models, and disruptive solutions. So make sure your analysis includes dynamic assumptions on pricing and available options. If I could predict specific innovations that will be coming within the next three years, I would be working at a hedge fund instead of opining on Linkedin. However, it is almost a sure thing that if you are making a 3 year decision, it better have a 6 month ROI.

What further compounds the problem is that IT organizations have a major conflict of interest in determining the "best" path forward from a business perspective. Having IT evaluate cloud options is tricky because the technology vendors' business model and the IT workforce are exactly what is being disrupted. So if the question is; "Should we host these applications and data in the cloud or refresh our infrastructure?" A static analysis of the alternatives will help those resistant to change show that staying with a legacy approach is less expensive, and have the added benefit for them of not disrupting their career. Of course this is not necessarily a business benefit. 

Business leaders need to remain engaged with their technology executive and understand the tradeoffs involved in major technology decisions and strategy. The business should be drawing the line in the risk/cost tradeoff, not just the technology leader. You don't have to be a technologist to understand the tradeoffs involved, 0r know that the technology game is changing rapidly.  If the only tradeoff you are typically discussing with IT is "sign this PO, or bad things will happen," you need to get a second opinion. Otherwise you might just be shooting where the rabbit was.

Finding the Brown M&M

Finding the Brown M&M

"He who knows how will always work for he who knows why." - David Lee Roth

I hate to admit it, but I used to be a fan of David Lee Roth. As in Van Halen, as in flying-through-the-air-spinning-back-kick David Lee Roth. The concerts were Epic for not only the music, but the aerobatics of the lead singer.

Legend has it that the contracts for a Van Helen concert were huge and complex, including detailed requirements for rigging the steel trapeze cables used for the aerobatic show. The contracts not only included this information, but everything you can imagine, down to the candy left in David Lee Roth's dressing room. In fact, it was so specific that it included the requirement that M&M's be left in a bowl in his dressing room, with the added requirement that all the brown M&M's be removed.

The first time I heard about this, it seemed to be consistent with the high maintenance narcissism of the lead singer. But this requirement served a very important purpose. In a typical tour, he may be performing in a different city every night. So if your life is on the line, how can you quickly tell whether the contractors have actually followed the detailed instructions laid out in the contract? Especially those terms relating to the cables you will be depending on to fly around the stage while you sing the lyrics to "Jump". You just look for the brown M&M's.  If you find them, you know you need to pay attention and the contractors probably did not follow the contract.

In the business world, we have our own brown M&M's to find. I find them everywhere around me in my professional life. I mean those things that make me want to drill down further,  question the assumptions, or think that someone has not read the contract. One contract, is that technology exists to meet the needs of the user or business, and not the career aspirations or interests of the technologists. If you see a brown M&M, its an indication you need to dig a bit further. 

An example of this I hear often is that an organization cannot move to the cloud because of security or compliance concerns. I once heard that IT told the business that they can't go to Google @ Work because it was not secure. Mmmm, brown M&M for sure, especially the word "can't". There may be many reasons you might decide against Google @ Work, but the word "can't" is not appropriate. I tend to believe in the saying, "there are no solutions, only tradeoffs".  The business gets to choose the tradeoff, not us.

As I dug further into this particular example, I found it was more that IT did not want to go Google. Office 365, onPrem Exchange, or Google @ Work all have their strengths and weaknesses, and the obvious winner from a purely IT perspective would be the option that introduces the least amount of change. The problem is that it really is not about what's best for IT, Development or Engineering, its about the business and the users.

Change can be scary. It can mean you get blamed for the negative experiences related to the change, your job becomes more difficult or is eliminated, your team becomes smaller, you have to retool to remain competitive in your career, or you simply won't be able to do the types of things you have come to know and love.

When someone tells you that you "can't" leverage the cloud because of compliance or security, use PaaS because its too restrictive, implement DevOPS, or use any of the other disruptive approaches and technologies out there, you may have found the brown M&M.