In this segment, I share a couple of personal experiences. They are both about value. The first relates to the sunk cost fallacy. The second relates to relative value.
Ignoring sunk costs is difficult for many. It’s a logical cognitive fallacy, where people overvalue time, money, and effort already expended instead of considering a project or proposition on its own merits.
Ignoring sunk costs is difficult for many. It’s a logical cognitive fallacy, where people overvalue time, money, and effort already expended, instead of considering a project or proposition on its own merits.
I was a programmer analyst in the late nineties, and I had just changed employers. They had hired a contract programmer analyst to design and develop a catalogue for its field salesforce that could accept ad hoc price updates, as their products were very commodity price sensitive. Although the commodity prices, mark-up formulas, and pricing tiers were hidden to prevent the salespeople and competitors from viewing them, they were needed to drive pricing. The Internet was still relatively new for distributed data applications, and many of the salespeople had no regular or reliable access to it. I was hired to wrap up this project.
Upon the company’s request, the contract programmer developed the application in a spreadsheet program. They gave him a couple of weeks to transfer knowledge to me, and to assist me in completing the application.
It was fairly obvious that this should have been a database application. I mentioned this to my manager at the end of the first week. Although no reason was given as to why a spreadsheet was chosen, I was informed that they’d already invested about six months on their current solution, and it was almost done, so it was too late to change course.
That weekend, I spent sixteen to twenty hours developing a solution in Microsoft Access. By Monday morning, it was at least in the same state—untested as it was—as the spreadsheet solution was. Twenty hours and a more appropriate tool. I told her that it would be done and tested by the end of the week, and we could load it with real data whenever she wanted. The interface and data portions were separate, so small data updates could be sent as necessary. The business logic was in-built with the interface.
The moral of this story not only highlights the problem with maintaining a sunk cost fallacy. This underscores that you can even change tracks at almost any point in the development process. For the record, I’d like to bring to your attention that this predated Agile methodologies and a test and learn approach by years.
You might be thinking that this was a minuscule project with a single developer, but recall that the original track had already taken half a year. Inappropriate technology was selected, and they staffed the project, pigeon-holed into it. This project offered many lessons learnt.
On the topic of value, I share another personal story. Again, this was a couple jobs before the one I just discussed. I had just relocated from Boston to Los Angeles, having left LA for Boston 10 years earlier to attend university. I had planned to take a month off before trying to find a job. This was in the days before a very interactive internet, so a month turned into five. I was canvassing in two primary domains.—technology and finance. Between them, I had sent dozens of resumes to no avail. I had a couple of lower-level financial position interviews, but they didn’t quite pan out.
About five months in, I got an offer for a programmer analyst position from an insurance company. They didn’t balk at my base salary target, and I started within days. Somehow, I got a corner office on an elevated floor overlooking Figueroa. It was not some posh office, but I enjoyed the vista. This was a utility corporate development position—rather a MacGyver role. The technology function and the actual technology was immature. My first assignment was a database project using Microsoft Access to interface with a SQL Server database as I recall. These were the days before VBA (Visual Basic for Applications). I believe it was a corporate directory lookup sort of thing. I’m not sure of that either. In any case, I whipped it up the first two days in the free time I had in between orientation sessions.
When I got home that first evening, I had 3 voice messages. Well, it was an old school answering machine. For the uninitiated, mobile phones were not ubiquitous, so this was the budget solution. Pagers were still the ubiquitous communication tech of the day. In any case, having received virtually no calls in 5 months, I got 3 after my first day of work.
I had two employment offers and one request for an interview at a mortgage lending company. They needed a financial systems programmer for their mission critical mortgage pricing application. It was a Visual Basic application being used in production, but it was unfinished and somewhat buggy—rather, unreliable. The developer had recently departed. And though he’d provided notice, they hadn’t found a replacement.
I called the number on the answering machine. It was around 7 pm, and it went straight through to the CIO. He picked up, as he was still at the office. After a quick screen and my explaining my current employment situation, he asked if I could come in to interview the next day after work. I agreed. He offered me half again what I was making at the insurance company, and I told him that I could start in two weeks, but given my employment situation, I told him that I’d see about starting sooner, offering to work after my other job, if necessary. He agreed that it would be nice, but said that two weeks would be fine. This was good news, because the first job was downtown, and this office was in the Valley, not a short jaunt up the 101. And the rare remote work was likely via FTP than anything else.
At the office the next morning, I gave my notice. I also noted that the standard two-week notice is typically used to tie up loose ends and transition work to others. Neither of these applied to my situation.
My manager pleaded with me to stay. He said he’d meet the competing offer, and then some. I responded that was the central problem. ‘If you can offer that to me now, you could have offered it a week ago’, to which he countered, ‘We gave you what you requested’.
This was in fact true by my own admission, so I informed him that this was a matter of integrity. If the company felt that I was worth at least half again what I was making and yet were willing to keep it for themselves anyway, I didn’t need to be part of that company. I shouldn’t have had to ask. And I have no interest in playing salary leapfrog games.
Despite having no work in progress, I agreed to make as much progress as I could on some unremembered application. Two weeks later, I was gone.
wage premiums…are wages over and above the market rate paid in order to retain quality employees
The lesson here is about what economics call wage premiums. These are wages over and above the market rate paid in order to retain quality employees and to save on onboarding costs.
In fact, not two employers later, I learned first-hand the value of wage premiums. I had been working as a development manager for a dot com. I was hired at a salary a quarter more than I had been earning. After about three months, my manager called me into his office and told me he was raising my wage an additional twenty percent. If you don’t think that instilled loyalty—at least to that manager—, you should think again. It’s been twenty years since then, and I am still talking about it. That should speak for itself.
I hope you enjoyed this segment. It was different to the rest, but I hope you have taken something from it.