Lock-In

I’ve been a consultant/programmer/integrator/other for over twenty years now. That’s not quite long enough to say I’ve seen it all but long enough to notice a few patterns. Admittedly, I’ve spent the vast majority of that time working in the defense world so the patterns may be heavily skewed to that but I think not.

I’ve run across a number of well-entrenched government-developed systems, such as command-and-control systems, with user interfaces and experiences that many professional designers would consider abhorrent. Yet, I have watched smart, motivated men and women in uniform stand in front of working groups and committees dedicated to “improving” systems and workflows and advocate passionately for these seemingly clunky systems.

Why? Because they know how to use these systems inside and out to meet their missions. User experience is ultimately about comfort and confidence. A user that is comfortable with a system will have a great experience with it regardless of its appearance. DOD tackles this reality through training. For all its faults, there is still no organization better at developing procedures and thoroughly training its people in them. It results in a passionate loyalty for the tools that help them do their jobs and places a very high hurdle in front of any tools that seek to replace current ones.

This experience has given me a different view of the concept of “lock-in.” Over my career, I have heard this term used in a pejorative sense, usually proceeded by the word “vendor.” Although I have used the term myself, I usually hear it levelled by a vendor’s competitors. It is typically meant to refer to practices a vendor uses to establish barriers to exit for its customers, making it harder for them to choose a competing technology. Such practices can include artificial bundling of unrelated tools, license trickery, half-truths in marketing, and many more; all of which do happen.

Lock-in is a real thing. Lock-in can also be a responsible thing. The organizations I have worked with that make the most effective use of their technology choices are the ones that jump in with both feet and never look back. They develop workflows around their systems; they develop customizations and automation tools to streamline repetitive tasks and embed these in their technology platforms; they send their staff to beginning and advanced training from the vendor; and they document their custom tools well and train their staff on them as well. In short, they lock themselves in.

This is the right and responsible thing to do. An organization, once it has selected a technology, has a responsibility to master it and use it as effectively as it can. If you start applying numbers to all the activities listed above, you will quickly see that it is an investment that far outstrips the original investment in the technology itself. In fact, the cost of the technology itself is often seen as marginal to the overall lifecycle cost, which makes arguments about removing licensing costs, for example, less effective than they would appear to be.

This is true regardless of the provenance of the technology. The original technology has to start to become a hindrance before change is seriously considered, which I am seeing in a few cases these days. But, by and large, the very strong pattern I have seen is that the majority of lock-in originates with users. To fail to recognize that and continue to target the vendor is to miss the point and, ultimately, the target.