Firing the Fire Stopper
A long, long time ago, in a dimly remembered past life, I had a client that I developed a software solution for. It was not your typical contract where the consultant gets paid an hourly or daily rate: I actually had the opportunity (and responsibility) to build and deliver the entire product, turn-key style, although the process was long-term, iterative and involved ongoing maintenance.
I essentially developed a custom sales support information system for these people. Apart from converting data from an organically grown database they had used previously, I had to do pretty much everything from scratch. Over the course of several years, the product grew to become quite large and sophisticated. I must admit that I was proud of my achievement – in a way, I think I still am :-)
Now, here’s the interesting part: The client was a global company operating in the medical devices industry, but my solution was built for and used by only a few local branches. These offices had no local IT departments (everything was handled centrally and by a few contractors), and none of the people that I negotiated with appear to have understood some very basic software development concepts. And so it happened that our legal agreement didn’t stipulate that they “owned” the source code, nor did it require me to even allow them access to it.
Although the precise regulations governing intellectual property may differ slightly from jurisdiction to jurisdiction, generally speaking, unless you sign a contract/waiver that defines different rules, whoever produces a piece of (any) content owns the copyright. Consequently, I owned all the intellectual property (or, technically, my corporation did), and they were merely “licensed” to use their own custom solution. I also had exclusive access to the source code, which would make it extremely hard for anyone else to maintain the system – even in the absence of the legal issues just described.
Vendor lock-in, opportunistic behavior, as well as other buzzwords…
I would like to make one thing clear, although you may choose not to believe me: I never intended to create this situation. It just happened, really :-) We negotiated the terms and conditions of our arrangement (and these were mute on IP issues), and the actual formal written contract, for me, was an afterthought.
A lawyer friend of mine (who isn’t an IP lawyer) helped me with the formalities. For the “software part” of the document (it also had parts covering deadlines, support hours, etc.), we basically took a standard software license agreement we found somewhere on the Internet, tweaked a few things, and that was it. Given their lack of expertise, the client’s representatives seemed happy with it and signed it without any substantial modifications.
As time passed, the operations of the divisions that used the application became increasingly dependent on it. You could say it gradually became a mission-critical system. In addition, judging from my conversations with the managers and users, they were all very satisfied with it and certainly felt no need to replace it.
As I was the only person who could possibly maintain it, the state of affairs could be used as a case study for a number of phenomena you usually encounter in economics and management textbooks. They were experiencing a vendor lock-in situation. I could easily engage in opportunistic behavior and price gouging. In (software) project management terms, you could say that the bus factor (1) was extremely unfavorable. I’m sure many more buzzwords to describe all of this exist :-)
Just as I had never intended to create the situation in the first place, I had no desire later to take advantage of it. I had my reputation at stake, and, also, I simply believe in treating your customers fairly. I do admit, however, that I did start thinking about how things had evolved, and I did find my position very secure. Once I bragged to a girl I went on a date with that I believed this client simply “couldn’t fire me” :-)
When drenched gunpowder ignites
And then the client fired me. Now, don’t get me wrong: It wasn’t a hostile act at all. Let me explain how things unfolded.
As the local offices I worked for became larger, they hired a manager responsible for their various information systems. (A CIO of a sort, although that wasn’t his official job title.) After several meetings and conversations with me, he informed me of their intent to phase out “my” system over the period of about six months. They would replace it with another custom solution, one based on an open source CRM application.
While I certainly didn’t feel in any way embittered, I couldn’t, at first, really understand why this was happening. Firing me meant writing off a system they had invested so much money and effort in and that had worked so well for them. Why would anyone do such a thing?
At the time – to the extent that I was thinking about it then and remember it now – I probably just concluded that it must have been a mistake on the part of the new information manager.
And then the penny dropped
With the benefit of hindsight, as well as some revealing conversations I had during my final six months at the company when I was still supporting the system and assisting with data migration, I slowly began to understand the underlying motives for the decision that previously hadn’t made any sense. Eventually, I had to admit that, from their perspective, it was most likely the right thing to do.
Unlike the people who signed the original contract with me, the newly appointed guy did understand concepts such as source code and intellectual property ownership. He concluded that while it would be expensive for the company to replace my system, living in a situation of absolute dependency on one person would, in the long run, cost them even more.
Arguably, he could have tried to renegotiate the deal with me – I would have been open to the idea of altering our arrangement. In one of our later conversations, he even more or less agreed that he probably should have tried something like that, but by then it was too late. In any case, it really is beside the point here.
Not all “irreplaceable” service providers are created equal
Time and time again, I’ve encountered people who appear irreplaceable. They’ve “achieved” this status – whether inadvertently or deliberately – in various ways, including, but not limited to the following:
- Writing code that is so unintelligible that only the original author can maintain it
- Using obscure and/or old frameworks, libraries or languages that few people understand
- Not sharing domain and other knowledge
The problem with this approach is that while you are making it expensive for your client or employer to fire you, you’re making it even more costly, in a hidden way, for them not to do it. Sooner or later, someone will have the guts to pull the plug no matter what.
As another example, a company I worked for builds products it needs installers for. For many years, they employed the services of a contractor who used an ancient version of InstallShield, and he always found an excuse not to upgrade to something more 21st century. He was the only one capable of maintaining these installers. Replacing him was unthinkable. Until, that is, the unthinkable happened, and the company rewrote all the installers in WiX.
Counterintuitive as it may sound, I believe that if you want to make your position truly secure, you should strive to make yourself as replaceable as possible. For instance:
- Always write code that is easy for other people to maintain
- Share as much knowledge as possible
- Volunteer to train others
- Remember that the source code for a custom solution belongs to the client :-)
All of this, ideally, will result in a situation where your client or employer will feel that losing you wouldn’t lead to insurmountable problems. In turn, no (perceived) need to preempt will exist. In other words, try to replace “negative” incentives to keep you around (as in “you can’t afford to fire me”) with “positive” ones (as in “I’m valuable, and you have no reason to get rid of me”).
Had I volunteered to give my client access to their solution’s source code and train other people to maintain it, they most likely wouldn’t have felt compelled to act in the fairly radical way they did.
Bottom line
Attempts to be on the “right side” of a vendor lock-in situation may backfire. Unless you genuinely believe the people you work for are truly dumb, it’ll probably be safer for you to assume they may try to do something to extricate themselves from a perceived predicament.
If an arrangement appears “too good to be true”, chances are it won’t last.