When the Client Gets Caught Between the Developer and the Server Administrator

In software projects, when a problem occurs, it is not always immediately clear where it comes from. The developer may believe the problem is related to the server, the network administrator may blame the software, and eventually each side may refer the issue to someone else. In such situations, finding the actual cause of the problem is more important than finding someone to blame.

One of the more interesting experiences I have had in this area involved a project where the software needed to connect to another server through an API.

However, no matter what we tried, the connection could not be established. I discussed the issue with the server administrator. He was completely confident that the problem was on our side, while we believed the issue was related to the server configuration.

The client trusted me, but because they did not have detailed knowledge of the technical communication between the software and the server, the issue needed to be investigated technically so that the actual cause could be identified.

On the other hand, the server administrators insisted that the problem was with the software and even told the client:

“Your developer doesn't know what they are doing.”

The client actually laughed when hearing this statement because they believed the server administrators did not know the developer or the history of the project well enough to make such a judgment based on a single technical problem.

Of course, not every client has the same level of trust in the developer. If a client does not have a sufficient understanding of the technical process behind a project, repeated disagreements like this or negative judgments from others can gradually reduce their confidence in the developer. That is why, instead of arguing or simply defending yourself, it is important to investigate the issue technically, document the findings and identify the actual cause of the problem.

Instead of getting into an argument, I examined the communication path step by step. Based on what I found, I asked the server administrators to review the server-side configuration again.

Eventually, it turned out that the problem was caused by two ports being closed on the server. Once the ports were opened, communication between the software and the server was established and the problem was resolved.

At the end, to make it clear to the client that the delay in the project had not been caused by our side, I asked them to ask the server administrators:

“Exactly where was the problem?”

Their answer was exactly what our technical investigation had shown.

After the issue had been identified, I told the client:

“Now ask them who doesn't know what they are doing.”

This experience taught me an important lesson: when dealing with a technical problem, even if a specialist confidently believes they know the cause, it is better to investigate the issue step by step and make decisions based on technical evidence rather than arguments or assumptions.

In situations like this, the person who speaks with the greatest confidence does not necessarily have the most accurate diagnosis.

The most important task in such circumstances is not finding someone to blame; it is identifying the actual cause of the problem and providing technical evidence that leads to the right solution.