One of the easiest mistakes in technology is to assume that replacing an existing system is the same as solving the customer’s problem.
During an assignment, I traveled to Oslo, Norway, as a presales solutions architect.
The company I was working with provided hosting services to small businesses and individual customers. Its existing hosting environment was built around Linux and other open-source technologies.
The company had an established customer base that was well served by its existing technology. It wanted to expand its services by adding capabilities based on Microsoft technologies.
From the technology vendor’s perspective, the opportunity initially appeared straightforward: replace the existing environment with its own products.
But that was not what the customer actually needed.
Its existing customers were loyal to the services and technologies they already used. Forcing those customers onto a different platform could have put much of the hosting company’s existing business at risk.
The real question was not, “How do we eliminate Linux?”
It was, “How do we add new capabilities without destroying what already works?”
My architectural recommendation was to keep the existing Linux environment for the customers who wanted it and add a separate environment for customers whose needs were not currently being met.
The client was very pleased with the recommendation. It differed from the original expectations, but insisting on a complete replacement could have jeopardized the opportunity.
By allowing the technologies to coexist, the hosting company could protect its existing business while expanding into a new market. The technology vendor could also gain business it otherwise might not have won.
That experience reinforced an important lesson: the responsibility of a solutions architect is not simply to promote a preferred product.
It is to understand the customer’s business, preserve what is already working, and recommend the solution that creates real value.
Working in technology gave me the opportunity to experience many different cultures and to see how people lived and worked in countries with very different resources.
One experience that comes to mind was traveling to Huế, Vietnam, in 1997 to teach database design at a hospital.
The hospital had requested the training materials in advance. When I arrived, I discovered that the doctors had already read and memorized them—and had used the books to create databases without receiving any instruction.
At that time, computer access within the hospital was limited primarily to doctors, and they were understandably proud of the opportunity to use the technology.
Before the hospital had an electronic database, patients were responsible for bringing their written medical records with them to every visit.
The doctors’ effort was impressive, but the books alone had not taught them how to connect database-design principles with the actual work of the hospital. They had theory on paper, but no instructor to help them translate that theory into a practical design.
The problem was not a lack of intelligence or effort. They had done remarkably well with the resources available to them. The problem was that reading a book was not a substitute for seeing how information moved through the hospital and understanding the work the database needed to support.
So we set the books aside.
For the next two weeks, we walked through the hospital with the nurses. We asked them to show us what they did, how information moved through their work, where problems occurred, and how electronic data might make their jobs easier.
The focus shifted from teaching database theory to understanding the people, processes, and needs that the database was supposed to support.
If we could make life easier for the nurses, we could improve the experience of the patients and, as a result, help the doctors as well.
We did not accomplish the original lesson plan.
But we accomplished what was needed.
That experience reinforced a lesson I have carried throughout my career: good data design does not begin with a textbook, a tool, or even a data model.
It begins with listening to the people who perform the work and understanding the problem that needs to be solved.
Three experiences across three decades taught me that loyalty to an employer should never require compromising personal integrity.
Over the course of my career, I have been asked to do many things I disagreed with. That is part of working for an organization. You do not always agree with management, and you do not always get your way.
But there is a difference between disagreeing with a decision and being asked to do something you believe is dishonest.
Three times in my career, that distinction cost me my job.
The first was in 1989. I was working for a technology company when management wanted us to tell customers that our profit margins were smaller than they actually were.
I had no problem declining to disclose the company’s margins. That was confidential business information, and customers were not necessarily entitled to it. But if a customer asked me directly, I had two acceptable choices: decline to answer or tell the truth.
Making up an answer was not one of them.
I did not spend much time debating what to do. I simply continued doing my job honestly, despite the company’s guidelines. Seven of us ultimately lost our jobs in circumstances involving our Christian convictions about honesty.
The second incident occurred in 2000 while I was working for a consulting company.
A regional vice president wanted me to tell a prospective customer that I had experience with a particular database technology. There was only one problem: I had never worked with it. In fact, I had never even heard of it.
I was perfectly willing to learn the technology. Throughout my career, I have had to learn new systems, tools, and approaches. That is part of working in technology.
But learning something new and claiming experience you do not have are two very different things.
I refused to misrepresent my qualifications and was fired for being disloyal.
This time, the consequences were more personal. The regional vice president who fired me was also a friend. I was leaving behind people with whom I had worked and developed friendships over many years. Some of those friendships have continued for more than twenty-five years.
It was a difficult departure, not because I was uncertain about telling the truth, but because of the relationships involved.
It is also worth making a distinction. This was the decision of an individual leader, not something I would attribute to the consulting company as a whole.
The third incident occurred in 2018.
By then, I had spent decades working in technology, including management and leadership roles. One of the responsibilities of a manager is evaluating the performance of the people who report to him.
The CIO began pressuring me to give one of my direct reports a negative performance review.
The problem was that the employee had done nothing to deserve one. His work had consistently been very good, and I had no legitimate basis for giving him a poor evaluation.
The pressure continued until I finally told the CIO that I could not, in good conscience, give the man a bad review.
The employee was fired. A short time later, I was fired as well.
By that point in my career, I had already experienced the consequences of refusing to compromise my integrity. I knew that standing my ground could cost me my job.
There was no hesitation.
I cannot speak to every consideration behind those decisions. I can only speak to what I was asked to do and why I refused.
Looking back, these three situations involved different responsibilities.
In the first, it was honesty toward customers. In the second, it was honesty about my own capabilities. In the third, it was honesty toward someone who had been entrusted to my leadership.
But the underlying question was the same.
What does loyalty require of us?
I believe employees owe their employers loyalty. When we accept a position, we take on responsibilities to the organization, its customers, its leadership, and the people with whom we work.
We should protect confidential information, support legitimate business decisions, and do our work to the best of our abilities.
But loyalty is not blind obedience.
A manager who asks an employee to deceive a customer is not protecting the company. A consulting leader who misrepresents someone’s qualifications is creating expectations that may never be met. And an executive who pressures a manager to give an undeserved negative review is undermining the trust on which effective leadership depends.
In each case, the request may have appeared to serve an immediate business objective. But the long-term cost of dishonesty can be far greater than whatever short-term advantage it provides.
My Christian faith has always shaped how I approach these decisions. I do not claim to have handled every situation in my career perfectly. Far from it. But there are some lines I have tried not to cross, and knowingly telling a lie is one of them.
There is another part of these stories worth mentioning.
After each termination, I eventually found a better job.
That is something I am grateful for, but it was never guaranteed. When I made those decisions, I did not know what opportunity would come next, how long I might be unemployed, or what the financial consequences would be.
Over the years, I have come to believe that loyalty and integrity should reinforce one another, not compete with one another.
Sometimes the most loyal thing you can do for an organization is respectfully refuse to do something that would compromise its integrity.
And sometimes that refusal comes at a personal cost.
I have never regretted telling the truth. I would have regretted lying.
My career in technology began before technology became my job.
In 1987, I was selling parts. My largest customer was a relatively new company that provided industrial maintenance services. They ordered a considerable amount of product from me every week.
Whenever I visited, I also found myself helping them with their computer.
One day, the shop steward took me aside and said:
“Dan, you are a lousy salesman, but we keep buying from you because every week, when you show up, you fix our computer. You need to change careers.”
It was blunt advice—but it was also good advice.
So I changed careers.
I left a job I hated and took a chance on doing work I loved. Technology eventually became a career that took me around the world, introduced me to remarkable people, and allowed me to spend decades solving problems.
I have loved the work ever since.
Sometimes another person recognizes an ability in us before we recognize its value ourselves. That shop steward saw something in me that I had not yet learned to see.
Sometimes the safe decision is not the right decision.
And sometimes, you have to take a chance and do what you love.
