Are You Aware of Your Differentiating Assets?

A week ago I had the pleasure of being invited to a private talk with Sir Jonathan Evans, former Director-General of MI5, on the theme of Digital Security. While many of the topics of the evening were quite pertinent to so many of the recent news events, there was one item in particular that really stood out. Evans stated that one of his missions was to try and reach out far and wide to government ministries, universities and corporations and ask:

“Are your important assets understood and secured from theft and sabotage?”

How many people and companies have properly asked themselves this question? How many can actually explain why those assets are important, and to whom? Do they differentiate you or your firm from the rest of the market? How many target the acquisition of those assets and then know once they have them? To take it even further, how many can articulate whether or not those assets that they have are effectively exploited?

These are questions that apply not only to businesses, but also to each and every one of us in our private lives as well. Let’s step through and explore a little more.

Assets

The first place to start is to look around at your assets. Assets are those things that have qualities or capabilities that can be somehow exploited to provide value. Assets can be physical (like tools, vehicles, property), financial (monetary instruments and credit), human (not only headcount, but also skills and culture), intellectual (which is not just things like patents, but also includes knowledge as well as data that has the ability to provide knowledge and indicators), and relational (these are usually things like commercial relationships or standing contracts that might allow for preferential or enhanced access and treatment not ordinarily available to others).

Most people and firms will go to some lengths to put in measures to secure physical assets. This is the reason for elaborate locks, alarm systems and guards. They may not do the best job of securing and tracking these and thus experience lossage, sometimes with severe consequences. Similar measures are often used for financial assets, which unless you are working with billions in financial instruments or are large enough to have your own Treasury Department, might be mostly outsourced to banks who are also simultaneously putting some of it to use for investment returns.

Human, intellectual, and relational assets, however, are far more elusive. Many companies only pay lip service to the value of their people. In some industries and areas people may be fungible enough that losing people has relatively low impact. However, as competition and innovation become ever faster and more knowledge dependent, losing staff becomes ever more costly. Often there are important skills and relationships that go into really making a product that are neither visible nor necessarily easily transferable to other staff. Understanding these dynamics, and putting in sensible safeguards to build staff loyalty and prevent poaching is important. For most companies, the best people are often the first to leave when conditions deteriorate.

Intellectual assets are even trickier. They are often invisible even to those within an organization. Theft through unauthorized analyzing or copying by external parties rarely leave any trace, even though the theft of such assets can have a significant impact. However, intellectual assets are even more vulnerable to two bigger scourges: tampering and neglect.

Tampering

It is rather easy to tamper with intellectual assets. Whether it be tweaking source code, fiddling with configurations, or twiddling with data without some form of tracking you are tampering and may not even realize it. Most tampering may be inconsequential, but occasionally unexpected mayhem may ensue, especially if the tampering is malicious. Tampering can not only cause vital systems to fail, but when it affects data and metrics can cause incorrect conclusions to be made that lead to disastrous actions being taken. Troops can be sent the wrong way. Investment firms can dump or buy assets that cause market instability and damage the firm. Companies can dump or damage their products, services and supply chains. The FDA has even warned recently that many medical devices and hospital networks can be tampered with, flooding patients with insulin or causing pacemakers to dysfunction.

Few properly think about and assess the dangers of tampering, with even fewer putting safeguards in place to minimize the risk of it happening. This doesn't mean that one needs to develop a high level of paranoia about everything, but there is value in understanding how exposed your assets are to tampering.

Neglect

Lack of awareness and neglect are potentially even more harmful. Data and assets are lost all the time, often disappearing through faulty storage, handling and backup. Many people know that NASA has lost large amounts of data from the early space programs, including the Apollo lunar missions, due to an inability to recover data stored on the 7-track reel-to-reel tapes used at the time. While that is an extreme case, I have run into many companies who have lost source code to critical systems due to general mishandling and improper source code control systems. In several instances I have personally witnessed, this has cost companies millions and severely hamstrung the business. I have also seen many cases where lost knowledge of systems, software, and even test harnesses built long ago have caused huge amounts of mayhem when they have later needed to be updated or replaced. It has been suggested that this may be part of the cause for the embarrassing mainframe outages at RBS/NatWest where people were locked out of their bank accounts for days on end.

Awareness of your assets and capabilities will help with ensuring that neglect does not become built in. It takes a great deal of effort to build in this sort of awareness, especially in large and well-established businesses. However, there are ways to gather and audit that can be put in place to first understand the size of the problem, then steadily fix it over time.

Differentiators

For both companies as well as individuals, both the understanding and being savvy with utilizing your assets is what differentiates you from your competitors. This is why it is important to both understand as well as protect and enhance them constantly.

I have seen many businesses outsource large chunks of their business to outside firms. For non-core and undifferentiated parts of the business this often makes sense. However, I have seen large numbers of firms also outsource core, near-core, and differentiating parts of their businesses, only leaving the executive suite and some minor elements of sales and marketing within the business. Without careful oversight this can be extremely dangerous. I have seen cases where companies have become so dependent upon one outsourcer for a key piece of the business that losing them would mean that the business would stop, perhaps catastrophically. I have also seen where the business ultimately ends up in competitive situations with the outsourcer and are incapable of competing cost effectively. Outsourcing Research and Development means that without very careful shepherding you risk becoming beholden to the outsourcer for innovative progress. Outsourcing customer service and support can potentially risk losing control over the level of quality of contact with the customer, potentially harming both reputation as well as future sales. The quality of these services are often differentiators to your customer in the marketplace.

Businesses need to think through what are their differentiators, and whether they are effectively protecting and enhancing them.

Awareness and Exploitation

It is key to be aware of your assets, not only what and where they are but also whether they are understood and secured from theft and sabotage. As they are not always obvious or visible, it often requires regular effort to ensure that they are accounted for and used effectively. Both individuals as well as businesses should regularly take stock of what they have, and determine whether and how they are used to effectively differentiate you from the rest of the market.

The Confusion of DevOps

"What we got here is... failure to communicate."

                              -- Captain of Road Prison 36,  Cool Hand Luke (1967)

I am noticing more and more frequently these days that the term "DevOps" is being used to describe a staff position or department and sets of tasks that can best be described as deployment configuration management and automation.  The role seems to have been derived from so much confusion that has come out of a mixing of the heavily related Continuous Delivery, Infrastructure-as-Code, Service Engineering, and DevOps movements that have been swirling around in various forms for the last several years.  While it is difficult to talk about any one of them without referring to elements of another, the fact that they have all somehow been combined into a new job family is not only disconcerting, but may potentially represent a general misunderstanding of the larger issues that exist between IT and the rest of the business.

Businesses constantly seem to be struggling to come to grips with the constant changes that are happening across the business, especially in IT.  Business leaders barely had come to grips with the whole concept of the Internet, Just In Time manufacturing techniques and multimodal telecommunication methods when suddenly the Agile and Lean movements, Continuous Integration, virtualization, elastic computing, and on-demand software services arose.  Each of these innovations has demanded significant changes to interactions, behaviors and understandings of people across the organization.  In return they deliver ever faster and ever cheaper ways of innovating and serving the market. 

Mainstream businesses have struggled to understand many of these concepts, and are only now beginning to seriously make many of the necessary steps to adopt them.  Few have gotten far enough along to really effectively handle them while also absorbing the next wave of change that is already on top of us.  This next wave includes not only the significant changes at delivery and run that come with Continuous Delivery, Infrastructure-as-Code, and Service Engineering, but also more advanced topics such as the flows and collaboration required to actually achieve what is aspired to in DevOps, the complete mindset change that comes with Outcome Delivery in the Product Development space, and changes arising in the legal contract and financial spaces.  This next wave is building upon the knowledge, learning and expertise created by successful pioneers from the earlier wave. 

Anyone who has made significant inroads into these next wave approaches knows that true power in them requires proficiency if not mastery of earlier concepts.  Continuous Delivery is not terribly effective if neither Continous Integration or the short iterations of Agile methods are in use.  DevOps is really the next step in collaboration.  It further blurs the remaining team boundaries to eliminate any remaining friction and gaps in roles and responsibilities that negatively affect service health and continuous improvement. It simultaneously shores up and strengthens the professional rigor that once organizational boundaries tried to uphold. The mindsets that are established in the earlier movements, such as frequent and rapid adaptation to feedback and working collaboratively in cross functional teams, are all important prerequisites.

Businesses are finding themselves in an uncomfortable spot.  They are realizing that they need to make massive changes in order to stay competitive.  Yet so few people within their ranks properly understand these new ideas enough to effectively implement the changes required by them.  There just simply doesn't seem to be a nice and neat place to handle this sort of change in the traditional organization.

So they create one.

In the past some companies simply made the move to outsource their IT in the hopes that the problem can become that of their outsourced partner. Some may still opt for this option in light of these challenges. This often only makes the problem larger by putting entire corporate entities and business profit models between IT and critical business functions.  Many of these companies have learned that IT is in fact a critical capability within their business, one that can only effectively be outsourced when doing so neither impedes business change nor lets go of the company's value add in the marketplace in a way that leaves the business completely hostage to the outsourcer.

Perhaps it is worthwhile to look deeper into the industry to see what is going on.
Much like the mess that is "Cloud Computing", the term seems to be pervading ever further across the industry, to the point where it is being used so frequently that otherwise intelligent people are starting to give in and use it to get a point across.  

By packaging "DevOps" into a nice compartmentalized role in the organization, many businesses seem to be tipping their hat to the problem and hoping that filling those roles will somehow accomplish what is needed with little additional need for change.  This is similar to the relatively recent fallacy that buying VMWare and virtualizing your legacy server estate will allow them to avoid the legacy architecture headaches and somehow give the organization "Cloud Computing".  These water down not only the meaning of the movements, but also provide fodder for those who are actively resistant to change by creating compromising stillborn half measures they can point at to say they aren't real.

Having been brought in time and time again to sift through the damage and placate the injured in such poorly implemented change efforts, I hope that this half-baked compartmentalized trend will somehow reverse and not damage yet again another great set of ideas.

I am speaking at Agile 2013

I have been very busy over the past few years honing my arsenal of techniques for creating high performing services and organizations.  In particular, I have been actively working with clients in live situations methodically trying to capture the key essence behind my most effective techniques.  Having seen so many otherwise smart people struggle for so long, I hope to add to the collective knowledge out in the industry to not only help others but to also hopefully reduce the amount of dysfunction that so many have to deal with on a day to day basis.

The talk that I will be giving at Agile 2013 covers one of the elements that I have discovered, which is how to find and improve flow and transparency across an organization.  I have found that many of the techniques I use, including looking for places where friction develops and queues build up, places where communication breaks down or is misinterpreted, and where there are knowledge gaps that form across organizational siloes, have very similar analogues in Lean.  The spirit and mindset that has been built up in the immense body of work within Lean can, when added to both the technical and architectural techniques that have been steadily arising from XP and elastic computing as well as the rapid product development techniques that have been coming from HotHousing and Lean Startup, go a long way to helping IT organizations improve and better serve customers.